x402, ERC-8004, A2A, and Stripe's Issuing-for-Agents are converging into the plumbing of an agent economy. Here's what each one actually does, where they compose, and the one problem all four leave for someone else to solve — the one we ended up solving ourselves.
Every write-up of the emerging "agent economy" stack treats x402, ERC-8004, A2A, and now Stripe's agent-facing card APIs as four pieces of one puzzle: agents need to pay, prove who they are, talk to each other, and reach the fiat world. That's true, and it's also the boring version of the story, because it stops at the moment money moves.
The claim we'll defend here is narrower and, we think, more useful: none of these four rails give a paying agent any leverage after settlement. x402 clears an HTTP 402 challenge and calls a facilitator's /settle endpoint — full amount, before the seller has done anything. ERC-8004 tells you the seller is who they claim to be. Neither tells you what happens when the seller takes the money and the deliverable never shows up. That gap isn't a rounding error in an otherwise-complete stack — it's the reason we built a fifth mechanism ourselves, on top of a primitive Coinbase's own facilitator already exposes and nobody in the ecosystem is using for this purpose yet.
x402 — settlement, not identity. x402 is the HTTP-402-as-payment-rail pattern: a server returns 402 Payment Required with a price, the client attaches a signed EIP-3009 authorization, the server verifies and settles it against a facilitator, then serves the resource. It requires no account, no API key, no OAuth dance. We run this rail live in chainlink-prediction-markets-mcp-enhanced/distribution/x402_api_gateway.py — it's how BlindOracle's 37 SKUs take payment from external agents. The mechanism that makes it work — _cdp_verify_settle() — calls the CDP facilitator's /settle endpoint for the full quoted amount before the job executor runs. That's the honest state of x402 as most people ship it: the seller gets paid on delivery of a promise, not a result.
ERC-8004 — identity, not settlement. ERC-8004 passports answer "is this agent who it says it is, and has anyone revoked it." Our onboarding flow (chainlink-prediction-markets-mcp-enhanced/services/onboarding/agent_onboarding.py) runs five steps — register, verify, issue, activate, attest — and every paid call re-checks the caller's passport against the revocation list before a delegation proof is emitted. This is the layer that keeps a spoofed or unregistered agent from transacting at all; it says nothing about whether a legitimately onboarded agent does the job it was paid for.
A2A — negotiation, not settlement or identity. Google's Agent2Agent protocol formalizes how two agents discover each other's capabilities and hand off a task. It's worth being precise here: our own equivalent surface, scripts/coms.py, is a flat, orchestrator-free, HMAC-signed peer-messaging primitive with replay protection — it is architecturally the same category of thing (two agents talking without a parent coordinating them), but it is not an implementation of Google's spec, and conflating the two is exactly the kind of overstatement that damages credibility with people who actually read the RFC. We use coms.py for critic cross-talk, test-vs-implementation Q&A, peer deliberation, and BO marketplace negotiation — pre-payment conversation, not payment itself.
Stripe Issuing for Agents — the fiat bridge, not a crypto-rail competitor. Stripe's 2026-04-29 launch (Cross River Bank partnership added 2026-07-02) gives an agent a single-use, scoped virtual card: self-canceling after one payment, hard per-authorization spend limit enforced at the network level, real-time authorization webhooks with a 2-second timeout, per-agent attribution via metadata[agent_id]. We evaluated it in specs/eval-stripe-issuing-agents.md and the verdict is GO, conditional on dashboard application approval — for fleet operational spend only. The reason that boundary matters: the same evaluation is explicit that BO's customer/agent-to-agent settlement stays on x402/USDC, full stop. Stripe solves "how does an agent buy a $5 Amazon card or pay a crypto-payable utility bill" — a real merchant who has never heard of Base. It is not trying to solve on-chain agent-to-agent settlement, and treating it as a competitor to x402 misreads what it's for. One useful data point from the same evaluation: the network-enforced single-use card limit is, dimension for dimension, a stronger deterministic spend gate than a purely crypto-native rail's own governance layer — the tradeoff is a real banking relationship instead of a wallet.
x402 plus ERC-8004 is the pairing everyone gets right: check the passport, then settle the payment. Our gateway does exactly this — unregistered or revoked passports are rejected before a /settle call is ever made. That's a real, working composition, and it's also where most commentary stops, as if identity plus payment equals a solved problem.
It doesn't. Identity tells you who is being paid. Settlement tells you that they were paid. Neither tells you whether the thing you paid for actually happened. An ERC-8004-verified, x402-settled counterparty can still simply not deliver, and under the default x402 flow the buyer's only recourse is the same one it's always been: a post-hoc refund the seller has to volunteer.
Once you see the gap, the obvious question is why nobody's closed it, because the primitive to close it already exists. EIP-3009's transferWithAuthorization supports an authorize/capture split the same way a credit-card network does: a signed authorization can be /verify-ed without being /settle-d, and an authorization that's never settled before its validBefore timestamp simply expires — no counterparty action required, no custodian, no new contract.
That's the whole mechanism behind scripts/bo_two_leg_escrow.py: split the price into a base fee and a success fee, collect two EIP-3009 authorizations from the buyer up front (a real constraint — a single authorization is signed for one exact amount, so a genuine split needs two signatures, not one arithmetic trick), settle the base fee immediately, and hold the success-fee authorization unsubmitted until the deliverable is confirmed. Every terminal path — accepted, failed, refused, or expired — resolves the held leg to either released or voided; voiding is the absence of an action, so it needs no cooperation from the seller and cannot itself fail.
We're not claiming this is novel cryptography. It's the opposite: it's the least exotic thing possible — the standard the token itself supports, applied to a problem the ecosystem hasn't gotten around to solving yet. Which is itself the honest finding here: the primitive for dispute leverage in agent commerce already ships in the token standard everyone's already using. The gap is adoption, not invention.
Two honest caveats, because a brief that only argues its own thesis isn't worth publishing. First, our two-leg escrow ships disabled, with zero SKUs opted in as of this writing — it's a working mechanism, not a live product claim. Second, it has a real failure mode we haven't fully closed: the held authorization's TTL (30 minutes by default) has to outlast the job's actual completion time, and for background jobs whose callback can fire minutes later, a job that outlives the window settles nothing for the success fee — the buyer keeps the discount and we did the work anyway. That failure resolves in the buyer's favor, which is the right direction to fail in, but it's still revenue left on the table until TTLs are tuned against measured job latency per SKU.
x402 moves money, ERC-8004 vouches for identity, A2A-shaped messaging lets agents negotiate before either happens, and Stripe's agent card APIs get the whole stack to merchants who don't take crypto — and every one of those four rails still leaves the buyer with no recourse the moment settlement clears. The infrastructure question worth asking isn't "which of these four wins" — they're not competing — it's whether the authorize/capture split already sitting inside EIP-3009 becomes standard practice before or after the first public agent-commerce dispute makes the case for everyone at once.
---
Sources and verification: data/x_liked_2077360260730564958_sources.json (internal claims verified against real files this session; external protocol claims flagged as training-knowledge, not live-fetched). Composition matrix: data/x_liked_2077360260730564958_matrix.json. Scope disclosure below.
CHECKED: our own x402 gateway (chainlink-prediction-markets-mcp-enhanced/distribution/x402_api_gateway.py), ERC-8004 onboarding flow, scripts/bo_two_leg_escrow.py and its rule doc (.claude/rules/infrastructure/two-leg-escrow.md), the Stripe Issuing evaluation (specs/eval-stripe-issuing-agents.md), scripts/coms.py, and the delegation proof ledger.
NOT CHECKED: the current live text of the ERC-8004 EIP itself, the Google A2A spec document, or Stripe's public API docs — none were fetched live this session (WebSearch/ WebFetch not invoked; flagged per the fleet's research-tool-preflight rule rather than presented as verified-current). No claim above depends on a specific clause of any of those three documents; all specific, falsifiable claims are sourced to our own code.
WOULD CHANGE THE CONCLUSION: if another team has already shipped a live, adoption-scale authorize/capture split on x402 (not just EIP-3009-capable, but actually used for deferred settlement), the "gap is adoption, not invention" framing weakens to "gap is awareness, not adoption" — worth a live search before this piece goes out externally.