1,382 Algorand routes the newest x402 client can't pay
Algorand has two ways to write its network in an x402 payment option. One is the whole genesis hash, algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=. The other is the CAIP-2 id, its first 32 characters: algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73k. Both name the same chain. Until this week the official x402 client accepted both. Since @x402/avm 2.29.0, published on 28 October 2026, it accepts only the short one, and most Algorand sellers use the long one.
What changed in 2.29.0
Both versions turn an option's network into the id they work with, in normalizeAlgorandNetwork. In 2.28.0 the whole genesis hash was mapped to the CAIP-2 id. In 2.29.0 those two lines are gone: anything but the CAIP-2 id throws Unsupported Algorand network. We reproduced it with the 2.29.0 client: the whole-hash option fails at once, the CAIP-2 option goes on to build the payment.
The short form is the one the x402 docs give (network and token support): CAIP-2 caps a chain reference at 32 characters. So 2.29.0 follows the standard; it just stopped forgiving the form many sellers copied before.
Who is affected
The x402 Trust Index checks every paid x402 endpoint it can find each day. In the scan of 29 October 2026:
| Algorand network id in the 402 | Routes | Sellers |
|---|---|---|
| Whole genesis hash only, no other network | 1,382 | 96 |
| Whole genesis hash, plus other networks (Base, Solana, Polygon, Tempo, …) | 955 | |
| Both forms side by side | 37 | |
| CAIP-2 id only | 814 |
Together 2,374 routes from 123 sellers use the whole hash, against 851 routes from 85 sellers with the CAIP-2 id. Our own services moved to the CAIP-2 id with the 2.29.0 upgrade on 29 October, after that scan, and are left out of these numbers. The 955 routes that also take Base or Solana stay payable for most agents, which simply pick another option. The 1,382 Algorand-only routes are the ones a buyer on 2.29.0 can't pay at all; the Trust Index still rates 1,053 of them "go", because older clients pay them fine.
We also probed a sample of live Algorand sellers on 29 October: of the seven that answered with a 402, six sent the whole hash. GoPlausible's discovery list writes the whole hash for 2,633 of its 2,731 routes, also for sellers whose own 402 uses the CAIP-2 id (ours does), so a buyer should read the network from the live 402, not from the list.
A second cost: Coinbase's Bazaar
Coinbase's validator for the CDP Bazaar rejects the whole hash as not CAIP-2, and with it the whole endpoint. A seller that offers Base and Solana next to Algorand by the whole hash isn't indexed in the Bazaar, where Coinbase's agents look, even for the Base option. We found it on an endpoint with four networks this week.
The fix for sellers
- Use the CAIP-2 id in your payment option:
"network": "algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73k"(testnetalgorand:SGO1GKSzyE7IEPItTxCByw9x8FmnrCDe). - Register the scheme under that id:
resourceServer.register("algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73k", new ExactAvmScheme()). With 2.29.0 on the server the long id no longer works anyway. - Check your facilitator. GoPlausible's lists both ids in its
/supported, so nothing changes there. A facilitator of your own on 2.29.0 takes only the CAIP-2 id.
x402 Doctor now warns about the whole hash in its report and gives these lines as a fix.
The fix for buyers
- Hand the scheme the CAIP-2 id and keep the seller's own option as the payment's
accepted, so the seller still recognises it. x402-safe-fetch 0.8.1 does this, and pays both forms with 2.29.0. - Match offers on both ids when you filter by network, or you miss half the sellers either way.
- Or stay on @x402/avm 2.28.0 until the sellers you pay have moved.
x402 Doctor's preflight now tells an agent when an option names Algorand by the whole hash, and which id to use.
How we checked
normalizeAlgorandNetworkread in the published@x402/avm2.28.0 and 2.29.0 packages (npm, 29 October 2026); the 2.29.0 client run on an option in each form.- Route counts from the x402 Trust Index scan of 29 October 2026: the networks in each route's latest 402.
- GoPlausible's facilitator
/supportedand its discovery list (2,731 routes), read the same day; a sample of 25 hosts from that list probed live.
The Trust Index is an open dataset on Hugging Face, and this article is also there as a community article.
Questions
Which Algorand network id should an x402 seller use?
The CAIP-2 id: algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73k for mainnet and algorand:SGO1GKSzyE7IEPItTxCByw9x8FmnrCDe for testnet, the first 32 characters of the genesis hash. That is the form the x402 docs give and the only one @x402/avm 2.29.0 accepts.
My Algorand endpoint worked yesterday. What changed?
Nothing on your side. @x402/avm 2.29.0, published on 28 October 2026, removed the mapping 2.28.0 had from the whole genesis hash to the CAIP-2 id. Buyers who upgrade now get "Unsupported Algorand network" on your option and can't pay it.
Do I need a new facilitator?
Not with GoPlausible: its facilitator lists both ids in /supported. If you run your own facilitator on @x402/avm 2.29.0, it accepts only the CAIP-2 id, so switch the network in your 402 and the facilitator together.
How can a buyer still pay these sellers?
Hand the Algorand scheme the CAIP-2 id while keeping the seller's own option in the payment, as x402-safe-fetch 0.8.1 does, or stay on @x402/avm 2.28.0 for now. x402 Doctor's preflight says when an option uses the whole hash.
Check an x402 endpoint before you pay it with x402 Doctor, and a transaction before you sign it with presign-guard.