Attestation Registry

Sybil-resistant identity attestation registries that verify a unique human behind an address, crucial for fair airdrops and governance.

• Proof of Humanity: A decentralized court system (Kleros) verifies video submissions to create a registry of unique humans.
• BrightID: Uses social graph analysis and verified video chats to establish uniqueness without collecting personal data.
• Both issue attestations (like a isHuman flag) that other dApps can query.

Platforms that aggregate attestations from multiple sources into a portable reputation score or verifiable credential.

• Gitcoin Passport: Collects stamps (attestations) from Web2 (Google, Twitter) and Web3 (ENS, BrightID) sources to compute a score for Sybil resistance.
• Civic Pass: Issues reusable KYC credentials as non-transferable NFTs (SBTs) after identity verification, allowing compliant access across dApps.
• These are composability layers built on top of base attestation registries.

Registries enable self-sovereign identity (SSI) by allowing users to collect portable, verifiable credentials. Key applications include:

• Verifiable Credentials (VCs): Issuing tamper-proof diplomas, licenses, or memberships.
• Soulbound Tokens (SBTs): Non-transferable tokens representing achievements or affiliations.
• Sybil Resistance: Proving unique personhood for fair airdrops or governance without revealing personal data.
• KYC/AML Compliance: Streamlining regulatory checks with reusable, privacy-preserving attestations.

Attestations create a portable, composable reputation layer for wallets and addresses. This is critical for:

• Under-collateralized Lending: Using a history of reliable repayment as creditworthiness proof.
• DAO Contributions: Verifying past work, governance participation, or bounties completed.
• Marketplace Trust: Building seller/buyer reputations that persist across platforms.
• Delegated Governance: Allowing voters to assess a delegate's proven track record and alignment.

Registries provide an immutable audit trail for physical and digital goods. Use cases include:

• Authenticity Verification: Attesting to the origin, materials, or ethical sourcing of products.
• Intellectual Property (IP): Recording creation dates, ownership transfers, and licensing terms for digital art or patents.
• Regulatory Compliance: Documenting steps in a manufacturing or food safety process for auditors.
• Carbon Credits: Verifying the issuance and retirement of environmental credits to prevent double-counting.

Attestation registries act as trust primitives that other decentralized applications (dApps) build upon. Examples are:

• Oracle Attestations: Verifying that off-chain data (e.g., price feeds) was provided by an authorized node.
• Bridge Security: Recording proofs of asset deposits on a source chain to enable minting on a destination chain.
• ZK Proof Verification: Stating that a specific zero-knowledge proof is valid, enabling other contracts to trust its output.
• Access Control: Granting permissions based on attested attributes (e.g., "holder of X NFT") instead of simple token checks.

An attestation registry stores cryptographic proofs—specifically, digital signatures—on a blockchain or other immutable ledger. These proofs link a subject (e.g., a wallet address, a DID) to a claim (e.g., "is KYC-verified") made by an issuer. The registry's primary function is to provide a public, verifiable record of who attested to what, and when, enabling anyone to independently verify the attestation's authenticity and integrity without relying on the original issuer.

By moving attestations on-chain, registries reduce reliance on centralized authorities and siloed databases. Trust is distributed to the cryptographic proof and the consensus mechanism securing the registry. This prevents single points of failure and censorship. Users control their attestations via their private keys, and verifiers can check proofs directly against the public ledger, eliminating the need to query the issuing service.

A critical security feature is the ability to revoke or update attestations. Registries must implement secure mechanisms for this, such as:

• Revocation Registries: Maintaining a separate list of revoked attestation identifiers.
• Status Lists: Using bitstrings to indicate the active/revoked status of credentials.
• Smart Contract Logic: Allowing the original issuer (or a delegate) to call a function to invalidate a claim. Proper state management is essential to prevent the use of outdated or compromised credentials.

Storing data directly on a public ledger can conflict with privacy. Advanced attestation registries employ techniques to minimize on-chain data exposure:

• Zero-Knowledge Proofs (ZKPs): Allow a user to prove they hold a valid attestation without revealing its contents or identifier.
• Selective Disclosure: Enables revealing only specific attributes from a credential.
• Off-Chain Storage with On-Chain Pointers: The attestation data is stored privately (e.g., IPFS, personal storage), while only a cryptographic hash (pointer) and the signature are stored on the registry for verification.

Attestation registries are fundamental tools for Sybil resistance in decentralized networks. By binding verifiable credentials (like proof-of-personhood or domain-specific expertise) to on-chain identities, they prevent a single entity from creating unlimited fake accounts with inflated reputation. This enables the construction of decentralized reputation systems where trust is earned through a persistent, verifiable history of attested actions and qualifications.

A W3C standard for tamper-evident credentials that can be cryptographically verified. They are the primary data structure issued and stored in an attestation registry.

• Structure: Contains claims, metadata, and a digital proof (e.g., a signature).
• Portability: Credentials are held by the subject (holder), not the issuer.
• Example: A university-issued digital diploma is a Verifiable Credential.

A W3C standard for self-sovereign identifiers that are controlled by the user, not a central authority. DIDs are often the subject of attestations in a registry.

• Format: did:method:identifier (e.g., did:ethr:0x...).
• Control: Resolves to a DID Document containing public keys and service endpoints.
• Role: Provides the cryptographic anchor for verifying attestations.

Cryptographic methods that allow one party (the prover) to prove to another (the verifier) that a statement is true without revealing the underlying data. They enhance privacy in attestation systems.

• Selective Disclosure: Prove you hold a valid credential (e.g., over age 18) without revealing your birth date.
• ZK-SNARKs / ZK-STARKs: Common proof systems used for this purpose.
• Use Case: Private proof of membership or qualification from a registry.

A component, often part of an attestation registry, that defines the structure and data types for attestations. It ensures consistency and interpretability of claims.

• Definition: Specifies the fields, formats, and meanings of data in an attestation.
• Governance: May be managed by a community, standard body, or protocol.
• Example: A schema for a KYCAttestation defining required fields like fullName and expiryDate.

A mechanism, often integrated with an attestation registry, to invalidate or revoke previously issued attestations without deleting them. This is critical for maintaining system integrity.

• Methods: Can use cryptographic accumulators, smart contract status flags, or revocation lists.
• Event Triggers: Revocation occurs if a credential is compromised or conditions change.
• Privacy-Preserving: Advanced schemes allow revocation checks without revealing which credential is being checked.