ERC-8353: Staked Weighted Verification Gate

Abstract

This ERC defines a minimal interface for a verification gate: a registry in which a claim about a subject carries no trusted status until it is verified by third parties. Verification is weighted — the force of an endorsement is a function of the endorser's own verified standing, not a count of endorsements — and a claim's subject can never verify itself. Claims may be bonded by an optional stake, follow a fixed four-state lifecycle (Offered → Verified → Settled, with Revoked reachable from any live state), and revocation always leaves an auditable trace. The standard specifies four state-transition functions, two views, and four events; weight functions, promotion thresholds, slashing, and revocation arbitration are left to implementations.

Motivation

As autonomous agents produce an increasing share of digital work, generating claims — "this code works", "this person shipped this", "I can perform this task" — becomes cheap, while verifying them remains scarce and expensive. Systems that gate value on self-description or on endorsement counts are trivially farmed by Sybil identities and by reciprocal endorsement rings.

Two design responses recur independently across production systems that face this problem:

1. Verify before settle. A claim is consumed (settled on, rendered, routed on) only after third-party verification, never on the claimant's word. Claimants can be required to stake, so wrong claims cost their maker.
2. Weight, not count. An endorsement's force derives from the endorser's own verified depth. An unverified endorser contributes approximately nothing, which makes Sybil swarms structurally worthless instead of merely rate-limited.

The information-theoretic case for measuring rather than counting trust — an actor's deliverable value is bounded by measured mutual information, not by declared confidence — is developed in A Mathematical Theory of Value (arXiv:2606.12502). This ERC standardizes only the interface and lifecycle of the gate, so that marketplaces, credential registries, and reputation systems can interoperate on trusted status while competing on verification policy.

The interface is deliberately minimal, following the precedent of single- concern introspection standards such as ERC-8063: anything two conforming implementations would legitimately do differently is excluded from the specification.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

State machine

Every claim is in exactly one of four states:

              offer()               verify()              settle()
  (none) ─────────────▶ Offered ─────────────▶ Verified ─────────────▶ Settled
                           │                      │                    (terminal)
                           │ revoke()             │ revoke()
                           ▼                      ▼
                                  Revoked  (terminal)

• Offered — the claim is registered and any required stake is bound. It MUST NOT be treated as trusted.
• Verified — accumulated third-party verification weight has met the implementation's promotion condition.
• Settled — the claim has been finalized and relied upon. Terminal: a settled claim MUST NOT be revoked.
• Revoked — terminal. The claim, its transition history, and its final state MUST remain queryable indefinitely.

No other transitions are permitted. In particular, a claim MUST NOT reach Verified or Settled without passing through Offered, and settle MUST revert unless the claim is Verified.

Interface

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.20;

/// @title Staked Weighted Verification Gate
interface IVerificationGate {
    enum Status { None, Offered, Verified, Settled, Revoked }

    /// @notice A claim was registered and entered the Offered state.
    /// @param claimId   Unique identifier of the claim
    /// @param subject   The party the claim is about
    /// @param offerer   The caller that registered the claim
    /// @param claimHash Hash of the claim content (content itself may be off-chain)
    /// @param stake     Stake bound to the claim (0 if none)
    event ClaimOffered(bytes32 indexed claimId, address indexed subject,
                       address indexed offerer, bytes32 claimHash, uint256 stake);

    /// @notice A third party verified the claim, contributing `weight`.
    event ClaimVerified(bytes32 indexed claimId, address indexed verifier,
                        uint256 weight, bytes32 evidenceHash);

    /// @notice A Verified claim was finalized.
    event ClaimSettled(bytes32 indexed claimId);

    /// @notice The claim was revoked. The record persists.
    event ClaimRevoked(bytes32 indexed claimId, address indexed revoker,
                       bytes32 reasonHash);

    /// @notice Register a claim about `subject`. Binds msg.value as stake, if any.
    /// @dev MUST emit ClaimOffered. MUST revert if a required stake is missing.
    /// @param subject   The party the claim is about
    /// @param claimHash Hash of the claim content
    /// @param data      Implementation-defined parameters (opaque to this standard)
    function offer(address subject, bytes32 claimHash, bytes calldata data)
        external payable returns (bytes32 claimId);

    /// @notice Endorse a claim as a third party.
    /// @dev MUST emit ClaimVerified with the weight actually credited.
    ///      A call where msg.sender is the claim's subject or offerer MUST NOT
    ///      contribute weight (implementations MAY revert instead).
    ///      A verifier MUST NOT contribute weight to the same claim more than
    ///      once (implementations SHOULD revert on repeat calls).
    ///      MUST revert unless the claim is Offered or Verified.
    function verify(bytes32 claimId, bytes32 evidenceHash) external;

    /// @notice Finalize a Verified claim.
    /// @dev MUST revert unless the claim is Verified. MUST emit ClaimSettled.
    function settle(bytes32 claimId) external;

    /// @notice Revoke a claim. Authorization policy is implementation-defined.
    /// @dev MUST revert unless the claim is Offered or Verified — Settled is
    ///      terminal and MUST NOT be revoked.
    ///      MUST emit ClaimRevoked. The claim record MUST remain queryable.
    function revoke(bytes32 claimId, bytes32 reasonHash) external;

    /// @notice The gate. Consumers MUST check this before relying on a claim.
    /// @return status The claim's current state
    /// @return weight Total verification weight accumulated by the claim
    function statusOf(bytes32 claimId)
        external view returns (Status status, uint256 weight);

    /// @notice The verifier's own verified depth, as computed by this implementation.
    /// @dev MUST be derived from `verifier`'s own verified state; MUST NOT be
    ///      a function of raw endorsement counts alone.
    function weightOf(address verifier) external view returns (uint256);
}

Conformance requirements

1. No self-verification. A verify call from the claim's subject or offerer MUST NOT increase the claim's weight or advance its state. This is the standard's one absolute red line: trusted status is unobtainable through self-endorsement, directly or via a single controlling caller.
2. Weighted promotion. The condition that moves a claim from Offered to Verified MUST be expressed over the weights of its verifiers (as reported by weightOf), not over the number of verify calls, and each verifier MUST be counted at most once per claim — repeat verify calls from the same address MUST NOT accumulate additional weight (implementations SHOULD revert on them). weightOf MUST derive from the verifier's own verified state (within this contract or an implementation-declared external source); it MUST NOT be a constant across all verifiers and MUST NOT be settable by the verifier itself.
3. Verify before settle. settle MUST revert for any claim that is not Verified. Implementations MUST NOT expose any other path to Settled.
4. Stake binding. If an implementation requires a stake, it MUST be bound no later than the ClaimOffered event and MUST only be released or reduced by settle or revoke. This standard does not define stake sizing, slashing schedules, or the destination of slashed funds, except that slashed stake MUST NOT be credited to the party that triggered the revocation (no bounty for engineering failures).
5. Auditable revocation. After revoke, statusOf MUST return Revoked for that claim indefinitely, and the emitted event history MUST allow reconstruction of every transition including the revocation reason hash.
6. Implementations SHOULD implement ERC-165; type(IVerificationGate).interfaceId identifies this interface.

Left to implementations

The weight function f behind weightOf; the promotion threshold; whether a stake is required and how it is sized and slashed; who may call revoke and under what challenge process; the format of data, evidenceHash, and reasonHash; and the semantics of the claim itself. Payment for verified work and the identity of the acting parties are explicitly out of scope.

Rationale

Why a lifecycle standard rather than a data standard. Existing attestation standards define what a signed statement is; the recurring interoperability gap is what a statement is worth and when it may be relied on. Consumers need one question answered uniformly — "has this claim passed a third-party gate, at what weight, and is it still standing?" — which is statusOf. The four transitions exist only to give that answer a well-defined history.

Why weight instead of count. Counting endorsements prices an endorsement at the cost of an address, which on a public chain is approximately zero. Weighting by the endorser's own verified depth makes the cost of moving a claim's status equal to the cost of building verified standing — which is exactly the resource the system measures. Both known production designs of this primitive adopted this independently after rejecting count-based scoring; the standard treats it as essential, not as policy.

Why the weight function is not specified. Verified depth is legitimately different things in different systems: measured task performance in a marketplace, identity-verification tier in a credential registry, stake-backed history elsewhere. Fixing one function would collapse the standard into one product's policy. The interface fixes only the invariants every honest weight function shares: it derives from verified state, and it is not self-assigned.

Why stake is optional. One production lineage makes stake load-bearing (claims are priced confidence, wrong claims burn); another achieves its anti-abuse goals without any stake. Requiring stake would exclude conforming gate implementations that bond claims by other means; forbidding it would exclude the staked design. The interface therefore standardizes only the binding discipline (bound at offer, resolved at settle/revoke).

Why no payment semantics. Verification gating and payment settlement compose naturally but vary independently. Every payment-bearing design surveyed had exactly one source; writing it into this ERC would present single-source policy as a multiply-evidenced standard. A settlement layer can consume statusOf without this ERC knowing it exists.

Relationship to agent registries (ERC-8004). Registry standards answer who an actor is and where its history is recorded: an identity registry, client feedback, and a validation registry in which an actor requests validation from a designated validator, who posts a response that is stored and averaged. This ERC answers a different question — when a particular claim may be relied upon — and the two compose rather than compete. Concretely, a registry records validation outcomes but does not define a trusted/untrusted status, does not bind stake to the claim, does not weight validators against each other, and does not constrain who may validate; this ERC supplies exactly those, and deliberately says nothing about identity or discovery. An implementation MAY source weightOf from a registry's validation history and MAY use a registry-issued identifier's wallet as a claim's subject. No registry is required: subject is a plain address, so the gate also serves parties that are not registered agents at all. This ERC therefore lists no requires dependency on any registry standard — composition is available, not mandatory.

Why Settled is terminal. Settlement is the reliance event: stakes are resolved and consequences have occurred, so a post-hoc status flip cannot undo them — it can only create a claim whose recorded outcome and live status disagree, and an incentive to engineer late revocations. Systems whose credentials must remain falsifiable after consumption can model this within the standard: keep the claim in Verified (revocable indefinitely) and treat settle as the explicit, deliberate point of no return, or issue finite-lifetime claims and re-offer.

Why one verify method rather than approve/reject voting. Negative signals are already expressible: a verifier withholds weight, and an implementation's revocation process handles contested claims. A binary approve/reject interface would force every implementation to have a dispute protocol, which is precisely the kind of policy this standard leaves open.

Backwards Compatibility

No conflicts with existing standards. The interface is self-contained and does not modify ERC-20, ERC-721, or ERC-1155 behavior. Claims MAY reference subjects that are contracts implementing other standards; attestation-format standards can be carried opaquely in claimHash/evidenceHash. Implementations SHOULD expose ERC-165 introspection.

Reference Implementation

Non-normative. A Solidity reference implementation accompanies this proposal: the interface, a minimal abstract base enforcing every normative requirement, two adapters, and tests covering both shapes.

The abstraction was informed by two independent production systems: a market-side agent task hub (staked bids, verify-before-settle, measured per-class reputation) and an identity-side works/certificate registry (offered→claimed→revoked attestations, endorsement weight equal to the endorser's verification depth). The two adapters in the reference implementation correspond to those shapes and differ only in the policy hooks — the same interface serves a staked marketplace and a zero-stake credential registry. Theoretical background: A Mathematical Theory of Value, arXiv:2606.12502.

Security Considerations

Sybil verifiers. The primary attack is manufacturing many verifier identities. The weight requirement is the structural defense: fresh identities have no verified depth, so their aggregate weight is ≈ 0 regardless of count. Implementations MUST ensure weightOf cannot be bootstrapped by self-verification loops among an attacker's own identities (e.g., by deriving depth only from claims verified by already-weighted parties, or from system-external verified state).

Authenticity re-derivation is not verification weight. Where a verification is accompanied by evidence that anyone can re-derive — a signed, deterministic verdict, for instance — consumers and implementations MUST NOT treat the number of successful independent re-derivations as verification weight. Re-deriving evidence confirms that a verifier issued what it claims to have issued; it says nothing about whether the judgment was correct, and a single-issuer verdict re-checked any number of times still carries exactly one independent judgment. Because re-derivation is cheap, deterministic, and performable by the issuer's own addresses, such a count is even easier to inflate than raw endorsement counts. Recomputable evidence is a precondition for trusting a verification, never a substitute for independent weighted judgment of the claim.

Evidence commitments are only as useful as their preimages. evidenceHash commits a verifier to material; it does not make that material available. A consumer that cannot obtain the preimage cannot re-derive anything from it, so for that consumer the commitment is indistinguishable from an assertion, however sound the verifier's method. Implementations that expect consumers to audit verifications SHOULD ensure the committed material is retrievable — by publishing it, by using a content-addressed location, or by any means that does not require the verifier to be responsive and honest at audit time — and consumers SHOULD treat a commitment whose preimage they cannot fetch as unaudited.

Collusive endorsement rings. Established, genuinely weighted verifiers may trade endorsements. Mitigations are implementation policy but the standard enables them: stake on the claim makes a colluded promotion costly to the claimant when revoked; weightOf implementations SHOULD make a verifier's depth degradable when claims it verified are later revoked, so lending one's weight to bad claims is self-consuming.

Stake runs and griefing. Where stakes are held by the gate contract, implementations must guard standard escrow risks: re-entrancy on release, stakes stranded by claims that never verify (a timeout/expiry policy is RECOMMENDED), and griefing by revocation-triggering third parties — hence the requirement that slashed funds never flow to the revocation trigger.

Revocation races. A consumer may read Verified and act while a revoke lands in the same block. Consumers SHOULD treat statusOf as authoritative at the moment of settlement, not at the moment of quoting; high-value consumers SHOULD re-check status in the transaction that relies on the claim. Conversely, front-running settle with revoke is an arbitration-policy question; implementations with adversarial revokers SHOULD impose a challenge window rather than instant revocation.

Weight oracle manipulation. Implementations reading verifier depth from an external source inherit that source's integrity; the external source MUST itself satisfy the no-self-assignment requirement, or the gate's central guarantee is void.

Copyright

Copyright and related rights waived via CC0.