Thanks @TMerlini — the gateway endpoint makes the oracle pattern very concrete, and the live claim tx is exactly the kind of working evidence that makes a spec credible.
Tagging @Damonzwicker @VincentWu @TMerlini and the broader thread — the interface is feeling clean at this point, and I’d love to get a few open questions settled before v0.1 goes out. Would genuinely value everyone’s perspective:
1. Input/Output Encoding — bytes32 hash or raw bytes?
Current design uses bytes32 inputHash and bytes32 outputHash. This keeps the interface minimal and gas-efficient, but pushes the hashing convention off-spec — each backend has to agree on what gets hashed and how. Raw bytes would let backends inspect content directly and avoid a separate hashing step, at the cost of higher calldata and new encoding questions. No strong view here yet — curious what feels right to people who are actually building the backends.
2. Input Segmentation — single input or split into systemPrompt / userPrompt?
My rough take: this only really matters for chat-style models where system and user context are structurally distinct. For non-chat inference (image, audio, structured data), the split doesn’t map cleanly. Splitting at the interface level would add expressiveness for one class of models at the cost of generality for the rest. Leaning toward keeping it as a single field, but would love to hear if anyone has a use case that cuts the other way.
3. Extension Fields — optional bytes calldata extra, or leave extensibility to proof?
Should the interface define an optional metadata field (model version, timestamp, session ID, etc.) that backends can use without touching the base interface? The alternative is to encode any extra context inside the proof bytes, keeping the interface flat. Tradeoff is between ergonomics for consumers vs. keeping the surface area minimal.
4. Naming Governance — self-assigned {system}/{variant}/{version} or a lightweight off-chain registry?
proofProfile() currently relies on self-assigned strings. Sufficient for now, but as more backends register, collisions become a real risk. Is a minimal off-chain name registry worth coordinating, or is that premature overhead at this stage?
On reference implementations: @TMerlini’s BountySettlement + gateway endpoint is a natural first example for the oracle/attestation pattern. For the spec to be complete, it would also benefit from examples showing how the interface composes with ERC-8183 (evaluator-side verification) and ERC-8004 (agent identity + validation registry) — both have natural integration points, and concrete examples there would make the standard a lot more actionable for implementors. Planning to include these in the PR (Add ERC: AI Inference Proof Verification by JimmyShi22 · Pull Request #1771 · ethereum/ERCs · GitHub) before v0.1.
this has been a great thread to be part of and this is a great foundation for the standard.