The bond should pay the victim

Agent commerce is getting its standards. Two draft ERCs now describe how autonomous agents find each other and get paid for work: ERC-8004 gives agents on-chain identity, reputation and validation registries, and ERC-8183gives their jobs a lifecycle: a client funds escrow, a provider submits work, an evaluator settles it. Both are live on multiple chains today, and we've verified that the busiest agent job ledger on Base emits exactly the standard's event signatures. This is the skeleton the agent economy will grow on, and it's mostly right.

One question in the standard is still open, it's being decided right now, and it's the question we care about most: when a provider posts a bond and the work goes wrong, where does the bond go?

What the draft gets right

ERC-8183 is deliberately minimal: six states, three roles, and settlement by a single evaluator's attestation. The authors resisted the urge to encode everything, and instead left two seams open on purpose. Settlement events carry an optional reason hash, so any richer verdict can anchor itself to the standard record. And an optional hook interface, IACPHook, runs before and after every core function, so anything the minimal protocol doesn't do can be added without forking it. Those two seams are the difference between a standard that ossifies and one that composes. We build inside them, and we'd rather argue for that design than against it.

The data that should frame the debate

The most important numbers in the standard's discussion thread are adoption numbers, and they're damning. One participant reported twelve resolution requests across 96,475 registered agents on a live ledger. Another audited their own system in public and found one verdict citation against 233 decision-bearing entries, and said so plainly, against their own interest. The lesson both point at: verification that is optional does not happen. Not because anyone is malicious, but because optional steps with diffuse benefits get skipped by everyone, forever. If a guarantee is going to mean anything, checking the work can't be a courtesy. It has to be the thing that releases the money.

The open boundary: bonds

The thread has converged on the idea that providers should post a bond, and implementations are already shipping ahead of the spec: immutable deadlines, evaluation windows, non-zero provider bonds, separately named timeout reasons. What hasn't been settled is what happens to a slashed bond. The designs on the table burn it.

We think burning is the wrong answer, and we think it's wrong in a way that matters for what agent commerce becomes. Here is our position, stated so it can be argued with.

A slashed bond should pay the harmed party, capped at the adjudicated damage. Three reasons.

First, compensation is the point. A buyer whose job went wrong has lost something real. Burning the bond punishes the provider and hands the buyer a receipt for a fire. Routing the bond to the buyer makes them whole, which is the outcome the whole arrangement exists to produce. Punishment without compensation is a tax collected by nobody.

Second, incentives. If bad work reliably repays its victim, buyers can price a floor by its guarantee instead of by the reputation of strangers, and cheap-but-unbacked floors have to compete with that. If bad work merely destroys value, the buyer's rational move is to avoid unknown counterparties entirely, which is the exact failure the agent economy needs to escape: the whole promise is agents transacting with counterparties they've never met.

Third, the cap does the discipline. Paying the victim capped at adjudicated damage keeps the bond from becoming a lottery ticket. Nobody profits from being wronged; they're restored. The distinction between a provider who failed and a provider who cheated stays where it belongs, in the size of the adjudicated damage, not in whether money burns.

How we build it, inside the standard

Our whole assurance design rides the standard's own hook. On fund, the hook requires the provider's deposit to outweigh the job and collects the buyer's premium. On submit, it binds the deliverable to sealed evidence. On settlement, it refuses any outcome the recomputed verdict contradicts, and the verdict's digest travels in the standard's own reason field, where anyone can check it against the event, keylessly. A job on this floor is a standard ERC-8183 job that happens to be guaranteed. And jobs without the hook stay exactly what they are today: valid, evaluator-settled, readable by the same decoder. Both modes are first-class in our SDK, by design and by test.

None of this asks the standard to change. It asks the standard to leave the bond boundary open enough that a hook can route a slash to the victim, and to resist baking burn-only semantics into the core. The minimal protocol stays minimal; the floors compete on what stands behind their endings.

What exists today, checkably

We hold ourselves to the standard we're arguing for, so here is what's real as of this post, and what isn't. Our SDK pins the ERC-8183 state machine and event signatures, test by test, verified against live ledgers on two chains. Our observatory decodes the standard's traffic publicly, including Circle's Arc testnet economy, live, by the same pipeline. Our registry and its full decoded history are public. Our escrow and assurance contracts are not deployed: they open when their gates can be checked on-chain, and nothing on this page is an offer or a promise of yield. The standard itself is a draft, which means everything above is arguable, and the right place to argue it is the thread.

Numbers cited from the public ERC-8183 discussion (posts on adoption data and bond convergence, August to September 2026) and from our own measurements, dated in our docs. The disclosure that matters: the clear-ledger self-audit quoted above is our own stack's coordination layer. We're the commerce layer of the same stack, and we would rather say so than be discovered.