JULY 7, 2026 · ANNOUNCEMENT

Your agent can now pay for anything. Nothing checks whether it was allowed to.

OP Crossrail. Delegate once. Enforced before the payment exists.

Note added 8 August 2026. This post describes the cross-rail budget without distinguishing it from the per-transaction ceiling. They are not equivalent. The ceiling is enforced against signed mandate content; the cross-rail budget is enforced against a local file the agent owns and can reset, shared only by adapters co-located in one process. The budget has never run in production. The three-rail run described below was demonstrated on one workstation, and its x402 leg settled on Base Sepolia, a testnet, while the Lightning and TRON legs were mainnet. See /crossrail for what it is and is not. The post is otherwise unedited.

On July 1, Cloudflare announced the Monetization Gateway: any API, dataset, or MCP tool behind Cloudflare can now charge agents per call, settled in stablecoins over x402. It is a serious piece of infrastructure, and it completes one half of agentic commerce. The seller side is gated at the edge. The buyer side, the agent holding the keys, is governed by nothing.

x402's design principle is that the payment itself is the credential. That is elegant, and it is also the gap: a payment proves the agent had funds. It proves nothing about whether the agent's principal authorized the spend, at what limit, on which rails. As agents gain the ability to pay for anything, nobody in the flow is checking what they are allowed to pay for.

Today we are releasing the missing half.

One credential, three rails, and a payment that never existed

OP Crossrail is a buyer-side enforcement layer for agent payments: one signed, portable mandate, enforced natively at each rail's own boundary, before the payment exists.

Here is the launch demo, committed as a transcript in the repo. A principal signs one delegation: $5.00 per rolling 24 hours, across every rail the agent operates on. Conversion rates are attested inside the credential itself, no oracle, no runtime dependency on us. Then the agent goes shopping.

It buys an API call from a seller running Cloudflare's x402-proxy-template, unmodified, exactly as Cloudflare ships it: 402, sign, pay, 200. It runs a 5,940-sat L402 invoice through the engine's pre-payment hook, called in-process on a synthetic invoice: no LND node, and the engine ships no payment path. It moves 2 USDT on TRON through the policy engine running on the WDK's policy hook (Tether's PR #55). Two more x402 calls, and the budget sits at exactly $5.00, spent to the cent across three rails under one credential.

Then it tries once more, and this is the part that matters. The payment is not declined. It is not reversed. It never comes into existence. The mandate check runs inside the standard x402 client, before the signer, and a denial means the EIP-3009 signature is never created. There is nothing to settle, nothing to dispute, nothing to claw back. The seller's resource stays behind its 402.

The next Lightning attempt is refused at the pre-payment hook. The next TRON transfer is refused inside the WDK policy engine, the transfer is never invoked. Three rails, three enforcement points: the key, the hook, the engine. One shared budget, one append-only decision log.

Nothing in the demo is staged. Every take settled against the production x402.org facilitator, on-chain on Base Sepolia: the first take at blocks 43667763–64, the committed take at blocks 43793016–43793058, and every transaction hash is committed in the repo's fidelity notes, independently checkable on any Base Sepolia explorer. The buyer wallet holds zero ETH; the facilitator broadcasts and pays gas. When we re-probed the facilitator with an already-settled payload, it returned invalid_exact_evm_nonce_already_used: Coinbase's own infrastructure attesting that our authorization was consumed on-chain. The repo also ships a local facilitator that simulates only the settlement hop, for self-contained CI runs; the fidelity notes label which configuration produced what, per take, stated plainly.

What shipping fail-closed actually requires

A detail from the build that says more about the product than any feature list. Adding the TRON rail surfaced a subtle attack: our counterparty matching, like most EVM tooling, folded addresses to lowercase before comparing. Correct for hex, wrong for base58, which is case-sensitive, an attacker could grind for a keypair whose address lowercases to an allowlisted one. The shipped core now matches exact-case on non-EVM rails, and there is a conformance case proving a case-twiddled variant of an allowlisted TRON address is rejected. Every engine runs against a 245-case parity harness so that a verdict on one rail is the same verdict on every rail.

That is what enforcement means to us: fail-closed by default, deny anything unestablishable, and count the worst case the key could authorize, not the best case the server reports. It is also why unknown assets deny. If the principal had not attested a USDT rate inside that credential, the TRON leg would have refused with "no principal-attested rate." Stale rates are the principal's own risk, by construction. That is what self-custody of authority means.

Open, and structurally so

Three engines ship with Crossrail today, MIT-licensed, on npm: @observer-protocol/x402-op-authorize, @observer-protocol/l402-op-authorize, and @observer-protocol/wdk-op-policy, plus the shared core they all run on, @observer-protocol/policy-engine. Credentials are W3C Verifiable Credentials; everything in the demo verifies without us, offline. To our knowledge, this is the first open enforcement layer spanning both 402 lineages, x402 and L402, plus wallet-SDK signers under one credential.

The enforcement layer is free, and not as a pricing decision. Metering the check would break fail-closed operation and portability, so it cannot be metered, by anyone, and that is the point. Engines for MPP/Tempo and OWS already exist and join Crossrail as their integrations enter the public set; Liquid, via a policy hook demonstrated in an instrumented Aqua build (not in shipped Aqua), is next; the Monetization Gateway's native cloudflare:402 scheme is on the roadmap, and we are waitlisted for the Gateway. Governance, issuance, caps, revocation, and audit, the things principals actually operate, live in Agentic Terminal.

Why buyer-side, and why every rail

Agents will transact for consumers and enterprises at real scale: API access today, procurement, travel, and portfolios next. And the reason today's agent economy runs on micropayments is not that agents are small. Ticket size is the industry's only risk control: nobody lets an agent move ten thousand dollars when nothing enforces what it may do. Enforcement at the signing boundary replaces smallness as the risk control. That is what unlocks everything above the penny.

Payments will never converge on one rail; they never have, and the same week Cloudflare shipped the Gateway, more than 140 companies announced OUSD: Visa, Mastercard, Stripe, and BlackRock in the consortium, and the chains committing in public within days, Solana and Tempo natively from day one, Stellar and Aptos alongside. The money itself is now multi-rail by design. Enforcement that cannot be bypassed must live at each rail's own signing moment, and signing moments are irreducibly per-rail. Put those two facts together and only one architecture survives: a portable mandate, enforced natively at every boundary, on every rail your agent touches.

Delegate once. Enforced before the payment exists.

Read the transcript, run the demo, break the harness: github.com/observer-protocol/x402-op-authorize

The product: observerprotocol.org/crossrail

Governance for your agents: app.agenticterminal.io