Binance drain, the TRON leg: a 46-minute freeze, the deposit-receipt escape, and tracing that follows receipts as value

TL;DR — On the TRON leg of the Binance drain, Tether froze the receiving address 46 minutes 27 seconds after 612,729,468 USDT left the hot wallet. Five minutes after that freeze, the attacker made a test deposit into a lending protocol. A lending deposit receipt cannot be frozen by the issuer, so moving the receipt to a new wallet and redeeming there stays one step ahead of the blacklist. ChainAnalyzer now traces stolen funds on TRON, treats deposit receipts as value, recognises TRON exchange hot wallets, and follows three hops instead of two. Twenty-one wallets created after the drain deposited 7.07M USDT into lending; for six of them (1,638,894 USDT) the TRX came straight from the attacker.

What happened on TRON, as far as the chain shows

The previous post covered the EIP-7702 sweep on Ethereum. The same night, funds also left the TRON hot wallet "Binance-Hot 7". Every timestamp below comes from the TRON ledger and Tether's freeze events.

On TRON, 378.7M USDT ended up frozen in two addresses. Of the 300M USDT that moved before the freeze, 199M went to a swap contract, 33M to a DEX pool manager and 66M to the fresh address that was frozen five minutes later.

The deposit-receipt escape

Tether can freeze USDT per address. But when USDT is supplied to a lending protocol, the depositor receives a receipt token (jUSDT and the like). The receipt is issued by the protocol, not the issuer, so Tether cannot freeze it. Send the receipt to a new wallet, redeem there, and the redeeming wallet holds USDT at an address that is not on any blacklist.

Read against the timeline, the 10,000 USDT deposit at 21:14 looks like a test of exactly this route, five minutes after the first freeze at 21:09. The trick also defeats tracing: stolen-fund tracers follow native coins and major stablecoins, and if receipt-token transfers are dismissed as "other tokens of unknown price", the chain breaks right there.

1. Stolen-fund tracing on TRON

The tracer that follows outflows from the attacker addresses in the incident database (the "stolen-fund exposure labels" from the previous post) now runs on TRON as well as Ethereum. TRON addresses are base58 and case-sensitive, so the lowercase normalisation used for EVM would turn them into different addresses; the tracer handles that correctly and fetches transfers oldest-first from the contamination time. Attacker addresses attract heavy address-poisoning spam on the inbound side, so outbound and inbound transfers are fetched separately and the outbound page can never be pushed out by spam.

The binance-2026 incident now lists the TRON victim wallet, the primary receiver, the consolidation hubs, the frozen receiver and the TRX feeders. The first pass recorded 169 addresses at hop one and over 800 at hop two.

2. Deposit receipts as value

When a traced address sends a stablecoin out and receives exactly one other token in the same transaction, that token is learned as a value carrier for this incident. The rate is "USD sent ÷ tokens received"; nothing is hard-coded. From the test deposit above, 1 jUSDT ≈ 0.0109 USD was learned. From then on, transfers of that token are valued at the learned rate, the recipient is recorded one hop out, and above the threshold it is also registered in ScamDB.

• Only the attacker's own outbound transactions are used for learning. Inbound-only airdrops and spam tokens can never become carriers.

• If two or more tokens are received in the same transaction, the case is ambiguous and nothing is learned.

• A DEX swap has the same shape, so swap outputs are learned at the executed rate. For volatile tokens the valuation can drift; the ledger keeps the carrier-derived amount in its own column.

3. TRON exchange hot wallets and tracing depth

When stolen funds reach a known exchange, the incident page shows the exchange name, never the address. Many TRON exchange hot wallets are missing from our registry, so the tracer now consults the public address tags of TRON's canonical explorer: addresses tagged as exchanges count as exchange touchpoints, and DEX and bridge contracts are excluded.

Tracing depth goes from two hops to three. The depositing wallets mostly appear at hop two, and stopping there hides both the receipt learning and what happens next. Hop-three addresses are recorded in the ledger only and are never registered in ScamDB; the line that keeps uninvolved third parties out is unchanged.

What the chain shows about scale

Supply events on the lending protocol's USDT market, from the drain at 20:00 UTC on 29 October to 13:30 UTC on 31 October:

The six wallets share one route: TRX peeled off the attacker's hub, swapped to USDT on a DEX, supplied to lending. TRX → DEX → USDT → receipt, four hops in about a day. The other fifteen cannot be tied to the drain on-chain yet, either because the funding is further away or because they are unrelated, so they are not counted.

Time to freeze, from this incident's primary data

All values are computed mechanically from the block time of the freeze events and match the freeze-latency card on the incident page. Forty-six minutes on TRON is not slow, yet 300M USDT moved in that window and the receipt route was being tested five minutes after the freeze. A freeze stops the clock. It is not a recovery.

The incident details and attacker addresses are public at /hacks/binance-2026. TRON tracing, receipt learning and exchange touchpoints reach every plan through ScamDB matching in wallet scans, the REST API and MCP. The figures in this post are as of 31 October 2026, 13:30 UTC; supply events keep accumulating.

Share this page

X Facebook LinkedIn Copy link

Binance hot wallet drain: EIP-7702 delegation detection, an auto-updating USDT/USDC freeze ledger, and stolen-fund exposure labels

TL;DR — At 20:24 UTC on 29 October 2026, 167,464 ETH and 64 tokens left Binance's hot wallet "Binance 14" in a single transaction. Three minutes earlier the wallet had been delegated to an attacker-deployed contract via EIP-7702, and the drain was a sweep executed through that delegated code. In response, ChainAnalyzer adds EIP-7702 delegation detection (E23), automatic updates of the USDT/USDC freeze ledger, and stolen-fund exposure labels (hack exposure), and publishes an incident page.

What happened, as far as the chain shows

Reported losses range from $2.5B to $5.5B. The incident page only carries what can be verified on the Ethereum ledger.

An EIP-7702 authorization can only be signed with the wallet's own private key. Fifty valid signatures strongly indicate that the signing key was in the attacker's hands. EIP-7702 was not the cause; it was the tool that let 65 assets leave in one call. The full walk-through is on the incident page.

What this changes for investigators

After a large exchange drain, stolen funds are swapped, split and consolidated within hours and show up at other exchanges' deposit addresses the next day. The team screening those deposits needs two answers on the spot: has this address touched the 29 October funds, and has the issuer already frozen it. The three additions below exist to answer that.

1. EIP-7702 delegation detection (E23)

On EVM wallet scans, ChainAnalyzer checks whether the address's code is the 23-byte EIP-7702 designator starting with 0xef0100. If the wallet is delegated, the result shows the delegate contract and whether it is verified.

• An unverified delegate contract is HIGH. An exchange, issuer or custody wallet being delegated at all is abnormal.

• Delegation plus the sweep signature seen here, a large internal ETH transfer and many ERC-20 transfers to one recipient within a short window, escalates to CRITICAL with the transactions attached as evidence.

• A verified wallet implementation as delegate stays at LOW, informational only.

Monitoring that only reads normal transactions misses transfers made through delegated code, because they are internal transactions. ChainAnalyzer includes internal transactions in the check.

2. Automatic updates of the USDT/USDC freeze ledger

An issuer blacklisting an address is the most reliable first-hand signal that the issuer itself judged it illicit. ChainAnalyzer has collected freeze events mainly for yen stablecoins; from now on every covered token, including USDT and USDC on Ethereum, Polygon and Avalanche, is collected every six hours and frozen addresses flow into ScamDB. Un-blacklist events are tracked too, so a released address is not kept dangerous forever.

Scanning the recipient address frozen on 29 October now shows "frozen by issuer" with the freezing transaction.

3. Stolen-fund exposure labels (hack exposure)

Starting from the attacker addresses registered in the incident database, ChainAnalyzer follows outgoing funds up to two hops and registers receiving addresses in ScamDB as recipients of stolen funds. From then on, any wallet scan, REST API call or MCP query on those addresses reports which incident's funds they touched and at how many hops.

• DEX routers, bridges, known exchange hot wallets and token contracts are excluded.

• When stolen funds reach a known exchange, the incident page shows the exchange name, not the address.

• Hop 1 is danger, hop 2 is warn, and nothing beyond hop 2 is followed. The cap exists so unrelated third parties are not swept in.

Technical note: reading a SetCode transaction

Delegation happens in a type 0x4 transaction whose authorizationList carries (chainId, address, nonce, signature) tuples. An authorization is only valid for the wallet's current nonce, and a hot wallet that sends several transactions per second moves its nonce constantly. This transaction bundled 50 signatures with consecutive nonces so that one of them would match. The technique presupposes an exchange hot wallet as the target.

Once set, the wallet's code becomes the 23 bytes 0xef0100 plus the delegate address. The delegate's code runs in the wallet's own context, so the transfers are recorded as the wallet's transfers, but as internal transactions. The sweep call 0x8a179be4(address recipient, address[] tokens) listed 65 addresses, the zero address at the front standing for ETH.

One more observation: minutes after the attacker's first test transfer, the test recipient started receiving zero-value transactions from addresses sharing its first four characters. That is address poisoning aimed at the attacker, and ChainAnalyzer's poisoning detector fires on it as it would on anyone else.

The incident details and attacker addresses are public at /hacks/binance-2026. EIP-7702 detection is on for EVM wallet scans on every plan; the freeze ledger and exposure labels reach every plan, the REST API and MCP through ScamDB matching.

Share this page

X Facebook LinkedIn Copy link

Agent Skill + Claude Code plugin: install ChainAnalyzer AML in one step, and API keys now on every plan

TL;DR — ChainAnalyzer's MCP server (chainanalyzer-mcp v1.5.0) now ships with an Agent Skill for AI agents. In Claude Code, two commands install the MCP server and the skill together. Cursor, Codex CLI, Gemini CLI and other agents that read SKILL.md can use the same skill. We have also made REST API keys available on every plan, including Free, so you can try all 7 tools at no cost.

What changed

You could already call ChainAnalyzer's tools from an AI agent by configuring the MCP server. But an MCP server only hands the agent a list of tools. Which chain to treat an address as, which tool to call first, and when to stop were left to the agent.

The new Agent Skill (a SKILL.md following the Agent Skills spec) gives the agent that procedure. It detects the chain from the address format, calls the cheapest tools first, checks with you before costs add up, and shows the evidence before the conclusion — the same way every time.

Who this helps

• Compliance analysts can paste a counterparty address and ask "is this sanctioned, and how risky is it?" — and get sanctions and risk results backed by tx hashes and counterparty labels.

• Developers building agents can drop in the skill and the MCP server instead of writing their own call ordering and cost controls for AML screening.

• Anyone who wants to try it first can try five of the tools with a Free plan API key (10 scans/month, 10 requests/min): sanctions check, risk score, transaction trace, CoinJoin detection and wallet clustering. Batch screening needs Starter or above and bridge tracing needs Business or above.

How to install

Claude Code (plugin)

Run these two commands inside Claude Code to install the MCP server and the skill together:

/plugin marketplace add rascal-3/chainanalyzer-mcp
/plugin install chainanalyzer-aml@chainanalyzer

Then set CHAINANALYZER_API_KEY in the environment of the shell that launches Claude Code. To pay per call in USDC without an account, set X402_PRIVATE_KEY instead.

Any other agent

Copy skills/chainanalyzer-aml/ from the GitHub repository into your agent's skills directory (or run npx skills add rascal-3/chainanalyzer-mcp), and configure the MCP server like this:

{
  "mcpServers": {
    "chainanalyzer-aml": {
      "command": "npx",
      "args": ["-y", "chainanalyzer-mcp"],
      "env": {
        "CHAINANALYZER_API_KEY": "tfk_..."
      }
    }
  }
}

Example prompts

• "Is this address sanctioned? 0x..."

• "Check the AML risk of this TRON address and show me the evidence."

• "Trace the funds in this Bitcoin transaction and look for signs of mixing."

• "Screen these 20 addresses in one batch."

• "Follow the funds that left this address through a bridge."

The 7 tools

• sanctions_check ($0.50) — sanctions lists and ScamDB

• check_address_risk ($1.00) — AML risk score, detections and ML anomaly score (all 12 chains)

• trace_transaction ($3.00) — transaction fund-flow tracing

• detect_coinjoin ($1.00) — CoinJoin and mixing detection (Bitcoin only)

• cluster_wallet ($2.50) — addresses likely controlled by the same actor

• batch_screening ($5.00) — up to 50 addresses per call

• bridge_flow_trace ($3.00) — cross-bridge fund tracing (EVM chains, Solana, Kaia)

Prices are per call in x402 (pay-per-request) mode. With an API key, each call uses one scan from your monthly quota. v1.5.0 also fixes bridge_flow_trace so it is correctly registered in the tool list.

API keys on every plan

REST API keys (starting with tfk_) can now be issued on every plan, Free included. Request limits are 10/min on Free, 30 on Starter, 60 on Pro, 120 on Business and 300 on Enterprise. Scans made through the API draw from the same monthly quota as scans in the web app.

Technical note: what the skill decides

• Chain detection — bc1 / 1 / 3 is Bitcoin, T is TRON, r is XRP, 32-44 Base58 characters is Solana, 0x plus 40 hex is EVM. The format alone does not identify the EVM chain, so without a hint the agent uses Ethereum and says so.

• Cheap first — sanctions check ($0.50), then risk score ($1.00). A sanctions hit is reported immediately; clustering and tracing run only when risk is medium or above, or when you ask to follow the money.

• Cost gating — in x402 mode, if a turn would cost more than about $5, the agent asks before running it.

• Evidence first — a one-line verdict, then the evidence behind each detection, with next steps offered as options for your own compliance policy. A "safe" result is never presented as a guarantee.

Results are risk indicators based on public ledger data, not legal determinations. Full steps and limitations are in the AI agents documentation.

Where it is listed

• Official MCP Registry (io.github.rascal-3/chainanalyzer-mcp)

• npm: chainanalyzer-mcp

• Smithery: chainanalyzer-aml skill

• Glama (quality score A)

• GitHub: rascal-3/chainanalyzer-mcp

Trying it is free. Create a free account, issue a key under Settings → API Keys, and your agent can start calling the tools. If you are evaluating it for your organization, contact us.

Share this page

X Facebook LinkedIn Copy link

zJPYC on-chain: about 1.21 million JPYC sits in a privacy pool — the link is severed, but entry and exit are public

TL;DR — zJPYC is the JPYC wrapper of zERC20, a privacy transfer protocol built on zero-knowledge proofs, live on Polygon and Kaia since June 2026. As of September 25, the zJPYC pool holds about 1.21 million JPYC on Polygon and about 48,000 JPYC on Kaia. The link between sender and recipient is not recorded on-chain, but deposits into the pool and exits through claims and redemptions are visible on the public ledgers. zERC20 itself states that JPYC Inc. is not involved in providing, co-developing, reviewing or endorsing zJPYC.

What zJPYC is

zERC20 is a privacy transfer protocol based on zero-knowledge "proof-of-burn" (in the EIP-7503 family). It has been publicly stated that it was developed by core developers of INTMAX. In plain terms, it works like this:

1. A user deposits an ERC-20 token into the pool and receives the same amount of a zAsset (zJPYC, in JPYC's case).

2. The zAsset is sent to a one-time address for which no private key exists. Nothing can ever move out of that address, so the transfer is effectively a burn.

3. The recipient proves, with a zero-knowledge proof, that such a transfer happened, and claims a freshly minted zAsset to their own address.

The proof in step 3 is verified without revealing which transfer it corresponds to, so the link from sender to recipient is never written on-chain. Recipients can claim on a different chain from the one the transfer happened on, and the protocol also supports batch claims (several transfers at once) and partial claims.

zJPYC is the JPYC version. According to zERC20's announcement it launched on Polygon on June 11, 2026, and it is also live on Kaia. The contracts share the same addresses on both chains.

zERC20's page states that JPYC Inc. is not involved in providing, co-developing, reviewing or endorsing zJPYC. zJPYC is not a JPYC Inc. product; it is an unofficial third-party wrapper.

What is visible on-chain, and what is not

Using zJPYC breaks down into four steps on the public ledgers.

The only thing that is not visible is which send in step 2 corresponds to which claim in step 3. The link is severed, but both the moment funds enter the pool and the moment they leave it are on record.

zJPYC in numbers (June 8 – September 18, 2026)

Transfer counts run through September 18; balances are as of September 25. *Kaia deposits and payouts are derived from zJPYC mint and burn events; their difference matches the held balance.

On Polygon, deposits minus payouts equal the held balance of 1,211,935 JPYC exactly. Across both chains there were 12,010 private sends, from 261 sending addresses to 9,850 one-time addresses. Only 49 of those one-time addresses ever sent anything afterwards.

Counting any role — deposit, send, claim or redemption — 296 distinct addresses took part. By role, 112 addresses deposited, 94 redeemed and 245 received claims.

Private sends by month:

The median private send is 3,000 JPYC. The most frequent amount is 10,000 JPYC (3,540 times), followed by 100,000 JPYC (1,372 times), and 56% of private sends are round amounts of 1,000 JPYC or more. The largest single send was 5,000,000 JPYC. A distribution in which the same round amounts recur this often looks more consistent with campaign- or airdrop-style distribution than with individual payments. That is an observation about the distribution only; the actual purposes were not confirmed.

There is also a cross-chain pattern. Kaia saw only 18 deposits (wraps), yet 4,217 claim transactions. Value mostly enters on Polygon and leaves on Kaia — the ability to claim on a different chain is being used in practice.

Note that total private-send volume runs to hundreds of millions of JPYC, far above the roughly 11.7 million JPYC ever deposited. The same zJPYC can be claimed and re-sent any number of times, so volume totals should be read as sums over events, not as the amount of value that actually entered the pool.

Where this sits for AML

Privacy protocols are legal tools with legitimate uses — for example, businesses or individuals who do not want counterparties or salaries exposed on a public ledger. Using one is not in itself a sign of wrongdoing.

For AML (anti-money laundering) practice, though, the realistic stance is to treat the pool boundary the way you would treat a mixer boundary: rather than trying to rebuild the link, know when funds entered the pool and when they left it, and apply due diligence proportionate to the amount. Attribution across the pool cannot and should not be asserted.

JPYC's own controls live in the JPYC token contract and do not reach inside the wrapper. Inside the pool the value circulates as zJPYC; it becomes JPYC again only at redemption.

How ChainAnalyzer handles it

• ChainAnalyzer registers the zERC20 contracts (zJPYC and the zETH, zUSDC and zBNB pools) as privacy-protocol entities. If a screened address has deposited into or withdrawn from a pool, the scan shows a "privacy protocol" finding with the number of interactions and the total amount.

• The JPYC issuer dashboard shows the JPYC balance held by the pool on each chain.

• It does not re-link senders and recipients, and by design it cannot.

Method and limitations

• Data comes from the public ledgers of Polygon and Kaia.

• Events are classified as deposits, sends, claims or redemptions by the type of interaction with the contracts listed above.

• Counts and amounts are event totals; when the same value is sent and claimed repeatedly, each occurrence is counted.

• The pool is in continuous use, so the figures change daily.

• "Addresses" are not people, and this article makes no attribution of any address to any person or entity.

Anyone who wants to check whether a counterparty's address has passed through a privacy protocol can try a free scan at chain-analyzer.com. For business use or bulk screening, please get in touch via our contact page.

This article is an analysis based on public information and is not a recommendation to use, buy or sell any crypto asset or service.

Share this page

X Facebook LinkedIn Copy link

JPYC's circulating supply rose 2.3× in 48 hours — about half of the increase sits with a small group of addresses that first appeared after the listing

TL;DR — In the roughly 48 hours after JPYC was listed on the Korean exchange Upbit on September 17, 2026, JPYC's circulating supply rose 2.3×, from ¥1.93B to ¥4.41B. Only Ethereum and Polygon grew; Kaia shrank. ChainAnalyzer tracked balances on four chains at hourly resolution, and almost all of the increase in circulating supply landed in one place. A group of addresses that received JPYC for the first time 78 minutes after the listing notice held 51.1% of circulating supply 48 hours later (peak 54.9%). That holding reached 78.4% of circulating supply on Ethereum and 56.2% on Polygon. DEX pool inventory, meanwhile, grew by only ¥64M over the three days — 2.6% of the ¥2.48B increase. On September 19 the group began paying JPYC out to external addresses, and the issuer side turned to net redemption on all four chains.

What the first report left open

The first report re-read the listing-day price dislocation through 55,293 executed trades on decentralized exchanges (DEXs). It showed that the reported highs only printed in trades below 1,000 JPYC, and that most of that day's new issuance never went through a DEX.

That leaves a simple question. If the new JPYC did not go through a DEX, where did it go? A price chart cannot answer it. Only on-chain balances laid out along a time axis can.

So balances for JPYC on four chains were collected at hourly resolution for 85 timestamps, from 00:00 on September 16 to 12:00 on September 19 (Japan time). Circulating supply here means total supply minus the balances held in the issuer's publicly known operational wallets — the same definition used on ChainAnalyzer's issuer pages. All amounts are stated at 1 JPYC = ¥1.

1. Circulating supply went from ¥1.93B to ¥4.41B, and only two chains grew

閉じる / Close

Comparing the two ends of the observation window:

Total supply rose 2.4× on ¥12.48B of mints, but circulating supply grew by only ¥2.48B. As of 12:00 on September 19, ¥16.88B — 79.3% of the ¥21.29B total supply — still sat inside the issuer's operational wallets and had not reached the market.

Broken out by chain, only two chains grew.

閉じる / Close

Kaia was the largest chain before the listing; 48 hours later Polygon was 2.5× its size. Kaia is the only chain that shrank. On Avalanche, ¥2.80B was minted and yet the amount reaching the market barely moved. Kaia also has a separate large holder that predates the listing and is unrelated to it, and that balance has in fact kept declining over these three days.

Circulating supply itself peaked on the evening of September 18 at about ¥4.49B, and has edged down since.

2. Where the increase went

Counting the destination of the ¥2.48B increase from the holder side gives a clear answer. A group of addresses that held nothing at all on September 16 held ¥2.25B on September 19 at 12:00 — 51.1% of the ¥4.41B circulating supply.

閉じる / Close

The group first received JPYC at 11:06 on September 17 — 78 minutes after the listing notice (09:48) and seven hours before trading opened (18:00). The path from there:

The skew is larger still by chain. As of 12:00 on September 19 the group held 78.4% of circulating supply on Ethereum and 56.2% on Polygon. On Kaia it held 7.4%, on Avalanche nothing. The chain the first report described as holding "about 7% of all circulating JPYC" multiplied its circulating supply 8.8× in 48 hours, and roughly 80% of that went to this group. By the time trading opened, 51.3% of Ethereum's circulating supply was already there.

The first receipt on Polygon was at 19:31:45 on September 17, eight minutes after the same exchange opened Kaia and Polygon deposits at 19:23:09. The notice, however, was public information available to anyone, and the closeness of the two times is not enough to conclude a relationship between them. The times are simply placed side by side here.

3. How that group of addresses behaves

The shape of the transfers says a good deal about how the group operates. What follows is measured from 11:06 on September 17 to 12:00 on September 19.

• It received 3,341 transfers totaling ¥2.47B from 282 distinct addresses (181 on Ethereum, 174 on Polygon, 51 on Kaia). Of those, 101 addresses deposited on both Ethereum and Polygon, and those 101 alone account for 89.7% of the deposit value across the two chains. The same senders are paying into the same receiving addresses across chains.

• The median deposit is about 300,000 JPYC (about 310,000 on Ethereum, about 300,000 on Polygon, about 29,000 on Kaia). 688 deposits exceeded 1,000,000 JPYC, and the ten largest depositors account for roughly half of the total.

• The largest depositors are all ordinary addresses (EOAs); no DEX router or pool, no bridge and no known exchange wallet appears among them. There is no sign, at least at the top of the list, of JPYC bought in bulk on a DEX flowing in.

• JPYC arriving at the receiving addresses is swept mechanically into a single destination at a median interval of about 12 minutes. The destination is one and the same address on all three chains, and it takes 89–98% of all outbound transfers from the receiving addresses.

This shape — many senders paying into receiving addresses, then a periodic sweep into one place — together with the near-total absence of outbound payments to external addresses from September 17 until the morning of September 19 (three days of essentially one-way inflow), is consistent with an operation that pools deposits from many users. As noted below, however, not a single piece of public evidence identifies whose operation it is.

At 09:08 on September 19, payments out to external addresses began. This is the first outbound flow of any size. In the three hours that followed, ¥158M left on Polygon and ¥30M on Ethereum. In the same window, transfers back from the sweep destination to the receiving addresses also began, totaling ¥177M. That movement is what took the share from its 54.9% peak down to 51.1%. Whether those payments are withdrawals to users or moves to somewhere else cannot be determined.

4. On the issuer side, day three turned to net redemption

閉じる / Close

Traffic between the issuer's operational wallets and the market, by day:

Net ¥2.49B reached the market over the three days, matching the independently computed change in circulating supply (+¥2.48B) to within ¥20M.

Two things stand out.

First, distribution into the market was extremely dispersed. 1,405 addresses on Ethereum and 2,055 on Polygon received JPYC from the issuer's operational wallets, and even the largest single recipient took less than 0.6% of the total (the same holds for flows back to the redemption wallet, where the largest was 1.6%). Nearly all of the increase ended up in one place, yet the entrance to it was spread across thousands of addresses.

Second, September 19 was net redemption on all four chains. Issuance that day had all but stopped through 12:00 (¥0.02B across four chains) and flows back to the redemption wallet exceeded it. This is 12 hours of observation on day 2.5, though — not long enough to call a trend.

5. DEX inventory barely grew

The first report noted that "the JPYC that passed through Ethereum's DEX pools on the event day was only about 19% of that day's issuance on Ethereum." That was a statement about flow; the same conclusion holds for stock.

Inventory across DEX venues grew by a combined ¥64M over the three days — 2.6% of the ¥2.48B increase in circulating supply. The DEXs were where a price printed on listing day, but they were not where the volume went.

6. What can and cannot be said

What is written above is an observation: 48 hours after the listing, about half of circulating JPYC sits with a small group of addresses that first appeared after the listing. Past that point there is a clear line.

• Attribution is unconfirmed. Neither the major block explorers nor ChainAnalyzer's own registry carries a public name tag for these addresses. That the behavior is consistent with an operation that pools deposits is as far as this goes; no primary evidence identifies whose operation it is.

• 51.1% is a lower bound. What was tracked here is limited to the addresses that the flow of funds indicates belong to a single entity. If further addresses belonging to the same entity are found, the share goes up.

• Closeness in time is not causation. Notices and deposit openings are public; anyone can react at the same moment. This article places times side by side and does not say that anything moved "in response to" anything else.

• Address counts are not people, and every figure carries a timestamp. The share moved 3.8 points in three hours on the morning of September 19 alone. Cut the window differently from 48 hours and the picture changes.

Whether concentration is itself good or bad is not assessed here. What is observable is only the fact of which chain, how much, and where it gathered.

ChainAnalyzer's issuer pages (no login required) publish per-chain total supply and circulating supply for JPYC and other major stablecoins, along with issuance and redemption events. Anyone tracking supply by chain can use /issuers/jpyc. For the breakdown of prices on listing day, see the first report, "Where did JPYC's '¥4' actually trade?".

Method and limitations

• Balances were read directly from each chain's archive nodes at 85 hourly timestamps from 00:00 on September 16 to 12:00 on September 19 (Japan time). For Avalanche alone, archive node responses did not arrive in time, so the series was reconstructed from transfer history and reconciled against measured values at six timestamps (maximum difference ¥100,000).

• Circulating supply is defined as total supply minus the balances held in the issuer's publicly known operational wallets. It is ChainAnalyzer's own aggregation and differs in definition and timing from figures published elsewhere.

• Each time series was built by two independent methods (direct balance queries and accumulation from transfer logs) and the two were compared. Across all 85 timestamps the maximum difference was within ¥5M.

• "Group of addresses" and "holders" refer to sets of addresses, not to people.

• DEX venue inventory is the JPYC-denominated balance of each chain's principal JPYC pools and is not exhaustive.

• The data set ends at 12:00 on September 19, 2026 and does not include anything after that.

This article is an analysis based on public information and is not a recommendation to buy or sell any crypto asset. It is not intended to inform investment decisions.

Share this page

X Facebook LinkedIn Copy link

Where did JPYC's ¥4 actually trade? The Upbit listing dislocation, seen through executed DEX trades

TL;DR — On September 17, 2026, the Japanese-yen stablecoin JPYC was listed on Upbit, the largest exchange in Korea, and briefly traded at 37.60 KRW (about ¥4.1). Decentralized exchanges (DEXs) were reported at "¥3–6". ChainAnalyzer aggregated 55,293 executed DEX trades on Ethereum, Polygon and Avalanche. The reported highs only exist in trades below 1,000 JPYC. For trades of 100,000 JPYC or more the ceiling was ¥3.32 on Ethereum and ¥3.51 on Polygon; for 1,000,000 JPYC or more it was ¥1.31 and ¥2.98. On the issuance side, after 62 days without a single mint, the issuer minted 12.48 billion JPYC in seven transactions between 21:37 on the 17th and 03:23 on the 18th, and 9.9 billion of that came after the price had already returned to roughly ¥1. The start, peak and end of the dislocation fell at different times on each chain; Avalanche recovered five hours before the other two.

What happened

According to Upbit's notices and price data (both from the exchange's public API):

• At 09:48 on September 17, Upbit announced the listing of JPYC and PYUSD. Trading was scheduled for 12:00, then postponed twice, to 15:00 and then 18:00.

• Trading opened at 18:00 with a first print of 12.00 KRW. The only trading limit was a floor (−10% from a reference of 8.81 KRW); there was no ceiling.

• The high of 37.60 KRW (about ¥4.1) printed between 19:20 and 19:25.

• At 18:44 Upbit announced it would add Kaia and Polygon deposits, and deposits opened at 19:23 (withdrawals later). The same notice added a caution that Korean users face restrictions in using JPYC's issuance and redemption window directly.

According to press reports, JPYC Inc. paused issuance reservations on Ethereum at 20:34 and on Polygon at 22:19 on the 17th, posting them as incidents, and restored them at 23:43 and 00:22 respectively. The cause is described as under investigation, and the company has not commented on any relationship with the price dislocation. In a written comment to press, JPYC CEO Noritaka Okabe said that the company always receives ¥1 at issuance and can therefore redeem regardless of the secondary-market price (NADA NEWS, September 18).

What follows is that sequence re-read against executed on-chain trades and issuance data.

Executed prices: the highs only printed in small trades

The data set is every swap between JPYC and a USD stablecoin in Uniswap's JPYC pools on Ethereum, Polygon and Avalanche from 09:00 JST on September 17 to 12:00 JST on September 18: 55,293 trades. Prices are computed from each trade's exchange ratio, not from order books or aggregator composites, with USD/JPY fixed at 155.58.

First, when the dislocation started, peaked and ended on each chain, measured on 15-minute volume-weighted average price (VWAP):

Ethereum began moving at 17:45, before Upbit opened. Avalanche is sometimes reported as "not affected"; it in fact reached ¥1.39 in the 19:45 bar and was back by 21:00. An observation just after midnight would correctly show 1.00×; the difference is the timestamp.

The next table is the core of this piece: trades between 18:00 and 22:00 on September 17, bucketed by JPYC amount per trade, with the highest price in each bucket.

The reported levels, "about ¥6.07 on Polygon" and "about ¥4", never printed in any trade of 100,000 JPYC or more. The larger the amount moved, the closer the realized price stayed to ¥1. "Mint at ¥1 and sell at ¥4" did not work at size. Aggregator highs and 15-minute closes carry no trade-size dimension, so this cannot be read off a price chart.

The issuer side: the first mint in 62 days, and 9.9 billion after the recovery

Supply data published on ChainAnalyzer's issuer page (no login required) shows that JPYC's total supply did not change for 62 days after the mint of July 17. Over that period the circulating amount drifted down from 2.49 billion on September 1 to 1.90 billion on the 16th; demand appears to have been met from already-issued, not-yet-circulating inventory. There were no burns in the past 180 days.

On the day of the event there were seven mints totaling 12.48 billion JPYC (times in JST):

Three things stand out when this is laid against the timeline.

1. The first mint (21:37) came about an hour after the reported pause of Ethereum issuance reservations (20:34). "Issuance reservation" is a user-facing procedure; a mint is on-chain issuance. They are different layers, and the company has not explained the relationship, so here they are only placed side by side.

2. The final 9.9 billion (03:19–03:23, on four chains at once) came about an hour after the executed VWAP on Ethereum and Polygon fell below ¥1.05 at 02:00. It reads less like meeting immediate demand and more like restocking on a scale larger than the pre-event total supply (8.81 billion), but that is an interpretation.

3. Ethereum's circulating amount on the 18th, 1.203 billion, exceeds the pre-event Ethereum total supply of 1.113 billion. Without additional mints, demand on Ethereum could not have been met. That is consistent with the CEO's comment that "issuance surged and we ran out of inventory in the middle of the night", although the company has not said what "inventory" refers to.

One more point about how the pools were used. On the event day about 0.69 billion JPYC passed through Uniswap pools on Ethereum, roughly 19% of the 3.69 billion minted on Ethereum that day (and that figure is gross, including round trips). Inflow of 0.692 billion against outflow of 0.685 billion means the pools held no inventory; they were a corridor. Most of the new issuance did not go through a DEX in this window.

Why the corridor was narrow

If something mints at ¥1 and sells at ¥4, arbitrage should close the gap quickly. It did close, but it took eight hours on Ethereum and Polygon. Every factor cited in press coverage points to the same thing: the corridor between the primary market (issuance and redemption) and the secondary market (exchanges and DEXs) was narrow.

• At listing, Upbit supported deposits and withdrawals only on Ethereum, and Ethereum held about 7% of all circulating JPYC.

• Issuance is capped at ¥1 million per request, and consecutive requests in a short period are not accepted (JPYC Inc. release, May 2026).

• Using Upbit requires a Korean bank account; issuing or redeeming JPYC requires identity verification with a Japanese My Number card. Very few participants could complete "mint at ¥1, sell on Upbit" alone.

• The DEX pools that linked Japan and Korea were thin; as the table above shows, trades of tens of thousands of JPYC moved the price several-fold.

A similar listing-day spike in a euro stablecoin was reported on a Korean exchange in August, so this is not specific to JPYC.

One token, one day, three prices and three clocks

The same token from the same issuer peaked at ¥3.14 on Ethereum, ¥2.92 on Polygon and ¥1.39 on Avalanche on the same day, and recovered at 02:00 on the 18th, 02:00 on the 18th and 21:00 on the 17th respectively. With no official bridge, cross-chain arbitrage runs through the primary market, and the peg is maintained separately on each chain. For anyone settling in a stablecoin, which chain you receive it on is itself a risk factor.

ChainAnalyzer's issuer pages publish per-chain total supply, circulating amounts and issuance/redemption events for JPYC and other major stablecoins. Anyone tracking supply by chain can use /issuers/jpyc without logging in.

Method and limitations

• Prices are computed per trade from swaps between JPYC and USD stablecoins (USDC / USDT / DAI) in Uniswap's JPYC pools. USD/JPY is fixed at 155.58, the rate at 19:37 JST on September 17. Highs and lows are limited to trades of 50,000 JPYC or more, except in the size-bucket table, which uses every trade.

• Kaia DEXs are outside this data set; prices on Kaia were not observed.

• The pause and restoration times for issuance reservations are the values on which several press reports agree. JPYC Inc.'s website carries no notice, so they were not confirmed from a primary source.

• "Participants" are addresses, not people.

• Supply and circulating figures are ChainAnalyzer's own aggregation and differ in definition and timing from figures published elsewhere.

This article is an analysis based on public information and is not a recommendation to buy or sell any crypto asset.

Share this page

X Facebook LinkedIn Copy link

Travel Rule exchange is coming to ChainAnalyzer — screening and transmission in one flow

ChainAnalyzer is building a VASP-to-VASP information exchange (transmission) capability for the FATF Travel Rule, offered to Enterprise customers. It integrates the transmission itself with the on-chain risk assessment ChainAnalyzer already provides (recipient screening, sanctions matching, attribution), so that pre-transfer risk decisions and Travel Rule notification complete in a single flow. The core method is patent pending.

A two-stage risk gate: check again after approval

In the standard Travel Rule exchange (TRP: Travel Rule Protocol), the deposit address is disclosed only when the beneficiary VASP approves. Verifying that just-disclosed address has traditionally been left to manual operations.

• Stage 1 — before any exchange starts, the destination and counterparty VASP are screened. If risky, no inquiry is sent at all.

• Stage 2 — the deposit address disclosed on approval is screened again before on-chain execution. If risk is found, the transfer is automatically voided even though it was approved, with the grounds recorded in the audit trail.

Placing procedural "approval" and on-chain "safety" as two independent gates in series structurally removes the blind spot that appears when screening and transmission run as separate services.

Personal data on a separated foundation

Originator and beneficiary personal data handled in transmission is encrypted and managed on a physically separated foundation from the detection engine. Queries toward the detection engine are mechanically restricted to wallet addresses, chain identifiers, and legal entity names — keeping the screening engine verifiably out of contact with personal data.

Jurisdictional differences absorbed by policy

Notification duties, required data fields, and the treatment of self-hosted wallets differ sharply by jurisdiction (Japan exempts transfers to self-hosted wallets from notification; Peru prohibits the transfer itself when the information cannot be collected). A single engine handles such opposite requirements through per-jurisdiction policy configuration alone.

Availability

In preparation as an Enterprise add-on, built on TRP (an open standard with interoperability bridges). If you are looking to combine Travel Rule compliance and on-chain AML in one place, please reach out via our contact form.

* This capability is under development; availability and specifications are subject to change.

Share this page

X Facebook LinkedIn Copy link

XRP goes live: 12 chains for self-serve scanning, full XRPL history included

On 2026-08-09, XRP (XRP Ledger) became a fully supported chain on ChainAnalyzer. Beyond native XRP payments, we now scan IOU (issued-currency) tokens too, with the same feature set as every other chain: one-off scans, Watchlist monitoring, Follow Mode graph exploration, and Case Management. That brings self-serve live chains to 12: Bitcoin, Ethereum, Polygon, BNB Smart Chain, Base, Arbitrum, Optimism, Avalanche, Solana, Kaia, TRON, and XRP.

Live on every plan, including Free, from day one

XRP is available on every plan, including Free, starting today. Sign up and scan an XRP address immediately — Starter and above get batch scanning, Watchlist monitoring, REST API, and x402 support for XRP as well.

Full history, no API key required

The XRP Ledger runs on Ripple's official full-history clusters (s2.ripple.com, with xrplcluster.com as fallback) — public infrastructure that needs no credential at all. Unlike EVM chains that require an Etherscan-family API key, or TRON where we integrate a dedicated API provider, there's no BYOK setting for XRP: every user gets the same full-history access on day one.

Partial Payment correction: the amount actually received, not the amount advertised

XRPL supports Partial Payment, a transaction type where the sender can settle for less than the amount originally specified — meaning the headline transfer amount in raw transaction data can overstate what actually moved. ChainAnalyzer corrects every Partial-Payment-flagged transaction against the delivered_amount field, so fund-flow analysis and risk scoring are always based on the amount actually delivered, not the advertised send amount.

Same detection depth as every other chain, plus a Destination Tag disclosure

OFAC sanctions screening, sanctioned-counterparty detection, dust attack detection, peel chain and fund-splitting detection, and KYT risk rating all run on XRP exactly as they do elsewhere. ScamDB matching, Follow Mode graph exploration, and case ingestion work unchanged.

One XRPL-specific nuance we surface directly in the scan result: exchanges commonly share a single deposit address across many users and tell customers apart with a Destination Tag. A scan verdict on such an address can therefore reflect the activity of the exchange as a whole rather than one individual user — tag-level analysis is not supported, and we disclose this explicitly wherever it applies.

XRP support is available on every plan, including Free. Existing Watchlist items and cases are untouched; just pick XRP from the chain selector when scanning. Ripple's official clusters are free and public, so there's no API key to configure.

Share this page

X Facebook LinkedIn Copy link

TRON goes live: 11 chains for self-serve scanning, TRC20/USDT included

On 2026-08-09, TRON became a fully supported chain on ChainAnalyzer. Beyond native TRX transfers, we now scan TRC20 tokens — including USDT-TRC20, the highest-volume stablecoin transfer rail on any chain — with the same feature set as every other chain: one-off scans, Watchlist monitoring, Follow Mode graph exploration, and Case Management. That brings self-serve live chains to 11: Bitcoin, Ethereum, Polygon, BNB Smart Chain, Base, Arbitrum, Optimism, Avalanche, Solana, Kaia, and TRON.

Live on every plan, including Free, from day one

TRON is available on every plan, including Free, starting today. Sign up and scan a TRON address immediately — Starter and above get batch scanning, Watchlist monitoring, REST API, and x402 support for TRON as well.

Same detection depth as every other chain

OFAC sanctions screening (the TRX-denominated SDN list), dust attack detection, peel chain analysis, Chainalysis KYT risk rating, Alterya ML risk scoring, and social/web mention detection all run on TRON exactly as they do elsewhere. ScamDB matching, Follow Mode graph exploration, and case ingestion work unchanged.

Engineering note: TRON is not EVM

TRON runs on the TVM (TRON Virtual Machine) and does not share the Etherscan-compatible API surface that every Ethereum-family chain we support relies on. Addresses are Base58Check-encoded (34 characters starting with T), not 0x... — and critically, case-significant, unlike EVM addresses. Rather than bolting TRON onto the EVM scanner, we built an independent scanner pipeline backed by the TronGrid API (the same design pattern as our Bitcoin pipeline). Everything it returns is normalized into the existing Etherscan tokentx shape, so the detector logic and Neo4j ingestion code paths work unchanged.

TRON support is available on every plan, including Free. Existing Watchlist items and cases are untouched; just pick TRON from the chain selector when scanning. Set up a TronGrid API key via BYOK for deeper analysis.

Share this page

X Facebook LinkedIn Copy link

IMOZURU: one input runs the whole investigation loop — and writes the report

ChainAnalyzer now ships IMOZURU. Give it one address (or transaction) and it follows the money on its own, all the way to an investigation report PDF and an investigation case. Available on the Business plan and above.

What changed — giving analysts their time back

Until now, an investigation meant a human running the same loop on top of a tool: scan an address, look at the graph, choose the next address to follow, back out of the dead ends, and finally write the trail up as a report. A single case can mean running that loop hundreds of times.

IMOZURU runs that loop for you. The point is not that there are more detection rules. What is new is the automation of the work that was still left to a person — deciding where to pivot next, deciding when a branch is not worth following, and turning the path taken into prose.

• Resolve the input → scan → ingest into the graph → search for endpoints

• Pick the addresses to follow next, and decide whether to stop

• Generate the investigation report PDF and create the case automatically

Related addresses on other chains are correlated and explored even when no bridge left a trace to follow.

A measured run

Recorded from a single seed address of the address-poisoning network of roughly 800 million JPY that we found and published ourselves.

• 71 addresses discovered autonomously in about 12 minutes

• Of those, 57 terminals (endpoints not followed further) and 5 infrastructure nodes

• 4 confirmed common-operator attributions

A branch stops automatically once it reaches an exchange, a DEX router, or a bridge. Expanding a hub of that size would flood the investigation with unrelated traffic. A terminal does not mean the funds disappeared there — read it as a marker for who to ask next, or where to resume the trace.

Note: counts and elapsed time depend on the shape of the network, upstream data availability, and the budget you allow. The same input will not always yield the same counts, and the figures above are not a guarantee of reproduction.

Reading the output

IMOZURU never blends what the machine observed with what the model wrote.

• Per-section labels — the report has 8 sections, and every heading carries either an AI-generated or a machine-extracted label. When the material is used in legal or regulatory filings, verify against the machine-extracted sections as the source.

• Confirmed vs estimated — common-operator attribution is reported in two bands: confirmed (directly observed) and estimated (a synthesis of circumstantial evidence, not an assertion). The confidence score is not a probability: a score of 80 does not mean an 80% chance of a common operator, it is an internal measure of how many signals lined up and how strongly.

• Fund sizes are lower bounds — all three measures in the report are computed only from transactions that were actually observed; paths that were never observed are excluded. We deliberately avoid the phrase "total damages" because it has no single definition.

• A case is created for you — on completion, the addresses that were found are collected into an investigation case. Each address keeps its genealogy — which address it came from, at which hop, why it was picked up, and the transaction hash behind it — so the discovery path stays auditable. On Enterprise, the case feeds the suspicious transaction report (STR) support package.

Plan and limits

• Available on the Business plan and above

• Each scan the investigation performs consumes one unit of your monthly scan quota (scans that error or time out are not charged)

• Exploration is always bounded by three guards at once: time budget, hop count, and scan count

Read more

• IMOZURU documentation — how to use it, how to read the output, deep mode, the 10 supported chains, FAQ

• The address poisoning network, two months later — the published investigation the run started from

Note: we have filed four patent applications covering insider-trading detection via pre-disclosure window analysis, the ML decision gate, and cross-chain fund tracing / common-operator inference. All four were filed in July–August 2026 and are pending examination.

Note: IMOZURU output is reference information for an investigation. Legal determination and reporting obligations remain with the user.

Share this page

X Facebook LinkedIn Copy link

Insider trading detection for crypto — pre-disclosure window analysis, patent pending

ChainAnalyzer now ships insider trading detection for crypto assets. Register company affiliations and token interest scopes as tags, and scans cross-reference them. On top of that, pre-disclosure window detection automatically escalates trades that land inside the window before a registered announcement to CRITICAL. The detection method is patent pending.

What it detects

• Relationship cross-reference — "which company is this wallet related to" (affiliation tags) × "which tokens are exposed to that company's insider information" (insider-scope tags). Trades of in-scope tokens by related wallets are flagged.

• Pre-disclosure window — register disclosure events (earnings, partnerships, listings…) and any trade inside the look-back window (default 30 days) before the announcement is escalated to CRITICAL, with the window trades themselves attached as evidence transactions.

No personally identifiable information

The feature collects no names, no account data — only user-supplied tags and public on-chain data are cross-referenced. This privacy-preserving monitoring approach is part of the patent-pending core technology.

Why now

Japan is moving toward bringing crypto assets under insider trading rules through FIEA amendments. Starting transaction monitoring before the rules take effect — rather than scrambling after — is the preparation exchanges, issuers, and investigation teams need.

How to use it

• Register disclosure events (title, announced-at, scope, window days) in the Insider Events screen

• Add affiliation / insider-scope tags (tags are private to each user)

• Then just scan — cross-referencing and window checks run automatically, with evidence attached to findings

Note: findings are reference information indicating suspicious patterns. Legal determination of insider trading and reporting obligations remains with the user.

ML that earns its way into the verdict: supervised β-scores, honest anomaly meters, and a false-positive purge

Plenty of products put ML into risk verdicts. Few can answer the question: was that model validated on production data? Starting today, ChainAnalyzer shows you the validation process itself.

Supervised ML as a β display — visible, but not in your score

Every scan's detection list now includes the supervised ML model's fraud-probability estimate as a β reference (the purple β CRITICAL badge). The important part: this value contributes zero points to the risk score.

The model is in shadow evaluation. It joins the verdict only after passing promotion gates measured on production traffic: real-world precision, zero false alarms on known-legitimate addresses, and threshold stability over time. We don't ship "the offline metrics looked good" — earning a place in the score requires proof on production data. Until then, the β display lets you watch what the model is thinking.

An honest reframe of the anomaly meter

The unsupervised "ML Anomaly" meter has been redefined as a novelty indicator ("this behaves unlike most addresses") and no longer contributes to the risk score. Our production measurements confirmed that anomaly and malice are different things — on every chain, the statistically most "anomalous" actors are legitimate high-throughput infrastructure: exchanges and issuers. Anomaly detection keeps its value as a novel-pattern discovery tool; the shortcut "anomalous therefore dangerous" is gone. The meter now carries a "reference" badge.

A false-positive purge for legitimate infrastructure

Alongside, a precision sweep across the detection pipeline. The principle: distinguish "high activity" from "malicious":

• Graph proximity now considers direction of funds — sending to a bad address (possible victim) is treated differently from receiving from one (possible downstream)

• Contract monitoring of major legitimate tokens (e.g. USDT) no longer flags large transfers mechanically — contact detection against known-malicious addresses stays fully active

• Fake-token transfers (Unicode spoofing) are excluded from graph evidence — closing the loophole where an attacker could make anyone look risky by airdropping them counterfeit tokens

A newly discovered address-poisoning network cluster was added to ScamDB during this work and is queryable via the public API.

The β display appears on scans with the "Include ML analysis" toggle enabled. Internal detection logic (thresholds, features) is not disclosed.

The enterprise trust stack: Holder Graph forensics, tamper-evident audit trails, webhooks, and an Issuer Dashboard

This summer ChainAnalyzer shipped four features aimed squarely at compliance teams. The common theme: moving investigation results through your organization in an audit-proof form.

1. Holder Graph & Cluster Forensics (Business+)

Token holder distributions rendered as force-directed graphs, with common-funder clustering via Neo4j BFS. Sybil structures — "the top 30 holders are actually one entity's distributed bags" — become visible as graph shapes. AI-generated forensic narratives (why this cluster is suspicious) and PNG export are built in, ready to paste into an investigation report.

2. Financial-grade audit trails

Every activity log entry is now hash-chained and periodically anchored to WORM (Write Once Read Many) object storage — a two-layer design. Rewriting even a single historical row breaks the chain detectably. Nobody, including us as the operator, can silently alter history. Built for regulated environments where you may later need to prove who saw which scan result, and when.

3. Three webhook events + a dedicated delivery worker

Risk level change / watchlist update / report ready — three webhook events, delivered by a dedicated worker with retries and duplicate-delivery prevention (atomic delivery claims). Wire them into your SIEM or team chat on Pro plans and above.

4. Issuer Dashboard (Enterprise)

For stablecoin issuers: a dashboard that tracks multi-chain circulating supply and issuance/redemption flows by querying operational wallets directly on-chain — first-party data rather than aggregator estimates, aiming for accuracy you can carry into financial reporting and audits.

Holder Graph ships on Business plans and above; audit trails and the Issuer Dashboard are Enterprise features. Contact us for a demo.

Kaia goes live: 9 chains for self-serve scanning, and Watchlist learns them all

On 2026-07-11, Kaia (formerly Klaytn, ChainID 8217) became a fully supported chain on ChainAnalyzer. Not just one-off scans — Watchlist periodic monitoring, Follow Mode graph exploration, token contract monitoring, and Neo4j graph analysis all work exactly like on every other chain. That brings self-serve live chains to nine: Bitcoin, Ethereum, Polygon, Base, Arbitrum, Optimism, Avalanche, Solana, and Kaia.

Watchlist catches up to every chain

Until now the Watchlist chain picker offered Ethereum, Avalanche, Polygon, Solana and Bitcoin. We've added Arbitrum, Optimism, Base and Kaia, so every chain you can scan is now a chain you can monitor. If you track tokens deployed at the same address across multiple chains (a common pattern for regulated stablecoins), cross-chain side-by-side monitoring is now the default workflow.

Engineering note: the Kaiascan API wall and the RPC fallback

An honest implementation note. Kaiascan's Etherscan-compatible API handles wallet-scoped queries fine, but does not support contract-wide token transfer queries ("give me all transfers of this token"). Left alone, contract monitoring would spin with "0 transfers" — in our internal testing, a token with 27k lifetime transfers reported zero.

Our fix: the contract monitor falls back to fetching Transfer events directly via eth_getLogs on Kaia public RPC — a generalization of the pattern that already powers our Kaia holder derivation. Result: the same token went from 0 transfers to 10,000 transfers analyzed. The meaning of "0 findings" changed from "we didn't look" to "we looked and it's clean" — which, for a monitoring tool, is the difference that matters.

Kaia is available on all paid plans. Existing Watchlist items are untouched; just pick Kaia from the chain selector when adding new ones.

W15 INSIDER_TRADE_SUSPECT — crypto insider-trading detection without storing any PII

On 2026-05-25, ChainAnalyzer released W15 INSIDER_TRADE_SUSPECT — a new wallet-level detector designed for Japanese VASPs (cryptoasset exchange operators) and electronic payment instrument operators to flag insider-trading suspicion without storing any PII.

🎯 In one line

You never have to share employee names or IDs with ChainAnalyzer. Tag the wallet with company_affiliation and the in-scope token contract with insider_scope using the same label — W15 fires HIGH (-15) on the next overlapping trade. Direct fit for Japan's amended FIEA Article 171-7–10.

Background — Japan's amended FIEA insider-trading clause for cryptoassets

Japan's amended Financial Instruments and Exchange Act (submitted to the Diet on 2026-04-10, expected to come into force within 1 year of promulgation) creates a new insider-trading regime specifically for cryptoassets. Officers, employees, and project insiders trading their own listed token on pre-disclosure information now fall in scope.

The practical implementation blocker has been that handing employee-identity data ("who is an officer", "who is an insider") to an external analytics vendor before achieving ISO 27001 or equivalent controls is operationally untenable. W15 sidesteps this entirely.

Design — label-matching only, no PII flow

• ChainAnalyzer never receives or stores employee names, IDs, or any PII

• Customer-side admins tag wallets with company_affiliation and token contracts with insider_scope

• Matching is case-insensitive exact match on the label string — nothing else

• If a wallet labeled "Acme" trades a token labeled "Acme", W15 fires. Otherwise it stays silent.

The system only knows that a wallet and a token are "linked in the customer's view" — it has no idea who the wallet belongs to.

Workflow

1. Tag the wallet — at /account/tags, attach company_affiliation with label "Acme" and 🏢 icon to the wallet under monitoring

2. Tag the in-scope token — same UI, attach insider_scope with the same label "Acme" and 🎯 icon to the token contract

3. Scan or watchlist the wallet — standard /account/scan or add to Watchlist (Pro+)

4. W15 fires HIGH on matching trades — Detection details include up to 10 transaction samples for SAR filing / audit review

False-positive suppression by design

Detection output

{
  "detector_id": "W15",
  "detector_name": "INSIDER_TRADE_SUSPECT",
  "severity": "HIGH",
  "description": "インサイダー取引疑い: \"Acme\" 所属タグ付きウォレットがインサイダー対象トークン USDC（scope: \"Acme\"）を取引しました（5 件: 送信 3 / 受信 2）。コンプライアンスレビューを実施してください。",
  "details": {
    "company": "Acme",
    "wallet_address": "0xUserWallet…",
    "token_contract": "0xA0b86…",
    "token_symbol": "USDC",
    "tx_count": 5,
    "send_count": 3,
    "receive_count": 2,
    "sample_tx": [ /* up to 10 tx hashes for SAR / audit */ ]
  }
}

Up to 10 sample transactions are included with hash, timestamp, send/receive direction, and amount — directly attachable to a JAFIC SAR filing or audit evidence pack.

Pricing

W15 INSIDER_TRADE_SUSPECT is available on Pro and above ($19.99/month). For organizational deployments (10K+ monitored wallets, large batches, SLA), see the Enterprise plan.

Roadmap

• company_announcement table — narrow alerts to trades within ±N days of an official disclosure

• W15b counterparty detection — abnormal spike of deposits into the company exchange as a group-insider signal

• Auto-PDF compliance audit log — bundle the evidence pack for periodic audits

Links

• Set up tags now

• W15 setup guide (docs)

• Pricing

Bridge Flow Trace: tracing NEAR Intents (and 6 other privacy bridges) in one request

2026-05-24 — ChainAnalyzer is launching Bridge Flow Trace, a one-request multi-hop cross-chain forensic tracer. It auto-detects bridge solvers (NEAR Intents, Wormhole, Stargate, Across, Synapse, Hop, deBridge), follows relay chains, and emits forensic insights including same-intent correlation with sub-minute cross-chain settlement timing.

🎯 The one-line pitch

Privacy bridges like NEAR Intents are not untraceable. Read the Solver + the intent_id memo and you can prove "this is the same fund flow" — on-chain, with cryptographic certainty. 1-2 hours of manual investigation collapses to 7 seconds.

5 key insights

1. Privacy bridges are not untraceable

NEAR Intents is intent-based — the user never directly calls the bridge contract, so naive on-chain inspection only shows "a solver delivered some SOL out of nowhere." But the intent_id stamped into the Solana Memo program matches the corresponding Ethereum-side leg byte-for-byte. With Wormholescan / deBridge / NEAR Explorer counterpart APIs, you reconstruct the cross-chain link deterministically.

2. Solver wallets are heuristically detectable

Even previously-unknown solvers are classified at 90%+ confidence with three indicators:

• UUID memo ratio > 50% (proportion of TXs stamped with an intent_id)

• Balance > 1000 SOL / 100 ETH (liquidity provider scale)

• TX frequency > 50/hour (intent processing throughput)

Empirical example (a Solana NEAR Intents solver `HWjmoU...mz16`): 1000 TX / 7h = 138 TX/h, 71% UUID memo ratio, 12,241 SOL ≈ $1.5M balance → classified at confidence 0.92.

3. same_intent_correlation is the forensic smoking gun

{
  "type": "same_intent_correlation",
  "description": "Intent PzUkLi9... settled in 74s: 0.03 ETH on send → 0.687618 SOL on receive",
  "evidence": {
    "intent_id": "PzUkLi9trGapLFsSGCf37xFRwX8kyYZZ8iZvTtqwyeFRwrPEa",
    "send_leg":    { "tx": "0x046ca1fa...", "amount": 0.03,        "token": "ETH", "timestamp": "2026-02-22T07:27:23+00:00" },
    "receive_leg": { "tx": "4QZfXmpjA61A...", "amount": 0.687618, "token": "SOL", "timestamp": "2026-02-22T07:28:37+00:00" },
    "delta_seconds": 74
  }
}

One block of structured evidence proves the cross-chain identity claim on three axes: (a) matching on-chain intent_id memo, (b) 74-second temporal correlation, and (c) USD-equivalent value parity ($67-equivalent cross-chain swap). Drop it straight into a law-enforcement filing or VASP SAR submission.

4. Separating user from solver

Graph roles are 3-way: user (the real origin, your investigation target), relay (short-lived intermediary, just a passthrough), and solver (liquidity provider — infrastructure, not perpetrator). Stopping at solvers prevents the classic mistake of misclassifying infrastructure as suspect.

5. 7 seconds vs 1-2 hours

Manual: pull Solana RPC sigs → parse memos → search NEAR Explorer → reconcile via Wormholescan → trace ETH-side outbounds → identify solvers → stitch the graph. Total: 1-2 hours.
Automated: 6.8 seconds and the full graph + insights drops on your desk. The real win isn't a single SANAE-style investigation; it's processing 100 wallets in batch.

How to use

Subscribed (Business / Enterprise)

Head to /account/bridge-flow, enter an address + chain + depth, get the graph + insights.

curl -X POST https://chain-analyzer.com/api/bridge-flow \
  -H "Content-Type: application/json" \
  --cookie "session=..." \
  -d '{
    "address": "6ytB6pX3d6avtgzCkRjsyd1jkUJCutyCoc83ZeoVTC6c",
    "chain": "solana",
    "max_depth": 2
  }'

Subscription-free (x402 pay-per-trace)

For one-off investigations or autonomous agents, the x402 endpoint settles at $3.00 USDC on Base / Solana — no account, no API key.

# Single-shot, no subscription — $3.00 USDC on Base/Solana
curl -X POST https://chain-analyzer.com/api/v1/x402/bridge-flow/trace \
  -H "X-PAYMENT: <signed-eip3009>" \
  -d '{"address": "...", "chain": "solana", "max_depth": 3}'

New pricing

Engineering background

The pipeline is 6 stages: Bridge Detector → Counterpart Resolution → Node Classification → BFS Expand → Same-chain Forward Trace → Insights Post-process. The Solver registry (static + heuristic) and the bridge-contract registry (7 protocols / 32 contracts / 7 EVM chains) cooperate so that previously-unknown solvers are still classified correctly.

Deep technical dive + the SANAE TOKEN case study (the work that motivated this build): see the Qiita article (Japanese):

• NEAR Intents で cross-chain 資金洗浄を追跡する — ChainAnalyzer Bridge Flow Trace

• Bridge Flow Trace docs (technical reference)

Acknowledgement

The SANAE TOKEN investigation that motivated this build started with @hiropi_fx's initial tracing.

Links

• Try Bridge Flow Trace (Business / Enterprise)

• Bridge Flow Trace documentation

• Pricing

• x402 Discovery (all endpoints)

Building an MCP server that AI agents pay for autonomously (Claude → MCP → x402 USDC)

The default model for MCP servers is "expose your tools, trust the caller." That's fine for personal Claude Desktop tools that hit local SQLite, but it doesn't work for paid data — the moment your tool calls a real upstream API, somebody has to pay for the upstream. We took a third path: instead of static API keys baked into the MCP config, our MCP tools speak x402, and Claude (or any MCP-aware agent) signs a $0.008 USDC payment per call. No accounts. No keys. The agent gets exactly what it asked for, the upstream gets paid, and the human is out of the loop.

Highlights

• No static API keys — users provision a wallet (USDC float on Base) and that's it

• Per-call USDC settlement — agent signs autonomously, no human in the loop

• Payment plumbing is invisible to the LLM — it just calls scan_address and gets JSON back

• Natural budget boundary — when the wallet runs out, calls fail clean

Why most MCP servers can't be paid for

If you've installed an MCP server in Claude Desktop, you know the drill: static API key in env vars, rate limits to track, billing surprises at month-end. The agent might call your tool 50 times in a session and neither the agent nor the user notice. This works for genuinely free tools (local Postgres, filesystem, GitHub). It works poorly for tools that wrap an upstream that charges per call.

We wanted something better: the agent should pay for what it calls, in real money, at the moment of the call.

What x402 is, in 4 lines

x402 is the HTTP 402 status code wired up to stablecoin payments. The exchange:

1. Agent calls GET /api/risk-score?address=0xabc

2. Server replies HTTP 402 with a price ($0.008 USDC), an asset (USDC on Base), a recipient, and a payload to sign

3. Agent's wallet signs an EIP-3009 transferWithAuthorization for that exact amount, base64-encodes it, and replays the request with X-PAYMENT: <signed payload>

4. Server verifies the signature, runs the handler, settles the USDC on-chain via the Coinbase CDP facilitator, and returns the response with X-PAYMENT-RESPONSE: <on-chain receipt>

Sub-second on the protocol level. A few seconds for the on-chain settle on Base. From the agent's perspective: a 402, a retry with payment, then a 200.

Why MCP + x402 fit naturally

MCP (Model Context Protocol) is the standard for exposing tools to LLMs. Tools get a schema, a name, and a callable; the model decides when to invoke them. The runtime path:

LLM
 ├─→ MCP client
 │    └─→ MCP server (chainanalyzer-mcp)
 │         ├─→ HTTP GET /api/risk-score    ← 402 + price
 │         ├─→ wallet.sign(EIP-3009)        ← per-call payment
 │         ├─→ HTTP GET /api/risk-score    ← retry with X-PAYMENT
 │         │    [verify → handler → settle]
 │         └─→ 200 OK + risk JSON
 └─← result returned to LLM

x402 fits inside "MCP server runs handler". The MCP tool implementation makes an HTTP call to the upstream. The upstream returns 402. The MCP server has access to a wallet keypair (configured once, owned by the user). It signs the payment, replays, gets the data, returns it to the LLM. The LLM never sees the payment plumbing — it just sees "I called chainanalyzer.scan_address and got a JSON response."

The user setup is less than the API-key version, because there's no signup. Their wallet is their account.

What changed in the MCP server

Our @chainanalyzer/mcp-server used to require an API key. The new version (paid mode) uses the user's wallet:

{
  "mcpServers": {
    "chainanalyzer": {
      "command": "npx",
      "args": ["-y", "@chainanalyzer/mcp-server"],
      "env": {
        "CHAINANALYZER_X402_PRIVATE_KEY": "0x...",
        "CHAINANALYZER_X402_NETWORK": "base"
      }
    }
  }
}

The private key is the user's payment wallet (must hold USDC on Base). The MCP server uses x402-fetch under the hood to handle the 402 dance:

import { wrapFetchWithPayment } from "x402-fetch"
import { createWalletClient, http, privateKeyToAccount } from "viem"
import { base } from "viem/chains"

const account = privateKeyToAccount(process.env.CHAINANALYZER_X402_PRIVATE_KEY)
const wallet = createWalletClient({ account, chain: base, transport: http() })
const fetch402 = wrapFetchWithPayment(fetch, wallet)

// Inside the MCP tool handler:
const res = await fetch402(
  `https://chain-analyzer.com/api/v1/x402/address/${addr}/risk-score?chain=${chain}`,
  { method: "POST" }
)
return await res.json()  // automatically retried with payment

From the model's perspective, the tool either returned data (paid) or returned a "wallet has insufficient USDC" error (out of money). The latter becomes a natural budget signal — Claude tells the user "your scan budget is exhausted" instead of silently doing nothing.

Gotchas we hit

1. MCP is stdio JSON; HTTP doesn't fit that model

Most MCP servers communicate over stdio. We had to make sure outbound HTTP calls didn't clobber the stdio framing — a separate HTTP client, explicit JSON serialization before yielding back to MCP. Never let raw HTTP bytes leak into the protocol stream.

2. EIP-3009 validAfter / validBefore need real clock skew

The facilitator rejects payments whose timestamps drift too far from network time. If the user's machine clock is 2 minutes off (laptop just woken up, NTP not yet caught up), every signature gets rejected. We added 60s of validAfter tolerance and a 5-minute validBefore window so this rarely bites in practice.

3. Self-payment guard

If the user happened to set payTo to the same address as their signing key, every payment would be a self-loop and the facilitator would reject it. We catch this client-side now and throw immediately with a useful error.

4. Small-balance UX

A $5 USDC float buys 625 calls at $0.008 each — enough for a meaningful Claude session, but if the user is doing batch screening (looping over hundreds of addresses), the float drains and the next call fails. We added a chainanalyzer.check_my_balance tool the LLM can call before kicking off a batch, returning the wallet's USDC balance and the projected number of calls available.

What it costs the user

• Wallet setup: free (any Base-compatible wallet)

• Initial funding: $5 USDC on Base + ~$0.50 of ETH for occasional gas (gas is cheap on L2)

• Per call: $0.008 USDC + negligible Base gas (the facilitator pays gas, the user pays the USDC)

• No subscription, no monthly minimum

Compared to our cheapest Pro plan at $19.99/month: under ~2,500 scans/month, x402 is strictly cheaper. Above that, Pro wins (and gets unmetered AI Analysis). For agentic workloads specifically, x402 is the obvious answer — agents don't have credit cards, agents don't sign up for SaaS, but agents do have wallets.

Try it

npx -y @chainanalyzer/mcp-server

…with the wallet env vars set as above. See the chainanalyzer-mcp GitHub repo for the full README, including a 90-second setup video.

For the underlying x402 endpoint set, see our companion post: Shipping a $0.008-per-call AML API on Coinbase x402 Bazaar.

Why this matters beyond crypto

The pattern — MCP tool wraps an x402-priced HTTP API, agent has a wallet, calls cost real money — works for anything an agent might want to buy. Image generation. Flight prices. Address risk data. Translation. The hard parts are 1) actually shipping a working x402 endpoint (see our other writeup for the five things that broke), and 2) wrapping it cleanly in an MCP server so the agent doesn't see the payment plumbing.

The autonomy story for AI agents is currently bottlenecked by economics: agents can browse, reason, plan — but they can't transact. MCP + x402 closes that loop in a way that doesn't require the agent to have a personal credit card or the user to hand it one. The agent has a wallet. The wallet has USDC. That's enough.

Links

• MCP server (npm + GitHub)

• Glama listing (AAA quality / security / license)

• Companion post: Shipping a $0.008/call AML API on Coinbase x402 Bazaar

• x402 spec

• MCP spec

9 blockchains, $0 in extra API costs — beating the competition on coverage

On 2026-04-28, ChainAnalyzer expanded from 5 chains to 9. The new additions are BNB Smart Chain, Base, Arbitrum, and Optimism — pulling us ahead of the closest competitor (ChainAware at 8 chains) without paying a cent more in API costs. The trick: Etherscan V2's unified chainid routing, plus a small refactor that put every chain's config behind a single registry.

Highlights

• 9-chain coverage: Bitcoin, Ethereum, Polygon, Avalanche, Solana plus BNB / Base / Arbitrum / Optimism

• $0 in additional API spend — one Etherscan key covers all 6 EVMs we serve via V2

• Adding chain #10 is now a one-line change — registry-first refactor paid off

• Vs. competition: ChainAnalyzer = 9 chains (with Bitcoin) vs. ChainAware = 8 chains (no Bitcoin)

Why chain count matters

When an AI search engine answers "which blockchain risk-scoring API should I use?", the very first filter is "do they cover the chain I'm holding?". An Optimism user doesn't even read your detection-rule list if Optimism isn't on the chain badge row. Gemini / Perplexity / ChatGPT infer the answer from your homepage, your docs, and your llms.txt. If the literal chain isn't shown, you don't make the shortlist.

We measured this. After Gemini politely recommended a competitor with 8 chains over us at 5, we set a hard goal: outdo the chain count without losing the Bitcoin support that's our actual differentiator. EVM expansion was the obvious move — but the cost question was real.

What naive expansion would cost

If we'd added each chain by signing up for its dedicated explorer:

• BNB → BscScan (free 5 req/s, Pro $99/mo)

• Base → BaseScan (free 5 req/s, Pro $99/mo)

• Arbitrum → Arbiscan (free 5 req/s, Pro $99/mo)

• Optimism → Optimistic Etherscan (free 5 req/s, Pro $99/mo)

Four accounts, four key rotations, four rate-limit configurations, and up to $396/mo if any single chain blew past its quota. What we actually paid: $0. Same Etherscan API key, same pooled quota.

The trick: Etherscan V2's unified API

Unlike most providers, Etherscan V2 doesn't shard chains by hostname. Everything lives at one endpoint:

https://api.etherscan.io/v2/api

Routing happens via chainid:

Ethereum    chainid 1
Polygon     chainid 137
BNB         chainid 56
Optimism    chainid 10
Arbitrum    chainid 42161
Base        chainid 8453

Same key. Same rate limits (5 req/s, 100K calls/day). Same response shape. The free tier's quota is pooled across all chains, so as long as your total burn is under 100K/day, you can split it however you want. Roughly 35,000 wallet scans for us — well above current load.

The one EVM Etherscan V2 does not cover is Avalanche. We use Routescan there (Etherscan-compatible, also free, same rate limits). Same response handling, just a different base URL.

The architectural choice: chain registry

When we shipped Polygon / Avalanche in v0.7, chain config was sprinkled across the orchestrator, the Neo4j ingestor, plan-gating, the UI selector, native-token symbol maps, and the marketing pages. Adding chain #6 the naive way meant grepping for "polygon" across 50+ files.

So we paid down the debt first. Chain metadata now lives in a single apps/api/app/services/chains.py:

EVM_CHAINS = {
    "ethereum":  {"chainid": 1,     "native": "ETH", "explorer": "etherscan_v2"},
    "polygon":   {"chainid": 137,   "native": "POL", "explorer": "etherscan_v2"},
    "bnb":       {"chainid": 56,    "native": "BNB", "explorer": "etherscan_v2"},
    "base":      {"chainid": 8453,  "native": "ETH", "explorer": "etherscan_v2"},
    "arbitrum":  {"chainid": 42161, "native": "ETH", "explorer": "etherscan_v2"},
    "optimism":  {"chainid": 10,    "native": "ETH", "explorer": "etherscan_v2"},
    "avalanche": {"chainid": 43114, "native": "AVAX", "explorer": "routescan"},
}

SUPPORTED_CHAINS = {**EVM_CHAINS, "bitcoin": ..., "solana": ...}
EVM_CHAINS_SET = frozenset(EVM_CHAINS)
SUPPORTED_CHAINS_SET = frozenset(SUPPORTED_CHAINS)

def is_evm(chain: str) -> bool:
    return chain in EVM_CHAINS_SET

Adding chain #10 is now genuinely a one-line change — the orchestrator, ingestor, native-symbol resolver, and is_evm() helper all pick it up automatically. The frontend chainanalyzer.ts got a symmetric isEvmChain() helper.

That's the diff that mattered. Everything else was bookkeeping.

The bookkeeping (still real work)

• 76+ detection rules — mostly chain-agnostic, but native-token transfer detection had to know "chain 56 = BNB" / "chain 8453 = ETH"

• Plan gating — Free stays Solana-only, Starter+ gets all 9. Already centralized, one-line update

• Chain selector UI — both marketing and scan-screen dropdowns grew four entries

• Marketing copy — every "5 chains" reference across marketing/, news/, docs/, llms.txt, CLAUDE.md, GitHub README, chainanalyzer-mcp. Caught with a single grep checklist (docs/CHAIN_EXPANSION_5_TO_9_CHECKLIST.md)

• Neo4j graph ingestor — native-symbol map updated:

NATIVE_TOKEN_SYMBOL = {
    "ethereum": "ETH", "polygon": "POL", "avalanche": "AVAX",
    "bnb": "BNB",       # native = BNB
    "base": "ETH",      # native = ETH
    "arbitrum": "ETH",  # native = ETH
    "optimism": "ETH",  # native = ETH
}

• CoinGecko ID mapping — BNB → binancecoin, L2s → ethereum

The registry-first refactor turned what would have been a 50+ file change into a single PR. Nothing exotic.

What we deliberately skipped

• TRON — non-EVM (TVM, Base58Check), TronGrid is a separate API surface, the address detection / signing flow is different. Customer demand is real, so it's a Phase 2 target

• TON — non-EVM, Toncenter is a separate API. Phase 2

• HAQQ — usage too small to justify

The registry is now ready for non-EVM chains too — they just need a non-EVM branch in the orchestrator.

Did it work?

Coverage: yes. 9 chains with Bitcoin vs. ChainAware's 8 chains without Bitcoin — a clean surface-filter win for AI search engines that lead with chain count.
Cost: yes. Monthly API spend before / after expansion: $0 / $0.
Visibility: partial. Gemini hasn't yet re-indexed the updated chain count (current 7-query baseline is still 0/7 surfacing — we expect 1-4 weeks of crawl lag for the structured data + disambiguating description shipped alongside this expansion). Perplexity, Claude Web, and ChatGPT already pick up the 9-chain coverage from our docs and llms.txt.

If you're an Etherscan API user who hasn't migrated to V2 yet — do it. Same key, more chains, no extra cost.

Links

• ChainAnalyzer (main product)

• Etherscan V2 docs

• Routescan (Avalanche)

• ChainAnalyzer MCP server

Shipping a $0.008-per-call AML API on Coinbase x402 Bazaar

On 2026-04-28, ChainAnalyzer cleared its first production mainnet settlement on Coinbase x402 Bazaar. An AI agent autonomously paid $0.008 USDC on Base, and in under 30 seconds got back a CRITICAL risk verdict with 64 detections on a Tornado Cash address — 76+ rules, ML anomaly scoring, Neo4j graph traversal. No account, no API key, fully settled on-chain.

Highlights

• Full x402 v2 spec compliance — verify + settle both running on real mainnet via EIP-3009 transferWithAuthorization through the Coinbase CDP facilitator

• Coinbase Bazaar auto-indexing — no submission form, no fee. The first successful settlement is the cataloging trigger

• Tornado Cash demo returned CRITICAL — 64 detections (Address Poisoning, Peel Chain, Fake Token URL Phishing, Sybil Aggregation, Token Relay)

• Nine chains — Bitcoin, Ethereum, Polygon, Arbitrum, Optimism, Base, Avalanche, Solana. Bitcoin coverage is unusual in this space

• No subscription needed — any AI agent that holds USDC can call the AML API in a single fetch()

Why x402 actually matters for AI agents

Most API products assume a three-step onboarding: create an account, generate a key, set up a subscription. For AI agents that's a fatal source of friction — the agent wants to act autonomously, but it has to wait for a human to register and provision credentials before it can do anything.

x402 turns HTTP 402 (Payment Required) from a curiosity into a real protocol. The server returns payment requirements in the 402 response; the client signs USDC authorization, replays the request with the signature in an X-PAYMENT header; the Coinbase CDP facilitator verifies and settles on-chain; the server returns the actual response after settlement clears.

Net effect: any AI agent that holds a wallet can call ChainAnalyzer's AML primitives one request at a time, without a subscription contract or an API key. Coinbase Bazaar / Agentic.Market is the marketplace that catalogs every endpoint built this way and lets agents discover, compare, and call them.

Five things that broke (and how we fixed them)

The x402 v2 spec is new enough that rolling your own implementation has multiple failure modes. Sharing the ones we hit, in case they save someone a day.

1. The verify wire format is nothing like the legacy x402 examples

The first hand-written implementation POSTed {"payment": "<base64>", "requirements": {scheme, price}} to the facilitator. That has nothing to do with v2. The correct shape is:

{
  "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
  }
}

The load-bearing field is paymentPayload.accepted — the client echoes back the exact requirement they signed for. Without it the facilitator can't bind the signature to a network / asset / payTo, which is the whole point of the protocol. Hand-rolling this is a trap; use the official x402 Python or TypeScript SDK and let the lib own the schema.

2. There was no settle call

Verify only checks "is this signature valid for this requirement." Actually moving USDC requires a second POST to /settle. The original implementation called verify, treated success as final, and returned the API response — meanwhile no USDC had moved on-chain. We replaced the whole pipeline with the official x402 Python lib's HTTPFacilitatorClient, then wrapped the middleware as verify → handler → settle.

3. The SvelteKit proxy was stripping X-PAYMENT

Calls to /api/v1/x402/... looped on 402 forever because the catch-all proxy in front of FastAPI only forwarded X-API-Key and Content-Type. X-PAYMENT and PAYMENT-SIGNATURE have to be forwarded explicitly, and the matching X-PAYMENT-RESPONSE exposed on the response side.

4. esm.sh transitive dep hell

Trying to wire up a browser demo via esm.sh, x402-fetch@1.2.0 internally imports @solana/rpc-parsed-types@5.5.1, and that subpath isn't published on esm.sh — it returns text/plain 404, which Firefox surfaces as "MIME type not allowed" (a CSP-flavored error message that sends you down the wrong rabbit hole). The fix that worked: drop x402-fetch entirely and sign EIP-3009 directly with viem's signTypedData_v4. About 50 lines.

5. Self-transfer (from == payTo) silently fails verification

The first end-to-end test connected Phantom to the same address used as the treasury payTo. The signed message was transferWithAuthorization(from=A, to=A, value=8000) — technically valid, semantically a no-op. The facilitator rejects it without a useful invalid_reason. Add a client-side from != payTo assertion before signing; it saves an hour of staring at HTTP 402 responses.

What it actually returned — Tornado Cash, 64 detections

For the end-to-end smoke test we hit the Tornado Cash 0.1 ETH pool address (0x0000db5c8b...e70000) and got back:

• risk_level: CRITICAL

• detection_count: 64

• ml_anomaly_score: 0.4381 (3-model ensemble — Isolation Forest + AutoEncoder + GraphSAGE)

• Top detector classes: 30+ Peel Chain (E8), 13 Fake Token URL Phishing (E16), Address Poisoning Received (E6), Sybil Aggregation (E12), Token Relay Chain (E15)

• scan_duration_ms: ~30s (running all heuristics + ML + Neo4j across 9 chains)

Settlement is on-chain: the receiving address chainanalyzer.eth (0xe8e26183...708959) shows the +0.008 USDC transfer on Basescan.

Try it

See the 402 (no payment, just the price tag)

curl -i https://chain-analyzer.com/api/v1/x402/address/0x0000db5c8b030ae20308ac975898e09741e70000/risk-score?chain=ethereum
# HTTP/2 402 Payment Required
# {
#   "x402Version": 2,
#   "accepts": [
#     {
#       "scheme": "exact",
#       "network": "eip155:8453",
#       "price": "$0.008",
#       "payTo": "0xe8e26183...708959",
#       "asset": {
#         "address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
#         "decimals": 6,
#         "eip712": { "name": "USD Coin", "version": "2" }
#       }
#     },
#     { "scheme": "exact", "network": "solana:5eykt4Us...", ... }
#   ],
#   "extensions": { "bazaar": { "discoverable": true, ... } }
# }

Pay with Phantom in the browser (no code)

Open chain-analyzer.com/x402-demo.html, connect Phantom on Base, click "Pay $0.008 USDC and scan". EIP-3009 prompt fires, ~30 seconds later the risk-score JSON drops in. Solana works the same way.

Call from an AI agent (TypeScript)

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/api/v1/x402/address/" +
    "0x0000db5c8b030ae20308ac975898e09741e70000/risk-score?chain=ethereum",
  { headers: { "X-PAYMENT": buildPayment(account, /* ... */) } },
)
const score = await res.json()
// score.risk_level === "CRITICAL", score.detection_count === 64
// score.detections[i].detector_name === "ADDRESS_POISONING_RECEIVED" ...

The full menu (six x402-native endpoints)

• GET /api/v1/x402/address/{address}/risk-score — $0.008 USDC. AML risk score + detections + ML anomaly. 8 chains live + BSC coming soon.

• GET /api/v1/x402/address/{address}/sanctions — $0.003. OFAC / FATF / JFSA / ScamDB cross-reference.

• GET /api/v1/x402/tx/{tx_hash}/trace — $0.015. Fund-flow tracing with ML anomaly detection.

• GET /api/v1/x402/tx/{tx_hash}/coinjoin — $0.01. CoinJoin / mixing / tumbling detection on Bitcoin.

• GET /api/v1/x402/wallet/{address}/cluster — $0.02. Neo4j graph clustering / entity resolution.

• POST /api/v1/x402/batch/screening — $0.05. Batch AML screening across up to 50 addresses.

The bigger picture

With this in place, an AI agent can run an AML check on a counterparty wallet, evaluate the result, and decide on-chain whether to send funds — entirely without human intervention. Compliance and fraud detection move from "a human looking at a dashboard" to "an agent verifying autonomously." That's a meaningful step.

As far as we can tell, ChainAnalyzer is the first production AML API to clear a real mainnet settlement under the x402 v2 spec on Coinbase Bazaar. Auto-indexing on agentic.market should land within 24-48 hours of the first settlement.

Links

• x402 Live Demo — settle directly from the browser via Phantom

• x402 Service Manifest (the JSON Bazaar reads)

• x402 Discovery Endpoint (all priced routes)

• x402 Protocol

• Coinbase CDP x402 Docs

• ChainAnalyzer MCP server (npm)

• ✅ 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.