• 854 new operator wallets funded by the same Master Funder in the past 60 days

• $16.8M USDT processed by the Ethereum collector from 1,450 unique senders

• $1.2M USDC processed by the Polygon collector from 1,100 unique senders

• Two addresses we previously labeled as "whale co-conspirators" are almost certainly exchange / OTC hot wallets — laundering starts at a CEX compliance gap, not a conspiracy

• Wallet rotation theory confirmed: operator addresses turn over on a 2-3 month cycle, making static blacklists obsolete by design

The investigation publicity did not deter the network. It accelerated.

Recap — What We Found in February

In our February 2026 investigation, we traced:

• 264+ operator wallets distributing 50+ Unicode-impersonation fake token contracts (Cyrillic UЅDT, Lisu ꓴꓢꓓt, zero-width invisibles)

• 6,892+ poisoned addresses across three chains

• $5.3M total capital moved, including 176M yen of JPYC

• A single Master Funder at 0x54cdcbdb… — 16,226 AVAX balance, 1,585 lifetime recipients, ~53% confirmed operators

• Two laundering collectors on Ethereum (\(2.67M USDT) and Polygon (\)788K USDC)

• A proven relay pattern: victim → look-alike → relay → collector, 34 minutes end-to-end

The question we left open: does this network dismantle itself after exposure, or does it keep running?

We came back two months later. Here's what we found.

Methodology

On 2026-04-20, we re-pulled on-chain state for every address flagged in the February report — using Routescan (Avalanche, keyless), Etherscan V2 (Ethereum and Polygon, free API key),
and ChainAnalyzer's Neo4j graph for cross-chain correlation.

Every number in this post is reproducible against public on-chain data as of 2026-04-20 06:45 UTC.

Headline Deltas

Three things happened in parallel: aggressive new operator recruitment, continued laundering of victim funds into collectors, and systematic retirement of old operator wallets exactly as
wallet-rotation theory predicted.

1. The Master Funder Keeps Recruiting

We pulled the most recent 10,000 transactions from 0x54cdcbdb…. After filtering to outflows since 2026-02-17:

• 1,119 outbound AVAX transfers

• 49,441 AVAX sent total (~\(1.24M at \)25/AVAX)

• 854 unique destination addresses — none of which received funds before 2026-02-17

To put that in scale: the February investigation covered 1,585 lifetime recipients. In the two months since, the Master Funder added another 854 recipients — an expansion of 54% of
the prior lifetime count, in 60 days.

Top 10 New Destinations (Since Feb 17)

The single-TX recipients receiving 7,000–10,000 AVAX in one shot look like fresh operator-funding events. The multi-TX recipients (38 transactions over a month) are mid-tier active operators.

The investigation exposing this network didn't slow it down. If anything, Master Funder activity accelerated.

2. The "Top Source" Was Not a Co-Conspirator

In February we noted a funder at 0x9f8c163c… that had sent 5,077 AVAX to the Master Funder but which we hadn't fully traced. Two months of additional data make clear: this address is
almost certainly an exchange or OTC hot wallet, not part of the criminal network.

Evidence:

• Current balance: 1,688,967 AVAX (~$42M)

• First traceable activity: 2021-09-06 — pre-dates the entire poisoning operation by 4+ years

• 2.7M AVAX inflow + 2.4M AVAX outflow in the last ~10,000 transactions alone

• Behavior pattern today: hundreds of zero-value transfer calls per day, occasional execute calls on a router, small payments to fresh addresses — classic CEX hot-wallet idle /
  withdrawal fingerprint

• Active on Ethereum and Polygon too — cross-chain hot wallet footprint

The 5,077 AVAX it once sent to the Master Funder was, in all likelihood, a regular withdrawal from a centralized exchange. The operator walked up to a CEX counter, withdrew AVAX, and walked away.

That's not a conspiracy. That's a compliance gap at the exchange.

Similarly, 0x3bce63c6… ("142K AVAX whale") — balance 168,901 AVAX, active today (last TX 2026-04-20 06:40 UTC), same hot-wallet fingerprint. Its 40 AVAX contribution to the primary operator in February was likely another exchange withdrawal.

Conclusion: there is no whale co-conspirator. The laundering-side money originates at one or two major exchanges that have poor outbound AML controls. This is actionable — and probably
SAR-worthy if you're an agency.

3. The Collectors Are Busier Than Ever

Ethereum Collector 0xbca34ed5…

In two months, this address handled \(16.9M USDT inflow from 1,450 senders and \)15.1M outflow. Net +$1.73M. At this velocity, the collector processes more USDT in one week than its entire Feb 17 balance.

Polygon Collector 0xa6380bfd…

The USDC balance dropped because they're laundering it downstream, not because victim flow stopped. 1,100 unique senders in two months is up from 715 total in February. The relay pattern (victim → relay → collector within ~34 minutes) is still producing the majority of those inflows.

4. Wallet Rotation Was Real

In February we theorized that operator wallets are disposable. The data now confirms it:

• Primary operator 0xb2de52d8… — last activity 2026-02-14, 3 days before we published. Dead ever since.

• Active operator 0x03309000… — was active on all three chains in February. Today: AVAX depleted (last TX 2026-04-15), ETH depleted (last TX 2026-03-04), POL near-zero (last TX
  2026-02-25)

• Top operator 0x0808469a… — received another 1,794 AVAX late Feb to early March, then quiet. 80 AVAX remains

• Lisu deployer 0x64424853… — dormant since 2025-12-23

The 854 fresh destinations the Master Funder has been seeding since Feb 17 are exactly the replacements. The operator population turns over on a roughly 2-3 month cycle.

Implication for AML teams: address blacklists decay. A list of operator addresses from February is 30–50% stale by April. Detection has to operate at the fund-flow and behavioral
level, not the static-address level — which is exactly the design of ChainAnalyzer's Follow Mode and graph-clustering detectors.

5. The Mass-Poisoning Funder Paid Off

Perhaps the single most striking data point: the Polygon mass-poisoning funder at 0xa081aa46… spent just $12.55 to poison 6,874 addresses in January.

Today, that address holds 23,435 POL (~$24K). Active, last TX 2026-04-20 00:14 UTC.

From \(12.55 to \)24,000+ — a 1,870× return on capital in 3 months, before even counting any funds it has already moved downstream.

That's the entire economic argument for why this attack class is not going away without active defense.

6. The Deployer Hasn't Shipped New Contracts — It Doesn't Need To

0x4226dd7419b1431f512d82a2c9e5fa1597fb1077 was the main fake-token deployer responsible for 39 Unicode-impersonation contracts. We checked whether it has deployed new contracts since Feb 17.

Zero new deployments. 200 other transactions.

The existing 39 contracts are still being used to mint and transfer fake tokens. The deployer is operational but not creating — meaning typical "contract creation detection" signals miss
this operator entirely during the period it's most active.

What This Changes

For victims and potential victims

The network exposing itself to public investigation did not cause it to shut down. Every protective behavior we recommended in February still applies, with more urgency:

• Never copy addresses from TX history

• Compare character-by-character

• Treat unsolicited tokens as a targeting signal

• Screen destinations before sending

ChainAnalyzer does this free at chain-analyzer.com. The MCP server lets AI agents do it automatically before signing.

For exchanges

Two addresses — 0x9f8c163c… and 0x3bce63c6… — have together funded wallets seeding thousands of poisoning operators. Our review strongly suggests these are exchange or OTC hot wallets. If they are yours, your withdrawal-side AML controls have a blind spot specific to address-poisoning actors. We would welcome a conversation.

For AML teams and regulators

Address-based blacklists decay within 2–3 months for this attack class because of deliberate wallet rotation. Effective detection has to operate at the fund-flow and graph level.

ChainAnalyzer's detector suite is explicitly designed around this:

• P2 ADDRESS_POISONING for Unicode impersonation signatures

• W9 / W10 bridge detectors for cross-chain laundering

• Follow Mode for automatic BFS graph exploration

• Exchange DB with 60+ known CEX hot wallets

For Japan-market crypto operators

The 176M yen of JPYC observed in this network in February — and the continued operator expansion since — continues to indicate that Japanese retail users are specifically in the
crosshairs.

ChainAnalyzer's JPYC AML coverage was built for exactly this. If your product uses JPYC for B2B settlement, creator payouts, or EC payment
acceptance, pre-transfer screening is no longer optional.

Takeaways

• The $5.3M network is now materially larger than when we published the February report. The investigation publicity did not deter it; it accelerated

• 854 new operator wallets funded by the single Master Funder in 60 days. Operator population rotates on a 2-3 month cycle

• The Ethereum collector processed \(16.8M USDT from 1,450 senders; the Polygon collector processed \)1.2M USDC from 1,100 senders. Real victims, real money, active every day

• Two "whale co-conspirators" are almost certainly exchange / OTC hot wallets. The laundering stack starts at a compliance gap inside those exchanges

• The fake-token deployer has not shipped new contracts in two months. The existing 39 contracts suffice. Contract-creation-based detection misses this

• For retail Web3, the defense is pre-transfer address screening. For AI agents, the defense is automatic screening via the ChainAnalyzer MCP server at $0.008 per check

We'll follow up again in 2-3 months. In the meantime, every new operator the Master Funder seeds between now and then will be tagged and propagated to ScamDB and the ChainAnalyzer detector suite automatically via Follow Mode.

Try It Yourself

Any of the addresses above can be scanned free at chain-analyzer.com. Or programmatically:

• REST API → /docs/api

• x402 pay-per-request → /docs/x402 (\(0.008–\)0.05 per call, no signup)

• MCP server → npx chainanalyzer-mcp (Claude Desktop / Claude Code / ChatGPT / Gemini compatible)

If you find new operator wallets the Master Funder has seeded, report them to ScamDB.

Originally published at chain-analyzer.com/news/address-poisoning-network-followup.
Prior investigation: The $5.3M Address Poisoning Network (February 2026).
ENS: chainanalyzer.eth · Engineering blog

Date: 2026-02-09, 14:28 UTC
Loss: 0.093668917 SOL (~$7.95)
Vector: A "First-Come-First-Served" airdrop link, posted in the Orynth Discord, by an account wearing the ORY admin badge.

That last detail is the whole story.

I'd been in that Discord for months. Active member. Followed the project. So when the post landed in #FCFS — admin badge, friendly tone, link to solland.cc redirecting to hibit.app — I did what any conditioned crypto user does: connect wallet, sign, claim.

The "claim" was a System Program Transfer disguised as an airdrop call. My SOL went straight to:

7kMpieh2THdaC5eUvxFJDL3TdsQWVQCwdhsEjLj1eL26                                                                                                                                                    

Solscan TX →

The amount didn't matter. What mattered was the realization sitting in my chest as I watched the TX confirm:

I fell for it because the badge was real.

If the compromise vector I just experienced — authority-based trust — could catch someone who'd been in this space for years, then it could catch literally anyone.

48 Hours Later

I didn't post a warning thread on Twitter and move on. I traced the wallet.

What I found was not an opportunist.

• Funded via FixedFloat (KYC-free instant exchange)

• Laundered via Jupiter (SOL → USDT swap)

• Withdrawn back through FixedFloat to break the chain

• $3,700+ stolen across the previous two weeks — 3,640 USDT + 0.67 SOL

• Dozens of victims matching exactly the same TX shape as mine

This was a pipeline. Industrialized. Repeatable. And nobody in retail crypto had a tool that would have flagged any of it before signing.

That's the moment the real problem clicked into focus:

The problem wasn't "I made a mistake." The problem was that no tool existed that would have caught this before I signed.

ScamDB Entry #1

Before I wrote a single line of UI code, I created a JSON file: scamdb.json.

The first entry was 7kMpieh2TH…j1eL26, with:

• the two phishing domains

• the laundering path

• the asset profile

• the entry vector (compromised admin)

That entry still lives in the production ScamDB today — alongside 100+ curated entries, OFAC SDN, Chainabuse, CryptoScamDB, GoPlus, and community reports. Every scan ChainAnalyzer runs checks against this set first.

The \(7.95 was the most valuable \)7.95 I've ever spent.

TokenForge → ChainAnalyzer

The first ship — TokenForge, February 2026 — was Solana-only. 14 detection rules. One-click scan of any mint or wallet. No login. Free.

Two weeks in, a friend asked me to scan an Avalanche address. I didn't have EVM support yet. He showed me what he was seeing: fake Cyrillic UЅDT tokens being spammed at legitimate wallets,
looking pixel-identical to real USDT in every wallet UI.

I added Avalanche. Then Ethereum. Then Polygon. Bitcoin later. Then I pointed the scanner at his Avalanche address.

It flagged CRITICAL with 20 detections. I turned on Follow Mode — a graph BFS feature I'd just shipped — and let it crawl the transaction graph.

Fourteen wallets became fifty. Fifty became two hundred and sixty-four.

Together they moved $5.3M across three chains. Every one of them funded by a single upstream wallet I started calling Master Funder.

That was the moment I realized what I was building wasn't a "consumer scam scanner." It was an AML-grade investigation platform for the retail Web3 era.

Two months later, the network is still growing → 854 new operator wallets, $16.8M USDT collected.

What Changed

What didn't change: every feature is still exercised against the kind of attack that cost me $7.95.

Five Lessons I Wish Someone Had Told Me

1. Admin badges mean nothing. Treat any post in your favorite project's server the same way you'd treat a cold DM.

2. "Connect wallet" is not a safe operation. Read what you're signing. If you can't read it, don't sign.

3. Address-first verification. Before sending anything, scan the destination. Three seconds.

4. FCFS airdrops are always scams. Real projects don't panic people into signing instantly.

5. Post-mortem immediately. When you lose money, trace it on-chain before you spiral. The understanding is more valuable than the money you lost.

Where We Are Today

ChainAnalyzer now:

• Scans across five chains: BTC, ETH, POL, AVAX, SOL

• Runs on Azure Japan East, FISC-aligned hosting

• Ships an MCP server on npm and the official MCP
  Registry, callable from Claude Desktop, Claude Code, ChatGPT, Gemini, Cursor

• Supports pay-per-request via x402 USDC on Base or Solana mainnet — \(0.003 to \)0.05 per call, no API key

• Ships a JPYC-specific compliance suite for Japanese stablecoin operators

• Was accepted into the Japan FSA FinTech Proof-of-Concept Hub (2026-03)

• Earned a AAA score on Glama MCP Directory and is listed on
  awesome-mcp-servers

All from a $7.95 drain two months ago.

What's Next

Two things pull me forward.

1. The \(5.3M network is still growing.
Since our February report, the Master Funder has disbursed another 49,441 AVAX (~\)1.24M) to 854 new destination addresses. The ETH collector has received $16.8M USDT from 1,450 senders in two months. These aren't numbers — they're 1,450 real people whose TX history got polluted hoping they'd copy-paste the wrong address. (Read the follow-up →)

2. AI agents are about to do this at scale.
With MCP + x402, any autonomous agent can screen any address before signing — autonomously, in a single tool call. The exact attack vector I fell for — copy-paste from history,
trust-by-badge, panic-driven UX — becomes structurally impossible if the agent runs check_address_risk first.

ChainAnalyzer is one of the first AML platforms wired into both protocols.

Try It

• Scan an address for free → chain-analyzer.com

• Public ScamDB (no API key) → /scamdb

• MCP server → npx chainanalyzer-mcp

• REST API → /docs/api

• x402 endpoints → /docs/x402

If you've been drained, reach out. Send me the TX. I'll add the drainer to ScamDB. The next person who tries to send to that address will get a CRITICAL flag.

That's the whole point.

One person's \(7.95 lesson becomes another person's saved \)50,000.

Originally published at chain-analyzer.com/news/origin-drainer-story.
ENS: chainanalyzer.eth · Engineering blog

• ✅ Merged into awesome-mcp-servers

• ✅ Earned a AAA score on Glama MCP Directory

• ✅ Switched x402 from testnet to Base + Solana mainnet via the
  Coinbase CDP Facilitator

This post is a brain-dump of how each piece fits together for anyone building an MCP server with native crypto micropayments.

What is x402?

x402 is an HTTP 402 micropayment protocol from Coinbase. The flow:

1. Client calls a paid endpoint without payment headers

2. Server returns HTTP 402 Payment Required with a JSON body listing
   accepted networks, prices, and recipient addresses

3. Client signs a USDC transfer matching one of the requirements

4. Client retries with X-PAYMENT: <signed payload> header

5. Server verifies via the facilitator and returns 200 with the result

This makes per-request billing trivial for AI agents — no API key
provisioning, no subscription forms.

What is MCP?

Model Context Protocol is Anthropic's
standard for letting LLMs call tools. Any MCP-compatible client (Claude
Desktop, Claude Code, ChatGPT, Cursor, Cline, Windsurf) can use any MCP
server through a single config file.

Combining the two

Our chainanalyzer-mcp package wraps six tools:

Install:

npx -y chainanalyzer-mcp

Or add to claude_desktop_config.json:

{
  "mcpServers": {
    "chainanalyzer": {
      "command": "npx",
      "args": ["-y", "chainanalyzer-mcp"],
      "env": {
        "X402_WALLET_PRIVATE_KEY": "0x..."
      }
    }
  }
}

The X402_WALLET_PRIVATE_KEY is your spender wallet — the agent uses
it to sign USDC transfers. If you'd rather pay by subscription, set CHAINANALYZER_API_KEY=tfk_... instead.

Server-side: x402 on FastAPI

We use a custom middleware (intentionally — we wanted full control over
the Bazaar metadata + bilingual error responses). The core verification flow:

async def _verify_payment(payment: str, config: dict) -> bool:
    auth_token = _generate_cdp_jwt(
        method="POST",
        host="api.cdp.coinbase.com",
        path="/platform/v2/x402/verify",
    )
    headers = {"Content-Type": "application/json"}
    if auth_token:
        headers["Authorization"] = f"Bearer {auth_token}"

    async with httpx.AsyncClient() as client:
        resp = await client.post(
            f"{FACILITATOR_URL}/verify",
            headers=headers,
            json={"payment": payment, "requirements": {...}},
        )
        return resp.json().get("valid", False)

The CDP facilitator wants an Ed25519 JWT signed with the API key from
the CDP portal. The portal hands you
a base64-encoded private key — sign with cryptography + PyJWT:

import base64, time, uuid, jwt
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey

def _generate_cdp_jwt(method, host, path):
    seed = base64.b64decode(CDP_API_KEY_SECRET)[:32]
    sk = Ed25519PrivateKey.from_private_bytes(seed)
    now = int(time.time())
    return jwt.encode(
        {
            "iss": "cdp",
            "sub": CDP_API_KEY_ID,
            "nbf": now,
            "exp": now + 120,
            "uri": f"{method.upper()} {host}{path}",
        },
        sk,
        algorithm="EdDSA",
        headers={"kid": CDP_API_KEY_ID, "nonce": uuid.uuid4().hex},
    )

That's all. Mainnet billing is now live.

Bazaar / Agentic.Market auto-discovery

Coinbase's Bazaar crawler picks up x402 services automatically if your 402 response and /services.json manifest carry the right metadata:

ROUTE_CONFIG = {
    "GET /api/v1/x402/address/*/risk-score": {
        "price": "$0.008",
        "description": "AML risk score (5 chains, 76+ detectors)",
        "bazaar": {
            "discoverable": True,
            "category": "data",
            "tags": ["aml", "compliance", "risk-score", "blockchain"],
        },
    },
    # ... 5 more routes
}

Then expose services.json:

@router.get("/services.json")
async def x402_services_manifest():
    return {
        "id": "chainanalyzer",
        "name": "ChainAnalyzer AML API",
        "category": "data",
        "x402Version": 2,
        "networks": ["base", "solana"],
        "endpoints": [...],
    }

Bazaar requests this manifest with an empty body, validates the 402
response shape, and indexes the service. End users then find your API
on agentic.market without you submitting anything by hand.

Discoverability checklist

If you're building an MCP server that wants to be findable by agents
and humans, here's what we did (most of it transferable to any service):

1. /llms.txt + /llms-full.txt — the llmstxt.org
   convention. AI crawlers (Claude, GPT, Mistral, Perplexity) pick this
   up to summarize your product.

2. /.well-known/ai-plugin.json — older but ChatGPT custom GPTs
   still read it.

3. robots.txt — explicit Allow: for GPTBot, ClaudeBot,
   PerplexityBot, Google-Extended, Applebot-Extended. Don't rely
   on User-agent: *.

4. JSON-LD Service / SoftwareApplication schema on key pages —
   AI Overview / Bing Copilot read these.

5. IndexNow API — pings Bing/Yandex/Naver/Seznam in one HTTP call.
   Google ignores it but the cascade picks up.

6. awesome-* GitHub lists — submit a PR. Surprisingly high CTR.

7. Glama MCP Directory — submit your MCP server, then add a
   Dockerfile to score AAA on security/license/quality.

8. MCP Registry — official registry at registry.modelcontextprotocol.io.
   Submit mcp.json via PR.

What's next

We're investigating Stripe's Machine Payments Protocol
as a parallel rail (cards via Shared Payment Token + Tempo crypto), so
customers without a crypto wallet can still pay per request.

If you're shipping an MCP server and want to compare notes — drop a
comment or hit me on LinkedIn.

Originally posted at chain-analyzer.com.