ERC-8274: AI Inference Proof Verification

Jimmy — there’s a catch-22 happening.

HTMLProofer: can’t link to ./eip-8263.md because the file doesn’t exist yet.
EIP Walidator: first mention of ERC-8263 must be a link.

The way out: add ERC-8263 to the requires: frontmatter. When it’s declared as a dependency, the linter stops enforcing the link-first rule for it and HTMLProofer won’t try to resolve it as a file.

Open the top of erc-8274.md and change:
requires: 165

To:
requires: 165, 8263

Then leave the plain text ERC-8263 mentions as-is in the body. That should clear both errors in one push.

1 Like

Jimmy —

Yes — submitting OCP as an ERC is the right path and it’s actively being pursued. Plain text citation is the right call for now. Once it has a number the relative link resolves cleanly alongside ERC-8263 and WYRIWE.

The tooling constraint you named is actually the clearest articulation yet of why the EIP matters structurally — not just for recognition but for the stack to be fully cross-referenced in a way the tooling accepts.

On the ERC-8183 and ERC-8004 composition examples — tagging Tiago, that’s his territory. @TMerlini

— Damon

1 Like

@JimmyShi22 @Damonzwicker , picking up the two open points.

WYRIWE citation

Same path as OCP for now, plain text citation until the PR lands. WYRIWE has a Magicians thread (https://ethereum-magicians.org/t/wyriwe-what-you-read-is-what-you-execute-input-provenance-for-verifiable-ai-inference/28655) and a formal ERC draft in the repo ( wyriwe/ERC-draft.md at main · TMerlini/wyriwe · GitHub ). PR to ethereum/ERCs is the next step once WYRIWE has a number it can go into requires: alongside ERC-8263 and the relative link resolves cleanly.

ERC-8183 composition

The BountySettlement contract is the reference impl for IProofVerifier in ERC-8274. In the ERC-8183 settlement flow, verify() gates complete() / reject() , the ProofEvaluator pattern already in the PR captures this. The inputHash passed to verify() is WYRIWE’s input_hash committed at fund time; the outcome envelope’s commitmentRef field maps to that same hash. The BountySettlement source is at BountySettlement.sol — ERC-8263 / ERC-8274 / OCP proof-of-concept. Verifies L4 EIP-712 InferenceAttestation on-chain, releases bounty if valid. Reference implementation for IProofVerifier.verify() pattern (ERC-8274). Deployed on Base Sepolia: 0x57fe09a6Eb8d5741b24fF640AA8Bc4D2010B93D7 · GitHub if useful as an inline reference.

ERC-8004 composition

The agentId and registry fields in the WyriweAttestation struct are ERC-8004 anchors. In the reference deployment at gateway.ensub.org, the gateway attestor key is resolved via IErc8004IdentityRegistry.getAgentWallet(agentId) , this is the binding that separates infrastructure signing from agent self-signing. The pattern is already in the PR’s ERC-8004 composition example (decoding agentId from metadata as bytes32(uint256(erc8004AgentId))). Once ERC-8004 has a stable PR number it can also move into requires: if that’s the right call.

Happy to expand either example if more detail helps pass CI.

Tiago

2 Likes

@TMerlini Hey Tiago — really appreciate you taking the time to walk through both examples. That’s exactly what was needed — the open questions on the composition side are now settled, and the v0.2 direction is clear.

PR #1771 is at 9/9 CI green at this point, so the spec is essentially in its final v0.1 shape and waiting on an editor review to merge. Do you have any sense of what we can do from our side to help move it along — or is it mostly a matter of waiting for one of the editors to pick it up?

— Jimmy

2 Likes

JimmyShi22 glad that settles the composition questions. On moving the editor review along, a few things that tend to help:

  1. Tag @abcoathup directly in the PR they’re already on it (commented earlier) and are one of the more active ERC editors. A direct ping noting it’s at 9/9 CI green and ready for editor review is reasonable at this point.

  2. Post on the Ethereum Magicians thread linking PR #1771 and noting the CI status editors and community members who follow the thread may not be tracking the PR directly.

  3. Cross-post to the ERC-8183 thread the composition with IVerificationMethod and ProofEvaluator is directly relevant there and the editors watching that thread may have more context for a faster review.

Beyond that it’s mostly a queue issue editors are handling a lot of AI agent ERCs right now. The 9/9 CI green status means there’s nothing blocking on your end, which is the best position to be in.

Will keep an eye on it and happy to add a supporting comment on the PR if a community signal from the reference impl side helps.

1 Like

@TMerlini — thanks for the concrete suggestions, really helpful to have a clear action list at this stage.

And yes, a supporting comment on the PR from the reference implementation side would be genuinely valuable — if you’re happy to add one, that’d be much appreciated. An editor seeing that the interface has been implemented and battle-tested in production is exactly the kind of signal that helps.

Will get moving on the other items too.

2 Likes

Note: I am NOT an editor. There are only a few editors, so you have to wait until one can review.

2 Likes

@TMerlini — based on the encoding you described, I put together a draft WyriweVerifier that lifts the WYRIWE / BountySettlement verification logic into a clean IProofVerifier implementation — to see whether the current v0.1 interface holds up in practice.

The encoding follows your mapping:

metadata → abi.encode(bytes32 manifestHash)
proof    → abi.encode(rawInputHash, sanitizationPipelineHash, agentId, registry, timestamp, l4Signature)

The wrapper validates the three-commitment provenance chain, reconstructs the EIP-712 WyriweAttestation digest over all 8 fields, and accepts via either the GATEWAY_ATTESTOR path or registry.getAgentWallet(agentId) for the trustless path.

Draft is here: WyriweVerifier — IProofVerifier (ERC-8274) wrapper for WYRIWE L4 gateway attestations · GitHub

There are three things I’ve marked @review that I wasn’t sure about — the exact ATTESTATION_TYPEHASH field order, the inputHash derivation formula, and the EIP-712 domain name/version. Would really appreciate your eyes on those when you get a chance.

1 Like

Pulled the WYRIWE spec to give you accurate answers on all three. Several things to correct, none of them architectural, all fixable.

1. inputHash derivation — remove the check

Your implementation:

if (keccak256(abi.encodePacked(rawInputHash, sanitizationPipelineHash)) != inputHash) {
    return false;
}


Per the WYRIWE spec, input_hash = keccak256(sanitized_input), it’s an independent commitment to the actual bytes fed to the model, not mathematically derived from the other two hashes. The three hashes form a provable chain but not an on-chain derivable one. The check can be removed, the EIP-712 signature binding already covers it. If the gateway signed a struct containing all three hashes, they’re cryptographically bound without needing a derivation formula.

2. ATTESTATION_TYPEHASH - four corrections

Current:

WyriweAttestation(bytes32 manifestHash, bytes32 rawInputHash, bytes32 sanitizationPipelineHash,
bytes32 inputHash, bytes32 outputHash, uint256 agentId, address registry, uint64 timestamp)


Should be:

WyriweAttestation(bytes32 agentId, address registry, bytes32 modelHash, bytes32 rawInputHash,
bytes32 sanitizationPipelineHash, bytes32 inputHash, bytes32 outputHash, uint256 timestamp)


Changes:

  • manifestHashmodelHash (field name per spec)

  • agentId type: uint256bytes32

  • timestamp type: uint64uint256

  • Field order: spec order is agentId, registry, modelHash first, matches the struct definition

3. Domain name

"WYRIWE""ERC8004AttestationGateway" per spec.

4. Domain verifying contract

// current
registry  // ← should be address(this)


The verifying contract in the EIP-712 domain separator should be the contract calling ecrecover , that’s WyriweVerifier, not the registry. Using registry makes the domain separator unstable across deployments.

5. One thing you got better than the spec

block.chainid (dynamic) is the right call. The spec had chainId: 1 hardcoded, I’ve updated ERC-draft.md to require block.chainid and flag hardcoded values as NOT permitted. Your implementation was already correct.

WYRIWE spec for reference: https://github.com/TMerlini/wyriwe

The struct definition and domain config are in ERC-draft.md. Let me know if anything in the spec is ambiguous and I’ll clarify.

Tiago / dinamic.eth

2 Likes