ERC-8183: Agentic Commerce

ERCs
, ,
384

After submit, the provider carries all the evaluator risk

I’ve been building against 8183 and read through the reference implementation. One thing doesn’t match what the Security Considerations say, and I wanted to check whether it’s intentional.

The notes say that once a job is Funded, the client can’t unilaterally withdraw, “which protects the provider after they start work.”

But claimRefund accepts Submitted as well as Funded. After the status check, the only other condition is that the deadline has passed — then it sends the whole budget back to the client. The spec also recommends letting anyone call it.

The client sets both expiredAt and the evaluator when the job is created, and there’s no way to change the deadline afterwards. So this works:

  1. Client creates a job with a short expiredAt and names an evaluator it controls. The spec allows evaluator = client.
  2. Provider does the work and calls submit.
  3. The evaluator does nothing.
  4. expiredAt passes, anyone calls claimRefund, and the client gets the full budget back.

The provider has delivered and has no recourse. The spec is clear that there’s no dispute resolution and that expiry is final.

The provider can of course read expiredAt and check who the evaluator is before starting. But it can’t extend the deadline later, and it has no way to know up front whether the evaluator will actually answer.

A provider could hold the real payload back until it’s paid, but that defeats the point of the flow — and deliverable is suggested as something like an IPFS CID, which is readable the moment it’s submitted.

This doesn’t need anyone to act in bad faith. An evaluator can be a contract or an agent. If one is simply down across the deadline, finished work turns into a full refund.

I can see why claimRefund looks the way it does. The notes say it’s deliberately not hookable so a malicious hook can’t block refunds, and that seems right — so I don’t think a hook is where this should be fixed.

Two options that wouldn’t break that:

  • Don’t allow claimRefund while the status is Submitted, and give the evaluator its own deadline to respond. If it misses that, make the fallback an explicit choice rather than always the client.
  • Or keep it callable, but add a grace period after submit, so submitting always buys some evaluation time that the client can’t set to zero.

Either way, the question worth answering out loud is: when the evaluator never responds, who takes the hit? Right now it’s always the provider.

Is that deliberate — the provider takes on evaluator risk, and reputation systems are meant to cover it? If so, it’d be worth saying that plainly in the Security Considerations, because the current wording reads the other way.

1 Like