ERC-8004 Validation Network Interface — extension for multi-validator networks

ERCs
,
1

This is a draft extension to ERC-8004 defining a standard contract interface for validation networks — implementations where the validatorAddress in ERC-8004’s Validation Registry is a network of independent validators rather than a single party.

Draft spec: https://github.com/pokt-network/erc-8004-vni

What we’re trying to fix

ERC-8004’s Validation Registry is deliberately unopinionated about who validates, and that’s correct. But that surface has left two distinct security questions to be answered per-implementation, with no portable answer to either:

1. How is the validator itself trusted?

A single validatorAddress is a single trust anchor. If that party is compromised, bribed, or colludes with the agent being validated, the validation is worthless — and ERC-8004 reduces to a more expensive way to write a reputation entry. Three patterns have emerged in practice, none of them portable:

  • Single-validator addresses — operationally simple, but reintroduce the centralized-trust assumption ERC-8004 was designed to relax.

  • TEE-based attesters — strong cryptographic guarantees, but with hardware-trust dependencies and a limited qualifying-operator set.

  • Bespoke threshold schemes — each team rolls its own selection rules, attestation format, and verification path. Clients integrating with multiple networks write per-network glue code.

No shared interface today lets a client say “give me N validators, drawn from at least D distinct operators, with a deadline of T, and return a verifiable bundle of their signed attestations.” Every team building this property is building it from scratch.

2. How is the work trusted?

Multi-validator selection is necessary but not sufficient. Even granting that a network claims to have called N validators across D operators, the relying party still needs evidence that the network actually selected those validators, ran the work, and collected the attestations it returns. Without that evidence, a multi-validator network collapses to its aggregator’s word — operationally no stronger than a single validator that happens to publish a list of names.

This second question admits a spectrum of answers: signature-only attestations (anyone can verify signatures, but selection is taken on trust); indexer-attested selection (a third-party indexer of the validator network’s state vouches that selection was legitimate); light-client verification of the underlying network’s consensus state on Ethereum (no third party needed); zk or TEE execution proofs of selection-and-verification. Any conforming network sits somewhere on that spectrum, and the interface should make that placement visible to clients rather than implicit.

What the extension does

Three pieces, strictly additive to ERC-8004:

  • IValidationNetwork — a contract interface that wraps the existing Validation Registry. A conforming network implements selection, accepts off-chain attestations from the selected validators, aggregates, and writes back through ERC-8004’s existing validationResponse. Mandatory addressee verification on submit() closes a griefing path where a third party can burn a network’s resources on requests not addressed to it.

  • SelectionPolicy — a canonical policy struct with operator-diversity (minOperators) as a first-class field, alongside selectionSize, minResponses, deadlineSeconds, and verdictMode. Networks enforce minOperators at selection time; a network whose effective operator count cannot satisfy a policy MUST refuse it via supports() rather than silently degrade.

  • EIP-712 attestation envelope — a typed-data structure each validator signs off-chain, with the aggregated bundle written to the Validation Registry’s responseURI as canonical (JCS) JSON. The same verification code works across any conforming network.

The Validation Registry contract is not modified. Single-address validators continue to work unchanged. Any sufficiently decentralized substrate — permissionless RPC networks, restaking-based AVSs, TEE consortia, decentralized oracle networks — can implement the interface.

What v0.1 doesn’t yet specify

Pre-publication review surfaced one significant gap: v0.1 defines the attestation format but leaves the verification model implicit. Networks at different points on the trust spectrum above all look identical at the contract surface. The likely v0.2 addition is a verificationModel() view (and possibly an operatorModel() view) so that a relying party can introspect what they’re trusting before they submit. We’d appreciate input on the right enumeration and granularity.

Open questions

  1. Verification model surface. Should the interface require networks to declare a verification model, and what’s the right enumeration? (See above.)

  2. Policy schema. Fixed canonical struct with an opaque extensions field, or registry-defined and extensible at this layer? (Current lean: fixed.)

  3. Validation-network registry contract. Yes or no? (Current lean: no — clients pass validatorAddress directly to ERC-8004; discovery happens at the agent/indexer layer.)

  4. EIP-7702 hooks for sponsored validation — in scope for v1, or follow-on?

  5. Cost discovery. Is a single uint256 from quote() expressive enough, or does pricing need structure?

  6. Spectrum verdicts (verdictMode = mean) — follow-on extension or v1?

Full list in §Open Questions of the draft.

Who we’d like to hear from

The agent ecosystem is settling on ERC-8004 as the trust-layer primitive, and the multi-validator question is being answered in production right now. We’d rather have one portable interface than several incompatible ones.

Particularly interested in feedback from teams running TEE consortia, restaking AVSs, decentralized oracle networks, and permissionless RPC networks — the interface is designed to admit you on equal footing, and we’d like to confirm that holds in practice. Co-authors welcome.

2

Well-scoped proposal and the strictly-additive constraint is exactly right IValidationNetwork implements the validatorAddress role as a network without touching the registry. A few reactions on the open questions:

On verification model enumeration

ERC-8274’s IProofVerifier interface is the natural introspection point here. proofProfile() returns a bytes32 identifier for the verification model, any IValidationNetwork implementation can expose the same pattern for its aggregation scheme. Rather than enumerating models inside VNI, supportsPolicy() already acts as the capability check; proofProfile() from ERC-8274 gives you the verification model identifier without a new registry. The two interfaces compose cleanly.

On whether a validation-network registry is needed

ERC-8004’s Validation Registry already anchors the validatorAddress on-chain. If validatorAddress is the IValidationNetwork contract, the registry already knows a network is handling that agent’s validation, no second registry needed. Discovery of which network type is handling it can be resolved via ERC-165 supportsInterface on the validatorAddress. A separate validation-network registry would duplicate ERC-8004’s role.

On policy schema design

The challengeKind field is load-bearing here, it’s effectively the schema discriminator. The suggested registry (identity-control-v1, rpc-equivalence-v1, tee-attestation-pass-through-v1) is the right pattern. One addition worth formalising: wyriwe-input-provenance-v1 — a challenge kind for WYRIWE triple-hash input provenance verification. Any VNI network implementing this would validate the rawInputHash → sanitizationPipelineHash → inputHash chain and return the committed inputHash as evidence. That connects VNI directly into the L2/L3 trust stack without requiring modifications to the base interface.

On EIP-7702 scope

Keep it out of v1. Sponsored validation is a separate trust boundary, the sponsor’s account abstraction should not affect the validator selection or verdict logic. Worth a follow-on extension once the base interface stabilises.

On cost discovery

quote() returning (uint256 wei, uint256 seconds) is sufficient for v1. The OUT_OF_BAND_PRICE sentinel handles the edge case cleanly. Avoid adding complexity here until there’s a demonstrated need.

One type conflict to resolve

VNI’s attestation struct has agentId (uint256). The commitment floor across the stack is already consistent on bytes32: ERC-8004 uses it as the identity primitive, ERC-8263 commits agentId as a fixed bytes32 slot with a 1-byte scheme discriminator (scheme 0x01 = 32-byte ERC-8004 record id), and WYRIWE carries the same type. VNI’s uint256 is the outlier — worth aligning before it propagates into downstream implementations across the ecosystem.

Strong foundation, the assurance tier table and verdictMode design are particularly well-thought-out.

On the co-author invitation, I’m interested. I’ve been building the reference implementation for ERC-8004 (FactoryFacade, getAgentWallet(), ENS bindings), WYRIWE connects directly into the challengeKind registry, and the type alignment question is something I’d like to work through with the authors directly. Happy to engage further, feel free to DM.