DEV Community: Kenzo ARAI

Shipping a $0.008-per-call AML API on x402 (and the CDP Bazaar bug we hit on launch day)

Kenzo ARAI — Wed, 29 Apr 2026 10:26:28 +0000

TL;DR — An AI agent paid us $0.008 USDC on Base mainnet to scan a Tornado Cash address. The agent got back risk_level: CRITICAL, detection_count: 64, ml_anomaly_score: 0.4381 in about 30 seconds. No signup, no API key, no Stripe — the agent signed an EIP-3009 transferWithAuthorization, our middleware verified + settled it via the Coinbase CDP Facilitator, and the bytes flowed. Three settlements have landed since 2026-04-28. The intended next step was Coinbase Bazaar auto-indexing on agentic.market. That hasn't happened — we eventually narrowed it to a CDP-side pipeline bug (the documented EXTENSION-RESPONSES header is missing entirely on every settle, matching three other teams' independent reproductions in x402-foundation/x402#2112, #2156, #2132). We're now listed on x402scan as the alternative discovery path. Below: what x402 is, the five things we fixed on our side, the one thing CDP needs to fix on theirs, and how to call the API yourself.

Why x402 matters (in one paragraph)

The dirty secret of "AI agents using APIs" is that the API still wants a human-issued bearer token. An agent that wants new data has to either reuse one of the developer's keys (a security disaster) or stop and ask. x402 flips this: the API replies HTTP 402 Payment Required with a price, the agent signs a stablecoin transfer for that exact price, replays the request, and gets the response. No accounts. No keys. The economic unit is per-call, not per-month. For an AML / risk-scoring API like ours, this is exactly the right shape — agents pay only for the addresses they actually scan, and we don't have to gate access behind sign-ups.

Coinbase's CDP x402 facilitator does the heavy lifting (verifying signatures, broadcasting USDC transfers on Base / Solana mainnet). The promise is real. The middle, where the implementation lives, is where everything broke — first on our side (fixable), then on CDP's side (still open).

Five things that broke on our side

1. Our `_verify_payment` was sending the wrong wire format entirely

We had a pre-existing implementation that sent the facilitator something like:

{ "payment": "<base64>", "requirements": { "scheme": "exact", "price": "$0.008" } }

That is nothing like the x402 v2 spec. The CDP facilitator expects a fully-typed paymentPayload (pydantic v2 schema with accepted + payload fields) and a paymentRequirements block that names the network, asset, payTo, atomic amount, and EIP-712 metadata. Verification was failing silently, and we'd been seeing HTTP 402: payment may have failed verification for weeks without realizing the request shape itself was wrong.

Fix: Stop hand-rolling. Add x402[httpx]>=2.9.0 to requirements.txt and let the official library own the wire format:

from x402.client.facilitator.https import HTTPFacilitatorClient
from x402.types import PaymentPayload, PaymentRequirements

facilitator = HTTPFacilitatorClient(base_url=FACILITATOR_URL, auth_provider=auth)
verify_resp = await facilitator.verify(payload, requirements)

The shape the facilitator actually wants:

{
  "x402Version": 2,
  "paymentPayload": {
    "x402Version": 2,
    "payload": { "signature": "0x...", "authorization": { "...": "..." } },
    "accepted": {
      "scheme": "exact",
      "network": "eip155:8453",
      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "amount": "8000",
      "payTo": "0xe8e26183...708959",
      "maxTimeoutSeconds": 60,
      "extra": { "name": "USD Coin", "version": "2" }
    },
    "resource": { "url": "...", "description": "...", "mimeType": "application/json" }
  },
  "paymentRequirements": {
    "scheme": "exact",
    "network": "eip155:8453",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "amount": "8000",
    "payTo": "0xe8e26183...708959",
    "maxTimeoutSeconds": 60
  }
}

2. There was no `_settle_payment` call at all

Even if /verify had ever passed, no USDC would have moved. The middleware had no /settle step. The contract for x402 is verify → handler → settle, and we were stopping at verify.

Fix: Wire the full middleware:

async def x402_middleware(request, call_next):
    payload = _decode_payment_payload(request.headers["X-PAYMENT"])
    requirements = _requirements_for_payload(payload, accepts)

    verify_resp = await facilitator.verify(payload, requirements)
    if not verify_resp.is_valid:
        return _402(reason=verify_resp.invalid_reason)

    response = await call_next(request)

    # Only settle if the handler succeeded — failed scans don't get charged
    if 200 <= response.status_code < 300:
        settle_resp = await facilitator.settle(payload, requirements)
        if settle_resp.success:
            response.headers["X-PAYMENT-RESPONSE"] = b64_encode(settle_resp.json())

    return response

The "only settle on 2xx" rule is important: if the AML scan crashes mid-flight, the agent shouldn't be charged. Conversely, once the data is over the wire, there is no rollback — settle is the commit.

3. CDP credentials were never injected into the container

The Azure secrets cdp-api-key-id and cdp-api-key-secret had been provisioned weeks ago. They just weren't being passed as env vars to the running container. So _generate_cdp_jwt() was returning None silently, the facilitator client was sending unauthenticated requests, and CDP was rejecting them.

Fix: Two-line patch to the deploy script:

# scripts/azure-deploy.sh
az containerapp update ... \
  --set-env-vars \
    ... \
    CDP_API_KEY_ID=secretref:cdp-api-key-id \
    CDP_API_KEY_SECRET=secretref:cdp-api-key-secret

Generic lesson: provisioning a secret in Key Vault and referencing it from the container app are two different deploys. Check both.

4. The SvelteKit catch-all proxy was stripping `X-PAYMENT`

We have a generic /api/v1/[...path]/+server.ts that proxies the SvelteKit edge to the Python backend. It was forwarding X-API-Key and Content-Type and nothing else. The browser-side x402 demo would sign correctly, attach X-PAYMENT, and watch it disappear by the time the request hit Python.

Fix: Forward x402 protocol headers explicitly, plus CORS preflight allow-list:

const FORWARD_HEADERS = ["x-api-key", "x-payment", "payment-signature", "content-type"]

// On the OPTIONS preflight:
"Access-Control-Allow-Headers": "X-API-Key, X-Payment, Payment-Signature, Content-Type"

We also moved the demo to the dedicated /x402/api/... route which has x402-aware proxy logic, leaving the generic catch-all for plain REST traffic.

5. Our demo wallet self-transferred to the treasury

The browser demo connected Phantom and signed a transferWithAuthorization from the connected account to the treasury payTo — except the connected account was the treasury. EIP-3009 has no problem with that (you can sign a transfer from yourself to yourself), but the facilitator's verifier rejected it because the signed from matched the platform's payTo, which it correctly read as a self-payment loop, not a real customer payment.

Fix: Cheap client-side guard:

if (account.toLowerCase() === acceptEntry.payTo.toLowerCase()) {
  throw new Error(
    "Connected wallet is the treasury — switch to a different account to test."
  )
}

Once we connected from a fresh wallet (a separate Phantom account funded with $0.50 of USDC), the signature went through. The buyer's wallet, the treasury, and the facilitator are all different parties — they have to be.

What a successful settlement actually looks like

After all of the above, the production curl is anticlimactic:

curl -i \
  -H "X-PAYMENT: $(./build_payment.ts $WALLET 0.008 USDC base)" \
  https://chain-analyzer.com/x402/api/address/0x0000db5c8b030ae20308ac975898e09741e70000/risk-score?chain=ethereum

# HTTP/2 200
# X-PAYMENT-RESPONSE: eyJzdWNjZXNzIjp0cnVlLCJ0eEhhc2giOiIweGFiYy4uLiJ9
# Content-Type: application/json
#
# {
#   "address": "0x0000db5c8b030ae20308ac975898e09741e70000",
#   "chain": "ethereum",
#   "risk_level": "CRITICAL",
#   "risk_score": 95,
#   "detection_count": 64,
#   "ml_anomaly_score": 0.4381,
#   "detections": [
#     { "id": "OFAC_SANCTIONED", "severity": "CRITICAL", ... },
#     { "id": "TORNADO_CASH_INTERACTION", "severity": "CRITICAL", ... },
#     { "id": "ADDRESS_POISONING_RECEIVED", "severity": "HIGH", ... },
#     ...
#   ]
# }

X-PAYMENT-RESPONSE is the base64-encoded settle receipt — the agent can decode it to get the on-chain tx hash and confirm the USDC really moved on Base. That's the loop closed: agent paid, scan ran, agent got data, settlement is on-chain. Three of these have landed for us across 2026-04-28 / 2026-04-29.

What's still broken on CDP's side: Bazaar `agentic.market` indexing

The plan was simple: a successful settlement on a route that carries extensions.bazaar.discoverable=true triggers Coinbase's Bazaar pipeline to crawl the manifest and add the resource to agentic.market. We shipped the metadata, settled the payments, and waited.

It didn't happen. After three settlements over 36 hours, the resource is still not in the Bazaar discovery index, and /discovery/merchant?payTo=... returns 404.

The diagnostic signal in the Bazaar Indexing Process docs is the EXTENSION-RESPONSES header on the facilitator's /verify and /settle responses:

Header value	Meaning
`processing`	Bazaar accepted the metadata, async indexing in flight
`rejected`	Bazaar rejected (schema / mimeType / etc.)
missing	Bazaar pipeline never received the metadata (CDP-side issue)

To see which case applies to us we patched httpx.AsyncClient.send inside the FastAPI process to log every facilitator response header before any middleware touched it. The header is absent in every casing on every settlement we've made. Not processing, not rejected, just nothing.

This puts us in the same spot as three other teams that filed reproductions:

x402-foundation/x402#2112 — siggy (rtkmotion.io) captured the same absence at the Cloudflare Worker level on Base mainnet, across nine settlements
Same thread — srotzin (HiveCompute) reproduced it on Solana / USDT
#2156 — third independent stack, agentic.market still empty after 8 settlements
#2132 — our own ecosystem-listing request, also pending

Across the four reproductions, the only commonality is that every payTo address is a non-CDP-registered EOA (we generated ours outside the CDP wallet system). The current strongest hypothesis — not yet confirmed by Coinbase — is that the Bazaar pipeline is gated on payee wallets being CDP-account-linked, and the missing header is a symptom of that gating happening silently. If true, this is a one-line documentation fix on CDP's side that would have saved every team filing into those issues a week of metadata iteration.

There's nothing we can change on our end to make Bazaar pick us up today. The metadata is correct (it matches Sentinel AML's catalogued listing structure), the settlements are real, the manifest is live. We're waiting on CDP.

Listed on x402scan instead

Bazaar isn't the only x402 discovery layer. x402scan (run by Merit-Systems) is an independent ecosystem explorer that crawls services via /.well-known/x402. Submitting our discovery doc registered five GET endpoints with full activity tracking inside ~10 seconds:

www.x402scan.com/server/78ee8ac2-bc8c-4d44-a565-45ead6dd5364

Getting through their probe required two extra fixes that the CDP-only path didn't surface:

Emit a base64 Payment-Required header alongside the JSON body. The validator (@agentcash/discovery v1.6.x) reads the v2 challenge from a header — base64-decoding atob(headerValue) to get the payload — and falls back only to a v1 JSON body parser if absent. Our v2 JSON body wasn't enough on its own. We now emit both: the rich body for CDP / x402-fetch and a flattened Coinbase-schema header for any v2 strict validator.
Add a bazaar.schema.properties.input.properties.{body|queryParams} block. agentcash's extractSchemas2 only recognises body or queryParams for input — it does not look at pathParams, which is where our existing bazaar.info block had the field definitions. We now synthesize a parallel schema block at request time so the same field names show up under both keys.

With those in place, x402scan picked up all five GET routes (the POST-only batch/screening is still excluded — their probe is GET-only, so a 405 from a POST endpoint counts as failed registration). Our build notes from this debug session are in the @agentcash/discovery issue tracker for anyone hitting the same wall.

Try it yourself

There are three reasonable on-ramps depending on what you're holding:

a) `curl` from a TypeScript helper

If you have a wallet on Base with a few cents of USDC:

import { createWalletClient, custom } from "viem"
import { base } from "viem/chains"

// Browser: connect Phantom (or any EIP-1193 wallet) to Base mainnet
const wallet = createWalletClient({
  chain: base,
  transport: custom(window.phantom.ethereum),
})
const [account] = await wallet.requestAddresses()

// Sign EIP-3009 transferWithAuthorization for $0.008 USDC, replay
// the request with X-PAYMENT — middleware verifies + settles via the
// Coinbase CDP facilitator, then returns the risk-score JSON
const res = await fetch(
  "https://chain-analyzer.com/x402/api/address/" +
    "0x0000db5c8b030ae20308ac975898e09741e70000/risk-score?chain=ethereum",
  { headers: { "X-PAYMENT": buildPayment(account, /* ... */) } },
)
const score = await res.json()
// score.risk_level === "CRITICAL", score.detection_count === 64

b) The browser demo

chain-analyzer.com/x402-demo.html connects Phantom on Base, lets you punch in any address, and runs the full pay → scan → settle flow with a visible tx hash at the end. Costs you $0.008 + Base gas (a few cents).

c) Through an MCP-aware AI agent

If you're using Claude or any MCP client, our chainanalyzer-mcp package exposes the same endpoints as MCP tools. The agent handles the x402 dance for you — you just say "scan this address" in natural language.

The endpoint menu

Method	Endpoint	Use case	Price
GET	`/x402/api/address/{addr}/risk-score`	0–100 risk score + detection list	$0.008 USDC
GET	`/x402/api/address/{addr}/sanctions`	OFAC / FATF / JFSA sanction list match	$0.003 USDC
GET	`/x402/api/tx/{tx_hash}/trace`	Multi-hop fund flow trace	$0.015 USDC
GET	`/x402/api/tx/{tx_hash}/coinjoin`	CoinJoin / mixer detection	$0.01 USDC
GET	`/x402/api/wallet/{addr}/cluster`	Common-spend wallet clustering	$0.02 USDC
POST	`/x402/api/batch/screening`	Batch address screening (≤50 per call)	$0.05 USDC

Chain coverage: 8 chains live for self-serve via the ?chain= query parameter — bitcoin, ethereum, polygon, base, arbitrum, optimism, avalanche, solana. BNB Smart Chain is on Enterprise rollout (paid Etherscan tier required) and is reachable through the subscription API key path, not via x402.

The full advertised manifest is at chain-analyzer.com/.well-known/x402 — that's the file the x402scan crawler reads, and the same one CDP's Bazaar crawler is supposed to read once the upstream pipeline is fixed.

The bigger picture

We didn't build x402 support to chase a buzzword. We built it because AI agents are the natural buyers of AML data — they don't have personal addresses, they don't sign up for SaaS plans, they need to know in 30 seconds whether the wallet on the other side of a transaction is a Tornado Cash router or a normie. Sign-up forms and quarterly contracts don't fit that workload. Pay-per-call USDC does.

The settlement layer works. The Coinbase Bazaar discovery layer is, today, blocked on a CDP-side bug we can't reach into. The x402scan discovery layer works fine. If you're a team about to ship x402 with a non-CDP-registered payee EOA, you'll likely hit the same Bazaar wall — file into #2112 so the signal reaches Coinbase, and submit your service to x402scan in parallel so your endpoints are reachable in the meantime.

The per-call cost of plugging an autonomous agent into multi-chain AML data is now half a US cent. That's where the agent economy is going, and we'd rather be on the supply side.

$5.3M Address Poisoning Network — 2 Months Later: The Follow-Up

Kenzo ARAI — Wed, 29 Apr 2026 10:17:57 +0000

By refinancier, inc. / ChainAnalyzer — 2026-04-20

TL;DR — On 2026-02-17 we published an investigation identifying a cross-chain address poisoning network moving $5.3M across Avalanche, Ethereum, and Polygon, with 264+ operator wallets funded by a single "Master Funder" (0x54cdcbdb...). Two months later, we returned to the same wallets. The network is still active, the Master Funder has disbursed another $1.24M in AVAX to 854 new destination addresses, and the Ethereum collector received $16.8M USDT during the interval. We also re-classified two addresses we had previously labeled as "whale funders" — they are almost certainly exchange / OTC hot wallets, not co-conspirators. Full comparison below.

Recap — What We Found in February 2026

In February 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 0x54cdcbdba40e294e8832230db706cee76e1f20f3 — 16,226 AVAX balance, 1,585 recipients, of which 53% were confirmed poisoning operators
Two collectors: Ethereum (0xbca34ed5... = $2.67M USDT) and Polygon (0xa6380bfd... = $788K USDC)
Proven relay pattern: on Polygon, a victim sent 2,800 USDC to a relay wallet after seeing a look-alike address in their history; 34 minutes later that USDC was forwarded to the collector

For the full February findings: original investigation writeup.

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

Follow-Up Methodology

On 2026-04-20 we pulled on-chain state for every address flagged in the February report, using:

Routescan (Avalanche C-Chain, keyless)
Etherscan V2 (Ethereum + Polygon, same API key)
ChainAnalyzer's own Neo4j graph for cross-chain correlation

For each address we compared:

Native token balance (Feb 17 → Apr 20)
Last transaction timestamp
Stablecoin holdings (USDT, USDC, USDC.e, POL)
New funding activity since 2026-02-17
Contract deployment activity (for the fake-token deployer)

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

Headline Deltas

Address	Role	Feb 17, 2026	Apr 20, 2026	Delta
`0x54cdcbdb`	Master Funder	16,226 AVAX	12,254 AVAX	−3,972 AVAX (disbursed)
`0x54cdcbdb`	Master Funder	1,585 recipients (cumulative)	2,439+ recipients	+854 new destinations in 2 months
`0xbca34ed5`	ETH Collector	$2.67M USDT	$5.97M USDT	+$3.30M (+124%)
`0xa6380bfd`	POL Collector	249K POL + $788K USDC	511K POL + $348K USDC	+262K POL, −$440K USDC (laundered out)
`0xa081aa46`	POL mass-poison funder	Balance: $12.55	23,435 POL (~$24K)	+1,870×
`0x3bce63c6`	"142K AVAX whale"	141,904 AVAX	168,901 AVAX	+27K AVAX
`0x9f8c163c`	"Top source"	(only 5,077 AVAX traced)	1,688,967 AVAX (~$42M)	(full profile now visible)
`0xb2de52d8`	Primary operator	Active until 2026-02-15	Dead — no activity since 2026-02-15	✅ rotated out
`0x03309000`	Active operator	Active 2026-02-17	Depleted across 3 chains — last AVAX activity 2026-04-15	✅ rotated out
`0x4226dd74`	Main deployer (39 fake contracts)	1.46 AVAX, active	Still active as of 2026-04-20 06:39 UTC	Still used for poisoning — no NEW deployments
`0x64424853`	Lisu deployer (cross-chain)	Active	Dormant since 2025-12-23	Likely retired

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 fetched the most recent 10,000 transactions from the Master Funder (0x54cdcbdb). After filtering to outflows since 2026-02-17, the numbers are:

1,119 outbound AVAX transfers
Total sent: 49,441 AVAX (~$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.

The top ten new destinations since Feb 17:

Destination	AVAX received	First TX	Last TX	TX count
`0x33a089cb`	9,722	2026-03-02	2026-03-02	1
`0xf57a1140`	9,297	2026-03-13	2026-03-13	1
`0x6f7e6fdf`	7,622	2026-04-02	2026-04-02	1
`0xd7b9b792`	3,677	2026-03-10	2026-04-19	38
`0x0808469a`	1,794	2026-02-20	2026-03-10	13
`0xeae12a48`	1,389	2026-04-10	2026-04-10	2
`0xe36d6080`	1,061	2026-03-04	2026-04-02	3
`0x6632f500`	1,032	2026-02-24	2026-03-06	3
`0x89b8678f`	856	2026-04-03	2026-04-18	10
`0x951aa58d`	844	2026-02-17	2026-04-17	7

Four patterns jump out:

Single large bursts to fresh wallets (9,722 / 9,297 / 7,622 AVAX in one transaction, then the destination goes quiet). Classic "seed a new operator and let it run autonomously" behavior.
Steady multi-TX relationships with certain destinations (0xd7b9b792 received 38 separate transfers between Mar 10 and Apr 19). These look like infrastructure wallets rather than operators — possibly paying gas or topping up the deployer.
Continuity with the old network — the address 0x0808469a that was the top operator in the February report received another 1,794 AVAX between Feb 20 and Mar 10, then went dormant again.
Activity continuing to today — 0xd7b9b792 last received AVAX on 2026-04-19, 24 hours before we ran this query.

gantt
    title Master Funder outflow velocity
    dateFormat YYYY-MM-DD
    axisFormat %b-%d
    section Before investigation
    Lifetime recipients (1585)   :done, 2022-10-01, 2026-02-17
    section Since Feb 17 report
    New recipients (+854)        :active, 2026-02-17, 2026-04-20

The investigation exposing this network did not 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 had not fully traced. We tentatively labeled it "TOP SOURCE."

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 at $25/AVAX)
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 (2026-04-20 06:32 UTC):
- Hundreds of 0-value transfer calls per day to the same destination (0x26debd39...) — classic hot-wallet idle ping / smart-contract calldata pattern
- Occasional execute calls on 0xee7ae85f... — looks like a router or batcher
- Small transfer operations to fresh addresses with amounts that resemble customer withdrawals (0.19 AVAX, 1.36 AVAX, 25 AVAX)
Active on Ethereum (3 TXs) and Polygon (5 TXs) 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 poisoning 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, we revise our view of 0x3bce63c6 ("142K AVAX whale"). Current balance 168,901 AVAX, active today (last activity 2026-04-20 06:40 UTC), high-frequency 0-value calls to the same contract endpoints as 0x9f8c163c, occasional outbound payments of various sizes to fresh wallets. 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 a SAR-worthy report to those exchanges if you're an agency.

3. Collectors: The Laundering Front-End Is Busier Than Ever

The two collector addresses — 0xbca34ed5 on Ethereum and 0xa6380bfd on Polygon — are the points where victim funds converge. Their 2-month activity is the best single indicator of whether victims are still being extracted.

Ethereum collector `0xbca34ed5`

Metric	Feb 17	Apr 20
USDT balance	$2,665,507	$5,970,800 (+124%)
USDT received since Feb 17	—	$16,865,450 from 1,450 unique senders (2,574 TXs)
USDT sent out since Feb 17	—	$15,134,814 (5,693 TXs)
Last activity	—	2026-04-20 06:38 UTC

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.

We flagged in February that the Ethereum collector is primarily a trading hub with poisoning as a side channel, and that characterization still fits — but the side channel is much larger than it appeared.

Polygon collector `0xa6380bfd`

Metric	Feb 17	Apr 20
USDC balance	$788,521	$348,256 (−56%)
POL balance	249,588	511,722 (+106%)
USDC received since Feb 17	—	$1,201,642 from 1,100 unique senders (2,111 TXs)
USDC sent out since Feb 17	—	$1,633,777 (3,399 TXs)
Last activity	—	2026-04-20 06:40 UTC

The USDC balance dropped because they are laundering it downstream, not because victim flow stopped. In fact, the opposite: 1,100 unique senders in two months is up from the 715 total sender count we observed in February. The relay pattern we documented in February (victim → relay → collector within ~34 minutes) is still producing the majority of those inflows.

The POL balance more than doubled, suggesting profit-taking or gas/ops reserves building up.

flowchart LR
    subgraph "Feb 17, 2026 — Snapshot"
    A1[1,585 MF recipients]
    B1[ETH col: $2.67M USDT]
    C1[POL col: 249K POL + $788K USDC]
    end

    subgraph "Apr 20, 2026 — Follow-up"
    A2[2,439+ MF recipients<br/>+854 in 60 days]
    B2[ETH col: $5.97M USDT<br/>+$3.3M net, $16.8M gross flow]
    C2[POL col: 511K POL + $348K USDC<br/>$1.2M gross inflow from 1,100 senders]
    end

    A1 -->|60 days| A2
    B1 -->|60 days| B2
    C1 -->|60 days| C2

4. Wallet Rotation Was Real

One thing we theorized in February was that operator wallets are disposable — used for a few weeks, then retired as new ones spin up. The data now confirms it:

Primary operator 0xb2de52d8 — last activity 2026-02-14, 3 days before we published. Dead ever since. Balance: 0 AVAX.
Active operator 0x03309000 — was active on all three chains in February. Today:
- AVAX: depleted, last TX 2026-04-15 (5 days before we pulled this data)
- ETH: depleted, last TX 2026-03-04
- POL: 0.001 POL, last TX 2026-02-25
Top operator 0x0808469a — received another 1,794 AVAX in late Feb to early March, then quiet again. 80 AVAX remains.
Lisu deployer 0x64424853 — dormant since 2025-12-23. No new Lisu-script contracts since.

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.

This has an interesting 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 at 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. We flagged this as one of the highest-ROI crimes we'd ever seen and suggested that even a single successful victim would 100x the investment.

Today, that address holds 23,435 POL (~$24K at $1/POL). It is still active — last transaction 2026-04-20 00:14 UTC, six hours before we queried it.

From $12.55 to $24,000+. A 1,870× return on capital in roughly 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 to victims. The deployer address itself is active (last TX 2026-04-20 06:39 UTC), but it's doing operational transactions, not creation transactions. The fake-token inventory from late 2025 is sufficient to run the whole operation — no need to paint new decoys.

This matters because typical "contract creation detection" signals would miss this operator entirely during the period they're most active.

Updated Network Topology

flowchart TD
    subgraph "Exchange / OTC layer (not co-conspirators)"
      TS[0x9f8c163c<br/>CEX hot wallet<br/>1.69M AVAX today]
      WHALE[0x3bce63c6<br/>OTC/hot wallet<br/>168.9K AVAX today]
    end

    MF[MASTER FUNDER<br/>0x54cdcbdb<br/>12,254 AVAX<br/>2,439+ lifetime recipients<br/>ACTIVE 2026-04-20]

    subgraph "Operator layer — rotating"
      OLD[Feb-era operators<br/>most retired]
      NEW[854 new recipients<br/>Feb 17 – Apr 20]
    end

    DEP1[Main deployer 0x4226dd74<br/>39 contracts, no new deploys]
    DEP2[Lisu deployer 0x64424853<br/>DORMANT]

    POISON[6,892+ poisoned addresses<br/>3 chains]

    ETHCOL[ETH collector 0xbca34ed5<br/>$5.97M USDT<br/>+$16.8M gross in 60 days]
    POLCOL[POL collector 0xa6380bfd<br/>$348K USDC + 511K POL<br/>$1.2M gross in 60 days]

    TS -->|CEX withdrawal| MF
    WHALE -->|CEX withdrawal| MF
    MF -->|AVAX seed| OLD
    MF -->|AVAX seed| NEW
    OLD -->|already retired| POISON
    NEW -->|currently active| POISON
    DEP1 -->|fake contracts| POISON
    DEP2 -->|contracts abandoned| POISON
    POISON -->|relay chains| ETHCOL
    POISON -->|relay chains| POLCOL

What This Changes

For victims and potential victims:

The network exposing itself to public investigation did not cause it to shut down. If anything, it accelerated recruitment. That means every protective behavior we recommended in February still applies, with more urgency:

Never copy an address from your transaction history. Use your address book, or re-verify from the source.
Compare addresses character-by-character, not by first-4 / last-4.
Suspicious tokens arriving in your wallet are not a gift — they are a marker that you are already being targeted for the next step.
Before sending funds, screen the destination address. ChainAnalyzer does this for 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 sent funds to wallets that seeded 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, not at the static address level. ChainAnalyzer's detector suite is explicitly designed around this:

P2 ADDRESS_POISONING detector for Unicode impersonation signatures on token transfers
W9 BRIDGE_FUNDED / W10 PRIVACY_BRIDGE_FUNDED detectors for cross-chain laundering
Follow Mode for automatic BFS graph exploration of related addresses
Exchange DB with 60+ known CEX hot wallets (and growing) to correctly attribute funding sources

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.

Methodology Notes

All data in this article was pulled on 2026-04-20 between 06:20 and 06:45 UTC using:

Routescan ( https://api.routescan.io/v2/network/mainnet/evm/43114/etherscan/api ) — Avalanche C-Chain, free, keyless
Etherscan V2 ( https://api.etherscan.io/v2/api?chainid=1 for Ethereum and chainid=137 for Polygon ) — free API key

Query patterns:

Native balance: module=account&action=balance
ERC-20 balance: module=account&action=tokenbalance&contractaddress=<token>
Transaction list: module=account&action=txlist (10K TX limit per call per address, sort=desc)
Token transfer list: module=account&action=tokentx (10K TX limit per call)

Cutoff for "since Feb 17, 2026": Unix timestamp 1771200000 (2026-02-16 00:00 UTC).

Every balance and transaction count above is reproducible against public on-chain data.

Takeaways

The $5.3M network is now materially larger than it was when we published the February report. The investigation publicity did not deter it; it accelerated.
854 new operator wallets have been funded by the single Master Funder in 60 days. The operator population rotates on a 2-3 month cycle.
The Ethereum collector processed $16.8M USDT from 1,450 senders during the interval; the Polygon collector processed $1.2M USDC from 1,100 senders. Real victims, real money, active every day.
Two addresses we previously labeled as "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 are sufficient inventory for the whole operation. Contract-creation-based detection misses this.
For retail Web3 users, 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 will 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.

Appendix A — All Key Addresses

Avalanche

Master Funder: 0x54cdcbdba40e294e8832230db706cee76e1f20f3
Main deployer: 0x4226dd7419b1431f512d82a2c9e5fa1597fb1077
Primary operator (retired): 0xb2de52d8838aa450d9e97cba8624d77f3b82d298
Previously active operator: 0x03309000ee1481fef75e6be3bb91ff38c6f7f5ca
Likely CEX hot wallet #1: 0x9f8c163cba728e99993abe7495f06c0a3c8ac8b9
Likely CEX hot wallet #2: 0x3bce63c6c9abf7a47f52c9a3a7950867700b0158

Ethereum

ETH collector: 0xbca34ed5875079cc561840f3409a790769821dbc

Polygon

POL collector: 0xa6380bfda5986782a15e3e285a1743aee8523f97
Mass-poisoning funder: 0xa081aa46c83c1f7afc1550e68260b28caeba896f

Appendix B — Try It Yourself

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

# REST API (subscription)
curl -H "X-API-Key: tfk_..." \
  "https://chain-analyzer.com/api/v1/public/scan?address=0x54cdcbdba40e294e8832230db706cee76e1f20f3&chain=avalanche"

# x402 USDC micropayment (no account needed, $0.008 / call)
curl "https://chain-analyzer.com/x402/api/address/0x54cdcbdba40e294e8832230db706cee76e1f20f3/risk-score"

# MCP (from Claude Desktop, Claude Code, ChatGPT, Gemini, Cursor…)
# After configuring chainanalyzer-mcp, just ask your AI: "scan 0x54cdcbdb..."

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

Investigation by refinancier, inc. All data from public on-chain sources. ChainAnalyzer is a multi-chain AML and security intelligence platform. Contact us for enterprise or law-enforcement engagement.

Drained for $7.95 — How a Solana Phishing Attack Became a Multi-Chain AML Platform

Kenzo ARAI — Wed, 29 Apr 2026 10:14:05 +0000

Every product has an origin story. Ours starts with the founder getting drained for $7.95 on a Sunday afternoon in a Discord server he thought he could trust.

Two months later, that $7.95 lesson turned into the first entry of a crypto scam database. Four months later, it turned into a multi-chain AML platform. Today it powers ChainAnalyzer, covers 9 blockchains (8 live for self-serve, BNB Smart Chain on Enterprise rollout) with 76+ detection rules, an MCP server on the official registry, an x402 pay-per-call API listed on x402scan, and is being used in enterprise-grade transaction monitoring for Japanese stablecoin operators.

This is the full story of how that happened — and why it matters.

The Drain — 2026-02-09, 14:28 UTC

I was in the Orynth Discord. Regular member, followed the project for months.

A post appeared in the #FCFS channel from an account with ORY admin badge. First-come-first-served airdrop. Link to solland.cc. That redirected to hibit.app. Big "Claim" button. Connect wallet → sign → done.

Except "done" meant "your SOL just went to the drainer."

Detail	Value
Loss	0.093668917 SOL (~$7.95)
Attack method	System Program Transfer disguised as a Claim
Drainer address	`7kMpieh2THdaC5eUvxFJDL3TdsQWVQCwdhsEjLj1eL26`
Domains	`solland.cc`, `hibit.app`
Entry point	Compromised ORY admin account on Discord
Transaction	Solscan

The punchline isn't the loss — it's that I fell for it because the account had the admin badge. Authority-based trust, weaponized. If I could fall for it after years in crypto, anyone could.

What I Did the Next 48 Hours

Instead of posting a warning on Twitter and moving on, I dug in.

I traced the drainer wallet. It had been funded via FixedFloat (KYC-free exchange) and was laundering via Jupiter swap (SOL → USDT) before moving everything back out through FixedFloat. Within hours of my drain, the same wallet hit multiple other victims with Flip.gg and "FREE Spins" lures. It had stolen $3,700+ total across at least 3,640 USDT and 0.67 SOL across dozens of victims over the prior two weeks.

This wasn't an opportunist. It was a pipeline:

flowchart LR
    FF[FixedFloat<br/>KYC-free exchange] -->|SOL funding| D[Drainer Wallet<br/>7kMpieh2TH...j1eL26]
    C[Compromised Orynth<br/>admin account] -->|posts solland.cc| V[Victim — me]
    V -->|signs tx| D
    D -->|Jupiter swap| U[USDT]
    U -->|withdrawal| FF

Same pattern, industrialized. That's when I realized: the problem wasn't "I made a mistake." The problem was that no tool existed that would have caught this before I signed.

Existing scanners could tell you if a token was a rug. None of them could tell you "hey, this address you're about to send SOL to has already drained 40 people this week."

ScamDB Entry #1

Before I wrote a single line of UI code, I started a JSON file called scamdb.json. The first entry:

{
  "id": "SCAM-001",
  "drainer_address": "7kMpieh2THdaC5eUvxFJDL3TdsQWVQCwdhsEjLj1eL26",
  "domains": ["solland.cc", "hibit.app"],
  "method": "FCFS airdrop phishing → System Program Transfer",
  "source": "Orynth Discord (compromised admin account)",
  "reported_at": "2026-02-09T14:28:33Z",
  "reported_by": "ChainAnalyzer founder (firsthand victim)",
  "drainer_profile": {
    "total_stolen": "$3,700+",
    "assets": "3,640 USDT + 0.67 SOL",
    "laundering": "Jupiter (SOL→USDT) + FixedFloat withdrawal",
    "funded_by": "FixedFloat Exchange (KYC-free)"
  }
}

That entry still lives in the production ScamDB today. And it's still the index-1 row in our database. Every scan that ChainAnalyzer does checks against this and ~100+ other curated entries, plus OFAC SDN, Chainabuse, CryptoScamDB, GoPlus, and community reports.

The $7.95 is the most valuable $7.95 I've ever spent.

From TokenForge to ChainAnalyzer

The consumer product we shipped in February 2026 was called TokenForge. Solana-only, 14 detection rules, one-click scan of any mint address or wallet. No login required. Free.

Two weeks in, something unexpected happened: a friend was investigating an Avalanche address and asked if I could scan it. 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 support. Then Ethereum. Then Polygon. Bitcoin later.

Then I pointed the scanner at that Avalanche address. It flagged CRITICAL with 20 detections. I turned on Follow Mode — a graph exploration 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 nicknamed "Master Funder." (Full investigation writeup →)

That's when I realized what I was actually building. Not "a consumer scam scanner." An AML-grade investigation platform for the retail Web3 era.

In March 2026, we rebranded to ChainAnalyzer and pivoted toward enterprise AML:

Multi-chain support (9 chains supported, 8 live for self-serve, BNB Smart Chain on Enterprise rollout, 76+ detectors)
Bitcoin coverage that most Chainalysis-style competitors deprioritize
ML anomaly scoring (Isolation Forest + Autoencoder + GraphSAGE ensemble)
Neo4j graph analysis for fund flow reconstruction
PDF compliance reports for Japanese regulatory hand-off
REST API + MCP server + x402 micropayments (listed on x402scan)

What Changed Between TokenForge and ChainAnalyzer

	TokenForge (2026-02)	ChainAnalyzer (2026-04)
Chains	Solana only	9 supported (BTC, ETH, POL, BASE, ARB, OP, AVAX, SOL live + BSC Enterprise rollout)
Detection rules	14	76+
OSINT	Our ScamDB	ScamDB + OFAC + Chainabuse + GoPlus + Reddit
ML	None	3-model ensemble
Audience	Retail Solana traders	Exchanges, compliance teams, law enforcement
Differentiator	Fill Solana OSINT gap	$5.3M network discovery, JPYC stablecoin AML coverage, native Japanese-language compliance UX
Interfaces	Web UI only	Web UI + REST API + MCP + x402 + PDF reports

What stayed the same: every feature is still exercised against the kind of attack that cost me $7.95.

Lessons I Wish Someone Had Told Me

1. Admin badges mean nothing. Discord/Telegram admins get their accounts taken over constantly. Treat a post in your favorite project's server the same way you'd treat a cold DM from a stranger.

2. "Connect wallet" is not a safe operation. The moment you approve a transaction, you've taken an action with financial consequences. Read what you're signing. If you can't read what you're signing, don't sign.

3. Address-first verification. Before sending anything, scan the destination address in a tool like ChainAnalyzer. If it's been reported, you'll know. If it shows graph proximity to known drainers, you'll know. Takes three seconds.

4. FCFS airdrops are always scams. Real projects don't panic people into signing instantly. The urgency is the tell.

5. Post-mortem immediately. When you lose money, trace what happened on-chain before you spiral emotionally. Understand the attack. That understanding is more valuable than the money you lost.

Where We Are Today

ChainAnalyzer now:

Processes scans across 9 chains (8 live for self-serve, BNB Smart Chain on Enterprise rollout)
Runs on Azure Japan East, FISC-aligned hosting
Has 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 — $0.003 to $0.05 per call, no API key, no subscription, listed on x402scan
Ships a JPYC-specific compliance suite for Japanese stablecoin issuers and handlers

All from a $7.95 drain two months ago.

What's Next

Two things pulling 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 the wrong address. Read the follow-up investigation.

2. AI agents are about to do this at scale. With MCP + x402, any autonomous agent can now screen addresses before signing. The attack vector I fell for — copy-paste from history — becomes impossible if the agent runs check_address_risk first. This is the biggest single leverage point for retail Web3 safety in years, and ChainAnalyzer is one of the first AML tools wired up to it.

Try It

Scan an address for free: https://chain-analyzer.com
Look up the ScamDB (public, no API key): https://chain-analyzer.com/scamdb
MCP server: npx chainanalyzer-mcp
REST API: https://chain-analyzer.com/en/docs/api
x402 endpoints: https://chain-analyzer.com/en/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.

refinancier, inc. is a Tokyo-based fintech company. We operate ChainAnalyzer, a multi-chain AML & security intelligence platform. Contact: https://chain-analyzer.com/en/contact_us

Shipping x402 USDC Payments to Base + Solana Mainnet for an MCP Server

Kenzo ARAI — Sat, 25 Apr 2026 13:22:00 +0000

Last week, ChainAnalyzer (a multi-chain blockchain AML platform) crossed

three milestones in five days:

✅ 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:

Client calls a paid endpoint without payment headers
Server returns HTTP 402 Payment Required with a JSON body listing accepted networks, prices, and recipient addresses
Client signs a USDC transfer matching one of the requirements
Client retries with X-PAYMENT: <signed payload> header
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:

Tool	Price (USDC)
`check_address_risk`	$0.008
`sanctions_check`	$0.003
`trace_transaction`	$0.015
`detect_coinjoin`	$0.01
`cluster_wallet`	$0.02
`batch_screening`	$0.05

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):

/llms.txt + /llms-full.txt — the llmstxt.org convention. AI crawlers (Claude, GPT, Mistral, Perplexity) pick this up to summarize your product.
/.well-known/ai-plugin.json — older but ChatGPT custom GPTs still read it.
robots.txt — explicit Allow: for GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended. Don't rely on User-agent: *.
JSON-LD Service / SoftwareApplication schema on key pages — AI Overview / Bing Copilot read these.
IndexNow API — pings Bing/Yandex/Naver/Seznam in one HTTP call. Google ignores it but the cascade picks up.
awesome-* GitHub lists — submit a PR. Surprisingly high CTR.
Glama MCP Directory — submit your MCP server, then add a Dockerfile to score AAA on security/license/quality.
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.