ERC-8183 Agentic Commerce Job Escrow
Analysis
Zero-Storage VerticalsEscrow Freelancing
escrowerc-8183agentic-commerceevaluatorjob-escrowintents
What it is
ERC-8183 is a Draft Standards Track ERC defining a minimal, composable job escrow for agent commerce. Six states: Open, Funded, Submitted, Completed, Rejected, Expired. Client creates job, sets budget, funds escrow; provider submits a deliverable hash; a single evaluator address alone may complete (release funds to provider) or reject (refund client). After expiredAt anyone can trigger refund. Evaluator can be the client itself when no third party is needed. Integrates with ERC-8004 for reputation.
Key design points
- Roles: Client (creates/funds, receives refund), Provider (submits deliverable, gets paid), Evaluator (sole attester).
- Transitions: Open->Funded via setBudget+fund; Funded->Submitted via submit(deliverable bytes32); Submitted->Completed via evaluator complete; Rejected/Expired refund client.
- Hooks: Optional IACPHook with before/after callbacks; address(0) = vanilla escrow. Allowlisted hooks and payment tokens (vetted ERC-20 semantics, no fee-on-transfer/rebase).
- Deliverable: bytes32 reference (IPFS CID, attestation commitment) - fits zero-storage: only hash on-chain.
- Evaluator is the hard part: no appeal, no timeout beyond expiredAt. Pick evaluator architecture carefully (AI judge, ZK verifier, multisig, DAO).
Why it matters for us
- Which stream: Stream 9 (Zero-storage) s9-todo-002 job-escrow module; Stream 8 Escrow.
- Which decision: Adopt ERC-8183 as the job-escrow primitive for agent-to-agent work; evaluator = our own AI judge initially, with expiredAt safety net and backup multisig.
What to do next
Rec 1: Implement escrow.js exposing createJob, setBudget, fund, submit, complete, reject, claimRefund against an ERC-8183 contract on Base; store only deliverable hashes (zero-storage).
Rec 2: Build evaluator service (AI judge) with IPFS-stored rubric and verdict; design expiredAt and backup path.
Sources
Unblocks
s9-todo-002