15. RandProof Identity: Sybil-Resistant Attestation

Where RandProof Oracle attests facts about the external world, RandProof Identity attests claims about an on-chain entity: a wallet, an agent, or a re

[Layer 1: Core, Design Stage]

Where RandProof Oracle attests facts about the external world, RandProof Identity attests claims about an on-chain entity: a wallet, an agent, or a real-world individual interacting through one. The growth of ERC-8004 agent registries and agent-to-agent commerce (Sections 10 through 13) introduces a problem none of RandProof’s existing products address directly: an agent’s claimed identity, history, or uniqueness is currently either self-reported or dependent on a single centralized verifier. RandProof Identity applies the same N-of-M keeper consensus model to identity-adjacent claims, producing attestations that are cheaper and more decentralized than biometric-authority systems, while being explicit about the weaker guarantee this implies.

15.1 What RandProof Identity Attests, and What It Does Not

RandProof Identity does not attempt to prove biological uniqueness the way biometric proof-of-personhood systems do. It attests weaker, composable signals that, in combination, raise the cost of Sybil attacks without requiring a hardware-based biometric authority: wallet age and activity history across chains, absence from known sanctions or scam-address lists, consistency of on-chain behavior with a claimed entity type (human-operated versus agent-operated), and, where a client explicitly opts in, attestation of credentials issued by a third party the client already trusts (a KYC provider’s signed claim, for instance), without RandProof itself performing KYC.

15.2 Execution Flow


Phase	Description
1. Claim Registration	An entity (wallet or agent) requests an IdentityAttestation for a specific claim_type (e.g., wallet_age, sanctions_clear, behavior_consistency) and pays the associated fee.
2. Independent Verification	N keepers independently check the claim against public on-chain data and, where applicable, public sanctions/scam-list APIs, following the same independent-fetch pattern as RandProof Oracle (Section 14.2).
3. Commit-Reveal Consensus	Keepers commit and reveal their independent findings; consensus produces a signed IdentityCertificate referencing the claim_type and the consensus result, true or false, with a confidence score where the claim type supports gradation (e.g., wallet age is a continuous value, sanctions-clear is binary).
4. Registry Publication	The certificate is published to the same ERC-8004 Validation Registry pattern already established for PoIF (Section 10.6 in the original v0.51 addendum), allowing agent clients to filter counterparties by identity attestation score the same way they already filter by inference fidelity score.

15.3 Composability With ERC-8004

RandProof Identity is designed to slot into the same Validation Registry integration already specified for PoIF, so an agent evaluating a counterparty can check both “does this provider’s inference fidelity track record meet my threshold” and “does this counterparty’s identity attestation meet my threshold” through the same registry lookup, rather than requiring two unrelated systems.

15.4 Threat Model


Threat	Mitigation
Sybil entity passes individual weak signals despite being part of a coordinated farm	RandProof Identity is explicitly disclosed as a composable, probabilistic signal, not a guarantee of uniqueness; clients requiring strong Sybil resistance are expected to combine multiple claim_types or require a higher consensus confidence threshold, not rely on a single claim_type alone.
Keeper colludes to falsely attest a claim	Same VRF-seeded keeper rotation and slashing model used throughout RandProof applies; a keeper’s false attestation diverging from independently-verified honest consensus is detectable and punishable identically to a false entropy or data-feed report.
Source data for a claim_type (e.g., a sanctions list) is itself incomplete or stale	Disclosed explicitly per claim_type; RandProof Identity attests that the declared source was checked and returned a given result, not that the source itself is complete or current, the same provenance-versus-fidelity distinction already established for PoRC (Section 13.4).

15.5 Use Cases

[Layer 3] ERC-8004 agent registries requiring Sybil-resistance signals before granting an agent elevated trust or transaction limits.
[Layer 3] DAOs requiring proof of unique participation for quadratic voting or airdrop distribution, where a single biometric authority is undesirable but unmitigated Sybil risk is unacceptable.
[Layer 3] DeFi protocols offering uncollateralized or under-collateralized credit lines requiring wallet-history-based risk signals.
[Layer 2] AGENT5050 entry validation, screening for wallet patterns consistent with raffle-entry farming, a natural genesis use case for the wallet_age and behavior_consistency claim types specifically.

15.6 Honest Status

RandProof Identity exists as an architectural design in this addendum, reusing the commit-reveal-consensus and keeper rotation mechanisms already implemented for entropy attestation. No IdentityAttestation contract, claim_type registry, or ERC-8004 integration code has been implemented or audited. The composability claim with PoIF’s existing Validation Registry pattern (Section 15.3) is a design intent, not yet built integration.