ERC-8210: Agent Assurance

ERCs
, ,
46

ERC-8210 v2 Progress Update

Draft for ERC-8210: Agent Assurance
Prepared: 2026-07-05

v2 Draft Implementation Progress Update

Since Post 29 (v2 Changelog, 2026-04-20), the reference implementation at wangbin9953/erc8210-aap has moved forward on the code-touching subset of the 17-item plan. The v2-draft branch now carries seven of those items. This post summarizes what has landed, one closed direction decision, a new subsystem introduced in June, and the current state of the four open questions from Post 28.

The spec PR (ethereum/ERCs#1632) is still pending EIP editor merge. Spec-text-only items in the changelog remain blocked on that merge, per the process rule laid out in Section 九 of the v2 Changelog.

A. Code Landings on v2-draft

Seven of the seventeen items now have implementation in the reference repo. All numbering below matches Post 29 Part 2. Commit hashes link to the v2-draft branch tree.

Item Scope Status Commit
5 Custom errors for commitToJob (4 typed errors replacing require strings) landed c74edda
8 resolveClaim stores keccak256(reason), raw reason added to ClaimResolved event landed c74edda
10 (Direction B) New CoverageType.RoleCollusion with post-completion attestation via external independence layer landed 8e473d0
11 IRiskHook extended with computeRecommendedAmountWithEvidence returning (uint256, bytes32 evidenceRef); single-output method retained for v1 compatibility landed, marked “v2 draft pending review” c74edda
15 New IIndependenceSignal interface: two delivery modes (assessIndependence on-chain oracle, verifyAttestation signed payload) sharing output shape (bool independent, uint8 confidence, bytes evidence) landed, pending co-author review c74edda
16 Integer Job Identifiers NatSpec: claimId = keccak256(abi.encode(jobId, claimant)) derivation pattern documented on Claim struct landed c74edda
17 (Direction B) High-frequency composition metadata promoted to first-class fields on Claim (upstream, reasoningCID, slashEvidenceHash), signature of fileClaim extended, ClaimFiled event carries three non-indexed bytes32 fields landed 8e473d0

Items 1, 2, 3, 4, 6, 7, 9, 12, 14 remain spec-text only and are held until v1 lands in Draft.

B. Item 17: Direction B Closed

Item 17 in Post 29 offered two paths for high-frequency composition metadata: keep it event-only (Direction A, indexer-driven), or promote it to first-class fields on the Claim struct (Direction B, chain-native).

Direction B has been implemented on v2-draft. Rationale:

  1. Composition metadata is queried by downstream contracts (upstream jobs need to trace slash evidence back through the call chain), not only by off-chain indexers. First-class fields enable direct on-chain reads without event replay.
  2. All three fields are bytes32 (single storage slot each), so cost impact is bounded and predictable.
  3. Optional zero values preserve backward-friendly semantics: fillers can pass bytes32(0) where the composition slot does not apply.

Event fields were retained as non-indexed, since the three indexed slots on ClaimFiled are already saturated by jobId, claimant, and coverageType. Indexers filter on those and read composition fields off the non-indexed payload.

C. Receipt Profile Registry (New v2 Subsystem)

A subsystem not present in the original 17-item plan was introduced in June:

docs/receipt-profiles.md (seeded 2026-06-17): a governance-light registry index for evidence profiles referenced by evidenceType. Key design points:

  • Binding rule: evidenceType = keccak256(profile_identifier), so a receipt profile is content-addressed by its identifier and cannot be silently swapped.
  • Entry template: 11 sections including cryptographic envelope, canonicalization rules, verifier keying, revocation model, and conformance vectors.
  • Status lifecycle: candidate → active → deprecated → withdrawn. Status transitions are recorded in the registry itself so downstream consumers can pin to a lifecycle stage.
  • Registry maintainer: @wangbin9953. The registry is a companion document to the ERC, not part of the ERC body, so profile churn is decoupled from ERC revisions.

The design intent is that ERC-8210 v2 will reference the registry as a normative external index in a Rationale paragraph, without embedding profile-specific schemas in the ERC text.

D. First Registry Entry: verification.v0.3

The first registry entry landed via PR #4 (merged 2026-06-23), contributed by @jkrausz (AgentOracle / TKCollective):

docs/profiles/verification-v0.3.md: JWS-based act/halt verdict envelope, typ = application/vnd.verification.v0.3+jws, normative spec IETF draft-krausz-verification-state-01.

Two independent issuers are already producing conformant receipts against this profile: AgentOracle and AgentTrust. That satisfies the “two independent implementers” threshold discussed in Post 29 for elevating a pattern into the registry.

Supporting implementation details on the issuer side (three-signer composed envelope, conformance test vectors, verification tooling) are being documented by @jkrausz and will surface in follow-up communications from AgentOracle / TKCollective.

E. Open Questions from Post 28: Status Update

Post 28 listed four open questions. Current state:

  1. RoleCollusion as a separate CoverageType. Closed. Direction B implemented (see Item 10 above).

  2. Behavioral similarity as a fifth core independence category. Still open, pending community input. The IIndependenceSignal NatSpec currently enumerates four categories; a fifth would be added as a non-breaking extension.

  3. IIndependenceSignal parallel to IRiskHook. Interface landed with both delivery modes. The remaining sub-question is how the two interfaces compose at call time (parallel invocation, IIndependenceSignal as an input to IRiskHook, or a wrapping pattern). Pending co-author review with @agent-tech.

  4. Multi-issuer envelope citation strategy in Rationale. Still open. Three candidate directions were surfaced in the v2-decisions doc:

    • A: name specific implementations by URL
    • B: protocol-neutral prose without naming
    • C: leave the citation to the reference implementation repo’s Integration Examples

    The Receipt Profile Registry introduced in Section C above materially reshapes this question: Direction B becomes more natural, since the registry itself is the naming mechanism and the ERC body can defer to it. Pending co-author review.

Feedback Requested

Two spots where community input would help finalize v2 spec text:

  1. Item 4 (Behavioral similarity as a fifth independence category): does the current four-category model in IIndependenceSignal NatSpec cover practical needs, or is behavioral similarity load-bearing enough to elevate?
  2. Item 4 (Multi-issuer envelope citation): does the Receipt Profile Registry make Direction B (protocol-neutral prose in Rationale, registry does the naming) the preferred path, or do reviewers still want direct URL citation in the ERC body?

Thanks to everyone who has engaged since Post 29. The registry subsystem in particular emerged directly from that discussion.