This is ERC-8471 (Draft; ethereum/ERCs#2123), a proposal for the step that the standards around AI systems, resources and services have been leaving to “the parties’ contract”: what happens when someone objects to a record. Participants may be people, organizations, agents or contracts; what a dispute is about (which model, service, output, dataset, evaluation or promise) and how it is resolved (verifier, evidence, human or AI-assisted judgment) are kept apart, and nothing requires that AI be judged by AI or that a party be an agent.
The claim is the object. A dispute is a specific claim about a specific object: an identified record, delivery, settlement, declaration or action does or does not conform to an obligation that was declared before the event. Admission is an algorithmic check of five criteria against what the bound business contract attests — identifiable object and event, accountable respondent, norm declared before the event, a bound method for every sub-question, open window — plus standing, authorized effects, a clock check (the business window must hold the whole procedure plus an enactment margin) and exclusivity (one active binding case per source, obligation and proposition). “Agent A is unreliable” cannot be filed; “delivery S of task T does not meet the criteria pinned at tender time” can.
Roles kept apart. Every case records the object under dispute, the actor that performed the conduct (an agent, a model service process, a human operator, a tool, a contract), the obligor (the party alleged to bear the obligation), the judgment participants and the executors — one participant may hold several roles, the records keep them apart. Identities, qualifications and organizational relations (trustless-agent identities, know-your-agent assertions, agent identity facets, swarm charters) are optional references, never prerequisites; a plain enterprise account and a model API service under ordinary terms can dispute a double charge, and the version the terms committed, the version the provider declared and the version actually used are three different things, the third being a fact for evidence rather than a filing prerequisite.
Four objects, two registries, no funds. A Dispute Policy (content-addressed, versioned through families) binds each (obligation kind, question type) pair to a method contract and declares the effect vocabulary and the procedure track. A Dispute Binding is the obligation source’s own statement of which policy it accepts for its objects, which effects a ruling may authorize (only what it can enact), who may enact and who else has standing — the only source of a ruling’s authority. A Case holds the eight elements a dispute must state, a dependency table of typed sub-questions, the findings with their support kinds, the round decisions and four dimensions read separately (procedure state, substantive result, reason, enactment status per effect). A Ruling is Sustained, NotSustained or NoDecision, with provenance, the one substantive effect it authorizes or the pre-committed disposition it points to, and how the procedure closed. The registries never move funds or execute; executors named by the binding read, check their own authority, enact and report.
Three question types, three method interfaces. FORMAL questions go to a deterministic verifier over inputs pinned at filing (support kind computed). EVIDENCED questions go to an evidence rule (support as the rule declares). JUDGED questions go to a judgment method; the reference profile files one binary question per sub-question as a CONSUMER_FILED issue with an ERC-8436 registry and imports only the Final result, with its issue, policy, source round, round count and adoption flag. Support kinds are a set, not a hierarchy: a finding records what its method supports, a derived conclusion inherits a list of sources, never their proof.
Not deciding has a meaning. NoDecision is distinct from NotSustained; the policy says per claim kind whether an undetermined decisive finding falls on the claimant or ends in no decision; NoDecision routes to the disposition the business committed in advance, never to a consumer’s improvisation. Every window has a consequence and a hard deadline closes every case; under the optional optimistic track, silence adopts a pre-accepted result and proves nothing.
Economics declared, not designed. The kernel fixes what an economic declaration must state (instruments, purposes, flows under every state and result, assumptions, failure handling) and records what executors report; it endorses no loser-pays, bond or reward scheme, and being in the minority of a panel is not a violation.
What is in the reference repository. Two registries (the dispute registry exposes the whole interface at one address and runs six modules by delegatecall on its own storage, so that every deployable unit stays within the per-transaction gas cap of Sepolia’s current schedule), the ERC-8436 bridge, two formal verifiers (duplicate settlement, declared version), an attestor-quorum evidence rule and a model-API-service escrow between plain accounts that is both obligation source and executor; JSON schemas for the policy, binding, case, finding, ruling and enactment documents; vectors cross-checked between ethers and solc; a 70-test Foundry suite that runs the two complete flows (a double charge verified on chain; a delivery-quality dispute judged by an ERC-8436 roster, including a NoDecision and a finality-by-adoption import) and the exception paths (no authority → Advisory, timeouts adopting an earlier decision, Advisory with no disposal, duplicate enactment refused, exclusivity, clock incompatibility); an evidence script rehearsed end to end on Anvil, to be run on Sepolia against the live ERC-8436 registry.
What is deliberately out of the first draft (reserved, named in the text): panel replacement on review, non-binary outcomes, verifiable selection and independence screening, economic modules, private evidence, cross-chain carriage, mirrors into validation or reputation registries.
Questions I would most value feedback on:
- The five admission criteria as the boundary of what can be filed as Binding — is anything missing that a consumer would need checked before a ruling can bind it?
- Support kinds as an unordered set with per-finding provenance — does anyone see a case where a consumer genuinely needs a kernel-level ordering?
- The exclusivity key
(source, obligationRef, proposition)within one registry — is per-registry exclusivity the right honest scope, or should the text push consumers harder towards one registry per obligation? - The J-profile’s one-binary-question rule — whether a typed multi-option profile should be specified now or left reserved.
Repository: GitHub - garyyang-finchip/ai-dispute-resolution: AI Dispute Resolution Framework (ADRF) · GitHub · PR: Add ERC: AI Dispute Resolution Framework (ADRF) by garyyang-finchip · Pull Request #2123 · ethereum/ERCs · GitHub