ChainPatrol

  • Name: ChainPatrol
  • URL: https://chainpatrol.com/
  • Category: web3 brand-protection company / phishing-blocklist and takedown operator / threat-intelligence distribution provider
  • Tags: ethereum-ecosystem
  • Summary: ChainPatrol belongs as an entity note, not a protocol note. The useful question is who defines protected brands and legitimate assets, runs the detection-and-review queues, decides what becomes BLOCKED versus ALLOWED, distributes those verdicts into wallets, browsers, and partner APIs, and handles disputes plus takedown workflow. The real control surface is the company-run detection, review, blocklist, and takedown stack in front of user clicks and wallet interactions.
  • What it does:
    • Monitors domains, social profiles, app listings, browser extensions, and related online surfaces for phishing, impersonation, and scam activity targeting customer brands and executives
    • Maintains a blocklist of confirmed malicious URLs, domains, social accounts, wallet addresses, and related assets, then distributes that threat intelligence to browsers, wallets, marketplaces, and other partners
    • Exposes partner APIs for asset checks, report creation, disputes, asset-list synchronization, blocklist prefix sync, detection-config management, webhooks, metrics, and queue-health monitoring
    • Runs a review workflow spanning ChainPatrol staff, trusted reporters, customer admins, and automation, with documented approve / reject / skip / escalate paths
    • Operates takedown workflow with provider contacts, legal-document handling, evidence collection, status tracking, and retraction handling when a false positive is identified
  • Key claims:
    • The homepage says ChainPatrol scans for fake domains, social profiles, and app listings, blocks malicious sites across 20+ browsers and crypto wallets, and files takedowns to remove threats at the source
    • The API overview says ChainPatrol works with leading wallets and security tools to block scam links, contract addresses, and wallet addresses before user interaction, and that those APIs are offered free to wallets, security apps, and marketplaces
    • The blocklist docs describe a blocklist-first, takedown-second operating model, position the blocklist as a continuously updated threat-intelligence database, and say ChainPatrol shares intelligence bidirectionally with Crypto-ISAC
    • The brands docs show that organizations define brand terms, images, legitimate assets, and legal documentation inside ChainPatrol’s workspace model, which means the operator is not only classifying threats but also curating the reference truth used to judge impersonation
    • The reviews docs describe a full proposal-and-review control plane with staff analysts, trusted reporters, customer admins, automation, escalation, revert windows, and threat-scoring logic rather than a thin static list service
    • The false-positive docs explicitly say an asset only ends up as Blocked after review by a human on ChainPatrol’s team or by a human at one of its scanning partners, which makes human review policy part of the control surface
    • The takedowns docs say ChainPatrol maintains direct contacts with platform trust-and-safety teams plus API integrations for accelerated takedowns, reinforcing that provider relationships and formatting know-how sit inside the company boundary
  • Whitepaper: No classic whitepaper or litepaper is the important artifact here. The strongest current primary-source snapshot is ../whitepapers/chainpatrol-company-primary-sources-2026-08-08.md.
  • Sources:

Why this company note belongs in the corpus

  • ChainPatrol is analytically stronger as an operator note than as a project note because the meaningful question is not what protocol does it run? but who decides what counts as a phishing domain, impersonation account, or wrongly blocked asset for downstream wallets, browsers, and brand teams?
  • The company boundary matters because ChainPatrol is not just publishing a passive feed. It defines protected brands and legitimate assets, runs the review and escalation queue, authors blocklist state, distributes updates, and manages the dispute and takedown loop.
  • That makes ChainPatrol a recurring offchain control-surface note rather than a generic security-vendor page. The preserved question is who gets to classify, publish, and retract threat verdicts that other products may start treating as policy truth.

Internal linkages

Protocol / company boundary

  • There is no especially clean standalone ChainPatrol protocol boundary doing the analytical work here.
  • The useful surface is the company-run brand-definition, detection, review, blocklist-distribution, dispute, and takedown stack that sits between raw internet content and the wallets, browsers, dashboards, or security teams that act on ChainPatrol’s judgments.
  • That is why ChainPatrol belongs in companies/: the real control question is who authors and operates the threat-verdict workflow, not whether one API, browser extension, or docs page can be described as a product.

Control surface

  • Practical leverage sits in how brands and legitimate assets are modeled, which detections get run, what trusted-reporter or automation paths are allowed to fast-track decisions, who can approve or escalate proposals, how quickly blocklist updates propagate, and how disputes or retractions are resolved.

  • Additional leverage sits in the operator-managed APIs and webhook surfaces that partner wallets, marketplaces, and security teams may treat as real-time threat truth.

  • None of that is onchain. The visible warning page or wallet block is only the last inch of the stack; authority already accumulated when ChainPatrol or its scanning partners decided that an asset was malicious enough to publish, distribute, and escalate.

  • Treat ChainPatrol as phishing-response and blocklist-policy infrastructure, not as a neutral protocol primitive.

  • Last reviewed: 2026-08-08 UTC