@JimmyShi22 agreed, and ERC-8275 Layer 4 runs the exact same pattern. EscrowV1.challenge() takes a bytes4 proofType discriminator and routes to the correct verifier at settlement time, the registry never touches verifier addresses, it only handles staking and slashing. The settlement contract owns the verification logic. Glad ERC-8274 v0.2 is the shared ancestor here; these specs are converging on the same composition principle independently.
@Bakugo32 , appreciate the External References placement. Here’s a paragraph you can drop straight in if it fits:
ERC-8275 Usage-Based Economic Compensation for Heterogeneous Mesh Nodes (discussion): defines a four-layer settlement protocol for CCIP Read mesh nodes. Layer 4 (EscrowV1) accepts a generic challenge(uint256 periodId, bytes4 proofType, bytes calldata proofData) entry point where proofType routes to the correct verifier at settlement time, the same soft-declaration pattern as IAgentVerifiable.getAgentVerifier(). VerificationCompleted events carrying a full pre-image are compatible with ERC-8275’s period-keyed attestation index. No normative dependency in either direction.
2 Likes
@TMerlini, Paragraph added as-is under a new “Cross-Reference: ERC-8275” subsection in Appendix B.x. The proofType discriminator / getAgentVerifier() analogy is a good anchor for readers coming from either spec. The “no normative dependency in either direction” framing fits exactly how we’ve positioned ERC-8275 elsewhere in the thread.
1 Like
@Bakugo32 appreciate the placement, a dedicated subsection is more than we asked for. The proofType ↔ getAgentVerifier() analogy is exactly the bridge readers will need when they hit both specs. No normative dependency in either direction is the right call, keeps both standards clean while making the connection explicit for implementers. Thanks for handling it carefully.
@Bakugo32 @TMerlini — ERC-8274 v0.2 is now up: Add ERC: AI Inference Proof Verification Interfaces by JimmyShi22 · Pull Request #1771 · ethereum/ERCs · GitHub
Per the discussions here, the integration with ERC-8183 is reflected directly in the spec:
verificationDigest (from IAgentVerifier.verify()) maps to job.reason — as discussed in #302–#305IAgentVerifiable on the settlement contract declares the verifier; no external registry needed — as discussed in #308–#309- A
ProofEvaluator reference implementation shows the full wiring in the Composability in Practice section
Thanks for the input that shaped these decisions. Would welcome any further feedback.
1 Like
commitmentHash → verificationDigest → job.reason is the chain I was pushing for in #303 — good to see it land cleanly in v0.2.
The IAgentVerifiable soft-declaration on the settlement contract is the right call. Keeping the verifier reference on the job execution side means an observer can recompute the digest from public inputs without needing registry state, which is what makes the verify() boolean actually trustworthy rather than just a gate.
The WYRIWE subsection I just posted on the 8274 thread closes the upstream end of that chain: commitmentHash from WYRIWE is the same verificationDigest 8274’s outer layer emits, which is the same value that lands in job.reason here. One hash, three layers, no adapter.
1 Like
Following the chain you just closed, commitmentHash → verificationDigest → job.reason: there’s a fourth layer that takes the same digest with no adapter. job.reason settles one job.
What none of the three layers holds is the running total across many jobs, how much of an agent’s mandate it has spent over everything it’s completed.
That’s a metering cursor (ERC-1833). It advances on a witness, and a verificationDigest is exactly the right shape for it, which is already how the 1833 spec composes with 8274. So the same digest 8274 emits and 8183 settles on can also advance the aggregate budget: verification proves the job, the cursor counts it against the bound. @JimmyShi22 and I have been talking through the cursor side of this on the 1833 thread, and it lines up: one hash, now four layers, still no adapter.
1 Like