Scam Sniffer

• Name: Scam Sniffer
• URL: https://www.scamsniffer.io/
• Category: anti-scam company / phishing-detection and signing-risk operator / threat-intelligence distribution provider
• Tags: ethereum-ecosystem
• Summary: Scam Sniffer belongs as an entity note, not a protocol note. The useful question is who labels malicious domains, scores risky signing flows, decides which checks and third-party signals matter, controls freshness and paid-versus-delayed distribution, and packages those verdicts into extensions and partner APIs. The real control surface is the company-run anti-scam classification and feed-distribution stack in front of wallet interactions.
• What it does:
  • Runs a browser extension that warns on phishing sites and suspicious signing flows
  • Sells malicious-website detection, blacklist, and threat-intelligence APIs to wallets and other crypto products
  • Publishes an open-source scam-database repo with phishing domains and addresses, but with a built-in delay relative to the paid real-time feed
  • Documents a transaction-precheck stack that combines domain checks, contract inspection, transaction simulation, suspicious-address checks, malicious-code checks, and sign-request checks
  • Publishes public scam research and drainer-loss reporting that also reinforces its role as a feed and classification operator rather than only a browser-extension brand
• Key claims:
  • The homepage says Scam Sniffer aims to enhance anti-scam capability of individual users and markets both end-user protection plus API products for partners
  • Official materials present Scam Sniffer as both a malicious-website detection provider and a blacklist API vendor for safer browsing and signing experiences
  • The docs describe a layered security-check pipeline using domain analysis, contract checks, Tenderly-based simulation, suspicious-address lookups, malicious-code detection, and sign-request checks, which means the judgment surface is broader than a static phishing list
  • The docs explicitly reference outside data and services such as Etherscan, Tenderly, SlowMist, and GoPlus inside the evaluation flow, making signal selection and composition part of the operator boundary
  • The open-source scam-database repo says blacklist data is refreshed every 24 hours but published with a 7-day delay, while real-time access is sold through a premium API; that freshness split is a real authority and distribution choice, not just pricing trivia
  • Public site statistics and research outputs reinforce that downstream users often encounter Scam Sniffer as a live source of labeling and warning decisions rather than as a neutral public dataset
• Whitepaper: No classic whitepaper or litepaper is the important artifact here. The useful primary-source snapshot is ../whitepapers/scam-sniffer-primary-sources-2026-04-25.md.
• Sources:
  • https://www.scamsniffer.io/
  • https://docs.scamsniffer.io/docs/security-check
  • https://docs.scamsniffer.io/reference
  • https://github.com/scamsniffer/scam-database
  • https://github.com/scamsniffer

Why this company note belongs in the corpus

• Scam Sniffer is analytically stronger as an operator note than as a project note because the meaningful question is not what product page does it have? but who decides what counts as a malicious domain, suspicious sign request, or risky transaction for downstream wallets and users?
• The company boundary matters because Scam Sniffer does not merely expose a browser extension. It maintains the labeling pipeline, composes outside signals, decides update cadence, and controls which consumers get real-time versus delayed intelligence.
• That makes Scam Sniffer a recurring offchain control-surface note rather than a generic anti-phishing app. The preserved question is who gets to classify, distribute, and monetize the warning stream that other products may start treating as policy truth.

Internal linkages

• Project-layer alias: scam-sniffer.
• Best adjacent wallet-safety comparisons: blockaid, blowfish, and chainpatrol.
• Best adjacent broader screening comparison: goplus-security.
• Positive-design companion on keeping misclassifications or compromised sessions from becoming catastrophic: post-authentication-bounded-loss-design.
• Positive-design companion on signer-facing authenticity and interpretation layers: signer-intent-truth-security-object.

Protocol / company boundary

• There is no especially clean standalone Scam Sniffer protocol boundary doing the analytical work here.
• The useful surface is the company-run domain labeling, transaction-precheck composition, blacklist publication, extension and API distribution, and premium-versus-delayed feed policy that sits between raw web content and downstream wallet or user action.
• That is why Scam Sniffer belongs in companies/: the real control question is who authors and distributes the anti-scam verdict workflow, not whether one extension, API endpoint, or research page can be described as a product.

Control surface

• Practical leverage sits in domain classification, suspicious-address labeling, simulation quality, third-party signal selection, warning thresholds, blacklist freshness, and the exact split between paid real-time access and delayed public data.

• Additional leverage sits in how partner integrations convert Scam Sniffer output into advice, friction, or hard stops for users.

• None of that is onchain. The visible extension warning is only the last inch of the stack; authority already accumulated when Scam Sniffer decided what counted as suspicious enough to publish and how quickly that verdict should propagate.

• Treat Scam Sniffer as anti-scam policy and feed-distribution infrastructure, not as a neutral protocol primitive.

• Last reviewed: 2026-08-08 UTC