Fireblocks Brought Spend Governance. AllUnity Brought a Krona. x402 Stopped Being a One-Rail Protocol This Week.

Two announcements landed on May 20 and they were not the same announcement. Fireblocks, the institutional crypto custodian rather than a startup, joined the x402 Foundation and shipped the security extension that adds request integrity and spend governance to the protocol. The same day, AllUnity, the German MiCA-regulated stablecoin issuer backed by DWS, Flow Traders, and Galaxy Digital, rolled out Agentic Payments using x402 to accept agent-initiated transactions and settle them into a Swedish krona stablecoin called SEKAU. One added institutional spend controls. The other added a non-USD currency under European banking-grade regulation. The next morning, a third party showed up on the v0.3.2 spec thread offering a non-Coinbase, three-rail acceptance fixture. x402 was a Coinbase-and-Cloudflare default six months ago. After this week, the variant axis is open.

What landed on May 20

Fireblocks did not just sign onto the foundation. They contributed a security extension that addresses two missing pieces of the protocol as shipped: request integrity (proving the agent signed the request the facilitator is settling) and spend governance (operator-side controls on per-agent, per-window, per-counterparty limits). These are the controls a treasury team needs before letting an autonomous agent draw against a corporate wallet. They are not nice-to-have. They are the gate between “demo with a developer wallet” and “production with a finance department.” Fireblocks landing this as a foundation extension, not a proprietary product, is the institutional-rail equivalent of TLS extensions getting contributed back to the standard instead of bolted on.

AllUnity went the other direction on the same protocol. Their Agentic Payments rollout uses x402 to accept agent-initiated transactions and settles directly into local bank accounts via SEKAU, the MiCA-compliant krona stablecoin they are issuing under the EU framework. Two things matter here. First, x402 is now being used to acquire payment in a non-USD asset under EU regulatory cover. Second, the settlement leg lands in a real European bank account, not a self-hosted custody wallet. That means the off-ramp is regulated, audited, and recognizable to the European Banking Authority. The Coinbase-on-Base default did not change. A second supported path opened next to it.

The variant axis the spec has been missing

The x402 spec has had a quiet structural gap. Conformance testing has mostly run against test-echo-cdp, which is Coinbase’s reference facilitator on Base USDC. That is the right reference. It is also a single-rail reference. If every conformance run uses the same facilitator, the same chain, and the same asset, the spec proves it works in that lane and proves very little about whether it works in any other lane. The variant axis is the dimension where you swap one of those (facilitator, chain, asset) and check that the protocol shape (extensions.bazaar, the per-route manifest, the well-known discovery endpoint, the receipt format) still holds.

The v0.3.2 work item labeled D.5, variant-aware extensions.bazaar, is the first time that gap is named explicitly. The work needs fixtures that aren’t test-echo-cdp. Without them, the spec keeps shipping with “works on Coinbase Base USDC” as an implicit assumption.

On the morning of May 21, a third party named hypeprinter007 offered the spec authors api.anchor-x402.com as exactly that fixture, on x402-foundation/x402#2207. Three rails on the same sixteen paid endpoints: Base USDC via CDP, Solana USDC via CDP, and JPYC on Polygon through a single-wallet, self-hosted facilitator running an EIP-712 domain of “JPY Coin” v1. Per-route manifest on every paid endpoint. Root /.well-known/x402 live. Source open at github.com/hypeprinter007-stack/anchor-x402, with the JPYC rail in services/jpyc_facilitator.py. The non-Coinbase, non-USD, non-CDP variant the spec was missing, offered as a stable fixture for the v0.3.2 cycle.

Read those three things together. Fireblocks at the governance layer, AllUnity at the regulated-currency layer, anchor-x402 at the facilitator-and-rail layer. The same week-shape shows up. The single-rail period is closing.

Why this matters for builders shipping agents

If you have been building against x402 for the last six months, the implicit stack you have been writing toward is: agent signs an EIP-3009 authorization on Base, facilitator is Coinbase, asset is USDC, receipt lands as a hash on Base. That stack is still the default. It is still the path of least resistance, and as we wrote about two weeks ago, the convergence around USDC-on-Base-via-Coinbase is the load-bearing thing under the agentic stack, not a coincidence.

What changed this week is that the second and third paths now exist as first-class options, not workarounds. A treasury-conscious enterprise can point at Fireblocks governance and have an answer to “how does our CFO approve this.” A European business can point at AllUnity and SEKAU and have an answer to “does this work under MiCA without rebuilding the stack.” A spec implementer can point at anchor-x402 and have a non-CDP fixture to test against. None of those answers existed in this form on Monday.

Where TensorFeed sits in this

We run the Coinbase-on-Base lane. TensorFeed’s premium endpoints accept the canonical Coinbase x402 V2 wire format, settled by CDP’s facilitator, on Base, in USDC. We are not a JPYC facilitator and not a krona issuer. Our value in a multi-rail world is exactly the same as it was in a single-rail world: we are a real paid endpoint that an autonomous agent can discover, pay, and read data from, with verifiable receipts. Whether the agent paid in USDC through Coinbase, in SEKAU through AllUnity’s settlement leg, or in JPYC through anchor-x402’s self-hosted facilitator, the data-buying side of the trade does not change.

We also offered tensorfeed.ai/api/premium/* as a corroboration target for v0.3.2 D.5 on the same thread, which is the CDP-on-Base lane of the same conformance work. The anchor-x402 offer covers the variant lanes we cannot. The spec authors will likely want both, because that is what “variant-aware” means when the word is taken seriously.

Our Take

The Coinbase-on-Base default is not going anywhere. It is the path of least resistance, it has the most tooling, and the convergence we wrote about with the AWS AgentCore Payments launch and the Google A2A x402 extension reinforces it weekly. That part of the story is stable.

What is no longer stable is the assumption that saying “x402” means USDC-on-Base-through-CDP. After May 20, x402 is a protocol with an institutional governance extension, a MiCA-regulated non-USD acceptance path, and an emerging non-Coinbase conformance fixture covering Solana and JPYC. The spec just stopped being a single-rail story. That is small if you only read the press releases and large if you read the work items they unlock. Variant-aware extensions.bazaar, multi-currency settlement receipts, and a conformance test matrix that does not assume Base USDC are the next three boring-sounding things that have to ship for this to be a real protocol. None of them ship without the three data points from this week.

The agent payments stack has spent two years asking which stablecoin, which chain, which custodian. The answer was, and still is, USDC, Base, Coinbase. The new question, the one this week opened, is which other rails count as conformant, and who certifies them. That is the question the foundation now has to answer in public. We will be watching.