When an AI agent buys a file and the buyer says it is not what was promised, somebody has to decide who is right. Digital goods have no parcel, no tracking number and no courier scan. There is a payment, a set of bytes, and two parties who remember the deal differently.
Under our last article, about who should sign the receipt when an agent pays, a reader who works on payment disputes made a point we keep coming back to. A receipt signed by the seller is still the seller's word. An independent attestation that delivery happened would make these disputes much easier to settle fairly.
We agree. We also do not have such an attestation. This post covers what evidence we record today, where it runs out, and a small failure of our own this week that showed how fast a case becomes impossible to reconstruct.
Not all evidence costs the same to fake
A useful way to sort dispute evidence is by what it would cost to forge. Provek, a verification project we run, uses four classes:
- self-reported: a party says so, at no cost;
- platform-observed: a platform saw it, but one line of configuration could fake it;
- third-party attested: faking it needs a third party to collude;
- cryptographically bound: faking it needs a stolen key.
Apply that to an agent purchase. The on-chain payment is cryptographically bound. Anyone can look up the transaction on Base without trusting us or the seller. The seller's "delivered" is self-reported. Our gateway's record of the order is platform-observed, and we are not neutral, because we sit in the middle of the flow.
So the money half of a dispute is easy. The goods half rests mostly on the cheapest evidence there is.
What we record today
On our merchant product, every agent order has a state, the payment transaction hash, a list of events and the shop's refund policy.
If something goes wrong, the paying wallet can open a dispute with one of six reason codes: not_received, not_as_described, duplicate, canceled_recurring, agent_error or other. A note of up to 1,000 characters goes with it. The shop then has 7 days. A verified refund from the shop's wallet closes the dispute. If the shop stays silent, the dispute expires and the order goes back to its earlier state. The silence still counts: the shop's dispute rate is public, and at 10 or more closed orders a rate of 2% stops new quotes until we review it.
Our refund framework is blunt: we are not an arbitrator. We record orders, refunds and dispute statements and pass them between the parties. Escalation means reputation and suspension, not a verdict.
For our own paid API calls the record goes further. Each receipt holds the payment transaction, a SHA-256 of the response we returned, and the provider's status code. Our refund policy file names two dispute contracts on the GenLayer testnet. A refund verdict from either one is paid after our worker recomputes the same rule from the same documents. The same file lists one case as not covered: response_mismatch, because validators cannot recompute it. That is the delivery question in a single line.
A case from this week
Soukbase is a catalogue where people list digital goods for agents to buy. It is still in pilot. We listed a research report there ourselves. A person reviewed it and approved it. Then the shop on our gateway refused the item, after approval. A rule had read the example amounts "$1, $5 and $20" in the description as a false statement about the price.
For about two hours the seller page said "Being added to your shop" and gave no reason. It changed only when we taught the system to read the shop's answer and show it.
No money moved, so nobody had anything to dispute. Now picture the same gap after a sale. The review step knew one thing, the shop knew another, and the page showed neither. Without a timed record of what was approved and what the shop answered, nobody could say what happened. That includes us.
Where this stops working
A hash proves which bytes arrived. It says nothing about whether the bytes are any good. A report can match its hash and still be thin, outdated or off topic. For digital goods, that is what "not as described" usually means.
An independent attester helps with two questions: did it arrive, and is it the item that was listed. It helps much less with "is it worth the price". That part still needs a person reading the listing next to the file. Our current answer is reputation over time. It is slow, and it protects the next buyer more than this one.
We have not built an independent delivery attester. We want the people who would rely on one to ask for it first.
A checklist for digital-goods disputes
- Put the on-chain transaction in every order, so the money question needs no trust.
- Hash what you delivered and keep the hash with the order.
- Record every step with a time: listed, approved, accepted by the shop, sent.
- When a step fails, show the reason on the page the seller or buyer reads.
- Give disputes reason codes and a deadline, so silence has a cost.
- Write down who decides, even if the answer is "nobody, only reputation".
Our refund framework, with the dispute rules: https://apibase.pro/legal/refund-framework
If you have handled disputes over digital goods, what evidence decided them in practice: the file, the logs, the listing text, or something else?
