As of 14:29 UTC today, a paid call to any BlindOracle SKU can be settled in USDC on three chains instead of one. The 402 challenge now carries x402 exact entries for Polygon PoS (eip155:137) and Arc (eip155:5042), verified and settled by Circle's Facilitator Service, alongside the Base entry that Coinbase's facilitator has settled since the start and the batched Base option we added in September.
Nothing changes for a buyer on Base. The Base entry is still accepts[0], so a client that takes the first entry behaves exactly as before, and the receipt it gets back verifies the same way. The fee is the same 20% on every chain, because the fee is a function of the price, not of where the USDC lands.
Measured against the public API at 14:30 UTC, over all 53 catalog entries:
| Count | |
|---|---|
| SKUs offering Polygon | 48 |
| SKUs offering Arc | 44 |
| SKUs whose 402 header grew past 4 KB because of this | 0 |
| SKUs already over 4 KB before today (unchanged) | 2 |
The gap between 48 and 44 is a tradeoff we chose, not a policy. Our payment-required header has to stay under 4,096 bytes because two discovery engines stop indexing a SKU above that, which we measured in September when the terms notice first had to fit in the same header. So the gateway builds the challenge, measures the header, and drops the new chains first, Arc before Polygon, until it fits. Four SKUs had room for one extra chain and not two. The two ops report SKUs that were over budget before today are still over budget and offer Base only, which is where they were. We rejected the alternative, shrinking the Base entry to make room, because the Base entry is the one every existing client parses.
Circle's own seller score for api.craigmbrown.com went from 95 to 100/100 with the change. The missing five points were the multiChain check. That is a number Circle computes from our live 402 and our OpenAPI document, not one we typed.
The code was the small part. The same three fail-open hooks we used for the batched rail: offer the chains in the 402, trim them if the header overflows, and route a payment whose network names Polygon or Arc through Circle's /verify and /settle instead of Coinbase's. Nineteen tests, one module, staged through the same deploy gate as every other gateway change, which exists because 54 raw restarts in ten days once cost buyers a four-second 502 each.
The large part was a credential. Circle's facilitator needs a mainnet API key to settle. We created one, Standard access, mainnet, and every authenticated call returned 403 Forbidden. The allowlisted IP matched our egress. A second key with no allowlist at all returned the same 403. The key's "Last Used" field never advanced past its creation time, so Circle was rejecting us before it even matched the key.
The docs state the cause in one sentence, on the keys page, in the negative: "Mainnet access for Swap and Earn doesn't require completing full onboarding or identity verification." Everything else does. The Console had an onboarding flow we had never finished. Adding a payment card completed it, and both keys returned 200 within seconds. Nothing on the error, the key page, or the facilitator docs pointed there. If your Circle key returns 403 on every endpoint and the sandbox says "invalid credentials" for the same key, it is onboarding, not the key.
One consequence worth knowing before you repeat this: the first payment you settle with an API key binds the payout address to your Circle account and ends that address's keyless trial. That is the intended end state for us, because our payout wallet is the treasury every receipt already names. It is a one-way door, so pick the payout wallet first.
Being payable on three chains puts us in front of exactly as many buyers as before until we are listed where those buyers look.
Circle's discovery index, the one its agent skill tells every buyer to search before declining a task, holds 2,583 Base resources, 1,802 Polygon and 2,182 Arc as of this morning. BlindOracle is in none of them. Our listing form went in on September 19 and never produced a reply. The 100/100 score and today's chains go into a fresh submission today. Until that lands, "multi-chain" is a true statement about our 402 and an empty one about our sales ledger.
We also have no outside purchase on Polygon or Arc yet. Our own test wallet is funded through Circle Gateway as this goes out, and the first two settlements, one per chain, will be appended below with their transaction hashes when they complete. If they do not complete, that will be appended too.
Proceeds from these chains land in our treasury wallet on Polygon and on Arc, not on Base. Nothing sweeps them back yet. That is the next piece of work, and it will appear in the update section when it ships, not before.
Circle's docs describe a wide product line: agent wallets, developer-controlled wallets, a compliance engine, a payments network for fiat payouts, Mint, StableFX. We read them. We did not adopt any of them, because none changes what a pay-per-call seller at our volume can do this month. We did not add Circle's webhooks either: the facilitator has none, and the Gateway webhooks that do exist announce deposits we already poll for. We did not move the treasury to a Circle wallet, because the one we have signs every receipt and delegation chain we have ever issued, and a wallet change would orphan that history.
A chain is not a feature. It is a listing you have not earned yet.
Request any SKU without payment and read the 402:
`` curl -s -X POST https://api.craigmbrown.com/v1/services/reputation.lookup \ -H 'Content-Type: application/json' -d '{"agent_name":"zuri"}' | jq '.accepts[] | {network, asset, amount, payTo}' ``
Pick the accepts entry whose network is eip155:137 or eip155:5042, sign an EIP-3009 transferWithAuthorization for that chain's USDC under the extra.name / extra.version domain the entry gives you, and resend with the standard PAYMENT-SIGNATURE header. You need USDC on that chain and nothing else, because the facilitator pays the gas. The SDK and the x402 client libraries do the signing for you; a Grok Bot or any MCP client follows the kit instead and never touches a key.
If you want to know what to buy first, the SKU guide walks the ten cheapest ladders, and the free catalog endpoint lists every price.
The test wallet bought reputation.lookup ($0.01) once per chain, paying from USDC that reached Polygon and Arc through Circle Gateway's forwarding service (0.12 USDC each, Circle paid the destination gas, both transfers finalized in under five minutes).
| Chain | Settlement transaction | Block | Gateway latency |
|---|---|---|---|
| Polygon PoS | 0xd5151845c0d3…1342b7 | 96905645 | 6.1 s |
| Arc | 0x3c107228784d…6394c1 | 30026367 | 3.9 s |
Both receipts read status 1 on their chains, both rows landed in the revenue ledger as settled_cash on rails polygon_usdc_x402 and arc_usdc_x402 with the standard 20% fee split, and the payout address is now bound to our Circle account as described above.
Two things did not go cleanly, and they are the kind we publish. First, the SKU itself answered HTTP 422 after settling: the reputation handler produced the record and then filed it as an execution failure, so a refund was queued for a one-cent job that had, in fact, delivered. That defect predates today's rail and is logged against the handler, not the payment path. Second, our refund path pays on Base only. A Polygon or Arc buyer who is owed a refund today gets it on Base at the same address. That is acceptable for an EVM wallet and wrong for anyone else, and it is the next fix. Both were found by paying ourselves one cent before telling anyone to pay us a dollar.