# Snyfer, full technical documentation > The long form companion to https://snyfer.com/llms.txt. It describes the five layer > architecture behind a scan report, what each layer measures, what a reader may and may not > conclude from a finding, and the surfaces built on top of the reports. ## Crawling All crawlers and AI agents are welcome to access the public site, including search, retrieval, user-requested browsing and model-training crawlers. The same robots.txt policy applies to every user agent; there are no agent-specific exclusions. Private dashboard and API routes remain excluded from crawling. Page-level indexing directives remain applicable. ## What is ours and what corroborates Layers 1, 4 and 5, acquisition, correlation and scoring, are built and run by Snyfer and produce findings that exist nowhere else. Layer 3, regulatory ingestion, is our extraction from public notices that are published as prose rather than as data. Layer 2 is third-party reputation data, and it corroborates the rest rather than constituting it. The layers below are numbered in the order a scan runs them, not in order of importance. Scanning since 2026-02-28. 31,025 domains analysed. ## The five layers A scan runs the layers in order. A later layer may reuse an earlier layer's result, and no layer is allowed to overrule another: a report shows what each one measured. ### Layer 1, acquisition, ours The page is fetched with a real browser engine and anti-detection rendering, because a large share of fraudulent sites serve a different document to anything that looks automated. Recorded: the final URL after redirects, every hop with its status code, the HTTP response headers, the TLS handshake, the resource waterfall, the cookies set, the rendered DOM and a page capture. Technology fingerprinting runs on hand-written signatures rather than a licensed signature database. A site that does not answer is not a failure of the scan. The report records the reason (offline, parked, for sale, blocked by an interstitial) and marks every measured value absent rather than zero. Absent and zero are different claims and the reports keep them apart. ### Layer 2, reputation, third-party corroboration The URL and the domain are checked against: - VirusTotal, aggregating antivirus and URL scanning engines, up to 98 on a given scan, 92 on average. The report lists each engine that flagged the URL and what it called it. - Google Safe Browsing. - Cloudflare phishing detection. - Community blocklists: MetaMask eth-phishing-detect, ScamSniffer, Phishing.Database, and a crypto scam intelligence feed. These are read from lists refreshed on a timer, not queried per scan; the report distinguishes the two. A detection is evidence, not a verdict. Two engines out of 98 is a weak signal and the report says so by printing both numbers. ### Layer 3, regulatory, our extraction 30 financial authorities are read directly and continuously, 41,041 official warnings naming 68,191 domains. When an authority publishes a notice naming a domain, that notice is attached to the domain with a link to the original. Two limits are stated on every page that uses this data. A notice may name several domains, so a count of rows is not a count of enforcement actions. And an authority withdrawing a notice is not currently detected, so a warning that has since been lifted may still be shown: the link to the original notice is there so a reader can check. ### Layer 4, correlation, ours Technical fingerprints tie domains together. The families, in descending order of how much they prove: Account level, the strongest. Analytics id, tag-manager id, tracking id, registrant, email, phone number, postal address. A shared analytics identifier suggests a connection, but copied code and shared services must be considered before attributing ownership. Network level. IP address, nameserver, TLS certificate fingerprint. Strong when the address hosts few sites, weak when it is a shared host, so the report prints the neighbourhood size beside the tie. Content level, the weakest on its own but the most productive in volume. JavaScript path fingerprints, template signatures, DOM structure hashes, content hashes, favicon hashes, build hashes, SVG sprite hashes, account-type hashes. Thousands of honest sites share a commercial theme. The graph excludes hashes that are known boilerplate (hosting parking pages, seizure notices, default error pages), because those cluster strangers. Regulator co-listing. One notice naming several domains ties them together. This is the only non-technical family, and it carries no human curation: there are no analyst-added edges in the graph. 463,115 correlations are currently held across 80,605 domains, resolving into 192 domain clusters. A cluster is a lead, not a conviction. Every network page says so. Cluster names shown on the site are generated labels for reference, not names the operators use, except on the networks that carry a written dossier, where the name is the one the operation itself advertises. ### Layer 5, scoring, ours Every domain starts at 100 and the score is clamped to the range 1 to 100, so 1 is the lowest value the model can assign and 0 never appears. 14 penalty chains subtract from it and 2 bonus chains add to it. A chain contributes at most one tier. Penalties do not simply stack. The largest applies in full and each subsequent one at half the weight of the last, adjusted by the tier that fired, so a site with one fatal finding and a site with ten do not collapse to the same number. Bonuses and manual adjustments are not subject to that decay. The chains, their tiers and their weights are published at https://snyfer.com/trust-score, and every report lists which tier of which chain fired and what it was worth. The model in use is Trust Score 4.0. The score is computed by the engine, once, and stored. It is never recomputed in a browser or in the web tier, so the number on the page is the number in the record and two readers cannot see two different scores for one scan. Bands used throughout the site and the share cards: - 1 to 24, high risk - 25 to 44, elevated risk - 45 to 69, moderate risk - 70 to 84, low risk - 85 to 100, minimal risk ## Report structure A report at https://snyfer.com/scan/{domain} carries: - Identity: the brand name read off the page, the favicon, the final URL, the category and the engine's reasoning for it. - Scoring: the trust score, the verdict, and every scoring badge with its tier and weight. - Threats: antivirus detections by engine, regulator warnings with links to the notices, blocklist hits by provider. - Infrastructure: hosting provider, ASN, server location, WHOIS registration and expiry, TLS certificate, security headers, uptime history. - Forensics: page timing, resource breakdown, redirect chain, cookies, HTTP transactions. - Network: the live neighbourhood, one node per connected domain, with the trait behind each edge named. - Reports: community submitted testimony about the domain, clearly separated from measured data. Some blocks may be replayed from an older scan of the same domain when the site was unreachable at scan time. Those blocks are labelled as archived, with the date they were observed. Registration and certificate data are never replayed. Map tiles on the infrastructure blocks are proxied through snyfer.com rather than fetched from a tile server by the reader's browser, so no third party learns which server location a visitor was looking at on a page that names a business as fraudulent. ## Freshness, publication and indexation A report is considered fresh for 10 days. Past that a visitor can trigger a rescan, which refreshes the measured data and preserves any editorial state. The report page states the age of the scan and the date it ran. Availability is checked separately. Current status uses dated observations; observations older than 48 hours are shown as unknown. **Not every scanned domain has a public page.** A report can be unpublished, withdrawn after publication, or on a reject list that bars the domain from being rescanned at all. The site answers those cases with a status rather than a thin page, so a citation to a report URL is a citation to something that may later stop resolving. Public availability and search indexation are separate decisions. Only selected indexable pages enter https://snyfer.com/sitemap_index.xml. Other public reports, infrastructure records, signals and network pages can remain noindex while still being readable. Authentication pages are noindex rather than disallowed, deliberately: a disallowed page is never fetched, so its directive is never read. ## The intelligence surfaces Built over the same records, each one a different pivot: - https://snyfer.com/networks: domain clusters, one page per cluster, with the shared trait that defines it. Some carry a written dossier rather than a generated summary. - https://snyfer.com/signals: one page per fingerprint, and every domain carrying it. - https://snyfer.com/infrastructure: seven pivots, IP, ASN, registrar, nameserver, mailserver, TLS certificate and favicon. - https://snyfer.com/warnings: one page per financial authority, its notices and its timeline. - https://snyfer.com/reports: community testimony, moderated before publication. - https://snyfer.com/reports/by-contact/{type}/{value}: every domain carrying one email, phone number or wallet address. One person's word is testimony; the same phone number under four unrelated domains is a pattern. ## The browser extension Snyfer Shield, https://snyfer.com/extension, uses a signed domain blocklist and local checks. Automatic blocking is on by default. Its current permissions, network requests and data retention are documented at https://snyfer.com/extension-privacy. Two public endpoints serve it, and they are public infrastructure rather than an extension-only contract: - https://snyfer.com/blocklist/latest.json: the signed manifest, with an ETag, polled with `If-None-Match`. - https://snyfer.com/blocklist/{version}/filter.bin: the filter the manifest signs. ## The API https://snyfer.com/developers. Keys are provisioned per project through https://snyfer.com/contact; there is no self-service signup, and that is a product decision rather than a missing feature. **VirusTotal results are not redistributed.** Their licensing terms do not permit it, so a consumer who needs engine verdicts brings their own VirusTotal key alongside ours. Everything else in a report is available: scoring and classification, Safe Browsing, Cloudflare and community blocklist verdicts, regulator warnings with source URLs, the threat graph and its clusters, WHOIS, TLS, DNS, hosting, geolocation, security headers and detected technologies, screenshots and brand assets, extracted indicators, page timing and network statistics, uptime history, and community reports both read and submitted. ## What a report does not claim - It does not claim a business is fraudulent. It reports what was measured and what authorities have published. - It does not compute a score in the browser or apply a threshold outside the engine. - It does not publish contact values as an accusation. An email or a phone number extracted from a page is evidence of what the page carried, and the same value may appear on an unrelated site. - It does not treat a shared page template as proof of common ownership. - It does not claim any connection was verified by a human. Every edge in the graph is computed. ## Corrections A business that believes a report naming it is wrong can contest it at https://snyfer.com/contact, which is the first reason listed on that form. The stated response time depends on the inquiry. Security disclosures can be submitted through the contact form. ## Quotas - 3 scans per 24 hours without an account, 10 with one - Breach checks: 5 per hour - Technology checks: 5 per hour - Community report submissions: 5 per hour - Contact form: 10 per hour - Newsletter: 5 per hour - Public reads: 100 per minute - Threat intelligence reads: 60 per minute Reading a published report is not rate limited as a scan. A cached scan result is served without consuming a scan.