Pull up the card network rules and the first thing you notice is that consumer protection is not really a mechanism. It is a calendar.
A cardholder generally has 120 days to dispute a transaction. If the goods never showed up, the clock starts from the expected delivery date instead of the purchase date, and the absolute ceiling stretches to 540 days. On the other side, the merchant gets 30 days under Visa and 45 days under Mastercard to respond to each dispute phase. Visa tightened its excessive-dispute threshold from 2.2% to 1.5% for US, Canadian and EU merchants on 1 April 2026, with a fee attached once you cross it.
Every one of those numbers is a duration. Not a cryptographic guarantee, not an escrow, not a proof. A duration, inside which a human being is expected to notice something went wrong and complain about it.
Human commerce is safe because it is slow.
Agents deleted the slowness, and they did it on purpose
Now go look at how the agent payment rails handle the same question.
The x402 protocol is the closest thing the space has to a standard here. Coinbase contributed it to the Linux Foundation, and the x402 Foundation launched operationally on 14 July 2026 with roughly 40 member organisations. The premier members list reads like the entire payments industry at once: Visa, Mastercard, Stripe, Adyen, American Express, Fiserv, Google, AWS, Cloudflare, Ripple, Shopify, Circle, Coinbase.
Their own FAQ has a section headed "How do refunds work?" The answer, verbatim in structure:
The
exactscheme is a push payment, irreversible once executed.
And then two options. Option one: business-logic refunds, meaning the seller sends a new token transfer back to the buyer. Option two: cooperative refunds from channel escrow under the batch-settlement scheme.
Read those two words again. Business-logic. Cooperative.
That is not a refund mechanism. That is a description of the seller choosing to be nice. It is entirely honest, it is written down in the documentation where anybody can find it, and it is almost certainly the right engineering decision. But it should be read for what it says.
The deletion was correct
I want to be careful here, because the easy version of this post is "look, the agent rails have no consumer protection, how irresponsible," and that version is wrong.
Card reversibility is not free. It exists because a specific machine exists underneath it: a human who notices the charge, an issuer who fields the call, a network that adjudicates, and a merchant who eats the loss or fights it. That machine costs real money, and it runs on the assumption that a person is in the loop with weeks to spare.
An agent making a purchasing decision in a few hundred milliseconds breaks every assumption in that list. There is no human to notice. There is nobody to call. There is no plausible way to run a 45-day merchant response cycle against a payment that was one of ten thousand made that hour. So the protocols did the honest thing and did not pretend. Irreversible, documented as irreversible.
The problem is not the deletion. The problem is what happens next.
The hole is already being refilled from the outside
Search around the x402 ecosystem and you will find third-party projects whose entire pitch is putting the missing piece back: refund extensions that add escrow around x402 payments, and dispute-filing services that let agents raise a dispute with the outcome written on-chain.
These are early, they are not part of the core standard, and I am not going to pretend they are load-bearing infrastructure yet. But their existence is the interesting signal, because look at what every single one of them has to reintroduce in order to work:
- A window. A period after settlement during which the outcome is not yet final.
- A decider. Somebody, or some committee, or some staked quorum, that determines who was right.
- Latency. However fast you make the decider, it is slower than the payment it is judging.
You cannot build a dispute layer without those three. They are the dispute layer. So the trajectory here is a system whose entire value proposition is that it settles in about a second, having a second system bolted onto it whose entire function is to make settlement not-final for a while.
That is not a scandal. It is just a loop, and it is worth naming before another year is spent walking around it.
There is a third answer, and it is older than the problem
If option one is "make failure reversible" and option two is "make failure adjudicable," option three is: make failure empty.
An atomic swap has no moment in which one party holds value and the other party holds a claim. Both legs are bound to the same secret. Either the secret is revealed and both sides move, or the timelocks expire and both sides keep what they started with. The failure state is not "one party lost and needs redress." The failure state is nothing happened.
There is nothing to dispute because there was never a moment of asymmetry to dispute about.
That is the whole trick, and it is worth being clear that it is a trick of structure rather than a trick of enforcement. Nobody is promising to make you whole. Nobody has to, because you were never made un-whole.
The part that does not work, which you should hear from me first
Atomicity kills exactly one class of dispute: counterparty default on the settlement itself. Your agent trades asset A for asset B, and the other side takes A and vanishes. That failure mode is gone. Completely, structurally gone.
It does nothing about the other class.
If your agent pays for an API call and the API returns garbage, atomic settlement gives you precisely nothing. The payment leg and the delivery leg were not the same object. The money moved atomically against a promise, and the promise was bad. Same story for a mispriced data feed, a model that returns confident nonsense, a service that is technically up and practically useless.
So the honest scope line is:
- Asset for asset: atomicity is total. Both legs are on-chain, both are bound to one preimage, and the dispute class disappears.
- Asset for service: atomicity is close to irrelevant. The service is not a chain object and cannot be bound to the preimage.
Anyone telling you atomic settlement removes disputes from the agent economy is selling you something. It removes one dispute class with unusual completeness, and that dispute class happens to be the one that scales worst under adjudication, because it is the one where the counterparty is anonymous, offshore, and possibly a script.
Where we actually are
We build this, so the disclosure matters. Settlement runs live end-to-end on Ethereum mainnet today. Our Sui contracts are deployed and CLI-tested, and they are not live. Bitcoin is signet-validated with mainnet pending. Base, Arbitrum, Solana and TON are roadmap, which means they are not built.
The MCP server is public on npm as hashlock-tech/mcp (scoped), currently version 0.6.0, six tools, so an agent can quote and settle without a human in the loop.
None of that changes the argument above. The argument holds whether or not we ship, and if somebody else builds it better I would rather that happened than not.
The question
The industry spent 2026 answering "how does an agent pay." That question is now well answered by people with more resources than us, and the answer is good.
The question nobody has answered is what happens when the payment goes out and the thing does not come back. The card networks answered it with 120 days and a phone call. The agent rails answered it by removing the question. The third-party ecosystem is answering it by rebuilding the phone call in Solidity.
So, two things I would like to hear from you:
When your agent pays for something and gets nothing back, who do you actually expect to fix it, and how long are you willing to wait for them?
And the sharper one: go count your agent's payments and split them into asset-for-asset and asset-for-service. I suspect for most people the second pile is much bigger than the first, and if that is true, atomicity solves a smaller share of your real risk than a post like this one implies. Tell me if your numbers say otherwise.
