Attestation

An attestation's validity can be independently verified by anyone with access to the blockchain. This is achieved through cryptographic signatures from the issuer, creating an unforgeable proof of the statement's origin and integrity. The verification process does not require trusting a central authority, only the issuer's public key and the blockchain's consensus rules.

• Example: A university issues a degree attestation signed with its private key. Any employer can verify the signature against the university's known public key on-chain.

Once issued and recorded on a blockchain, an attestation cannot be altered or deleted without breaking the chain's consensus. This immutability provides a permanent, historical record of the statement, ensuring its contents remain exactly as the issuer intended. This property is crucial for credentials that must be resistant to forgery or retroactive changes.

• Contrasts with traditional databases where records can be edited or deleted by administrators.

Attestations are issued by decentralized identifiers (DIDs) or smart contract wallets, not centralized servers. The subject (recipient) of the attestation typically holds and controls the attestation in their own wallet, a model known as self-sovereign identity. This shifts control from institutions to individuals, allowing users to present their credentials without asking the original issuer for permission each time.

Interoperability is enabled by standardized data schemas. Frameworks like the Ethereum Attestation Service (EAS) and EIP-712 define structured formats for attestation data, ensuring different applications can read and interpret the same attestation type. A schema defines the fields (e.g., degreeType, issueDate, GPA) and their data types, creating a common language for verifiable data.

• Example: A KYC schema ensures all compliance attestations contain the same required fields for automated checking.

While the on-chain record is immutable, the validity of an attestation can be dynamically managed. Issuers can publish revocation signals (e.g., on a revocation registry) or set expiry timestamps within the attestation data. Verifiers must check both the attestation's existence and its current revocation/expiry status, enabling credentials to be invalidated if conditions change (e.g., a license is suspended).

Attestations can reference other on-chain entities (wallets, tokens, NFTs, or other attestations), creating a verifiable graph of relationships. This allows for complex, compound proofs.

• Example: A DAO Membership attestation can be issued to a wallet that holds a Proof-of-Humanity attestation, creating a credential chain. Smart contracts can then gate access based on this composite proof.

To reduce cost and increase scalability, many attestations are stored off-chain while their integrity is secured on-chain. Common patterns include:

• Signed Messages: An issuer signs a structured message (e.g., a JSON object) with their private key. The signature and message are stored off-chain (IPFS, Ceramic).
• On-Chain Anchors: A cryptographic hash (like a Merkle root) of a batch of off-chain attestations is periodically committed to a blockchain, providing a tamper-proof timestamp and verification point.
• Indexing & Querying: Services like The Graph or custom indexers are used to efficiently query and verify these off-chain attestations.

Attestations are a primary tool for building Sybil-resistant reputation in decentralized applications. Instead of relying on a single token balance, protocols can aggregate trust from multiple sources. Examples include:

• Gitcoin Passport: Aggregates stamps (attestations) from various identity providers (BrightID, ENS, Proof of Humanity) to compute a unique humanity score for Sybil defense in quadratic funding.
• DAO Delegation: Attestations can signal expertise or trustworthiness, informing delegation decisions in governance systems.
• Credit Scoring: Anonymous but verifiable history of loan repayments or protocol interactions can form the basis for decentralized credit.

Attestations create immutable, verifiable records of origin and journey for physical and digital assets. Each step in a supply chain can issue an attestation about the state, location, or handling of an item. This enables:

• Consumer Verification: End-users can scan a QR code to see a cryptographically verified history of a product's lifecycle.
• Compliance & Auditing: Automated checks for regulatory requirements (e.g., fair trade, organic certification) based on the attached attestations.
• Anti-Counterfeiting: Genuine products are linked to a non-fungible on-chain attestation that cannot be forged.

These Ethereum Improvement Proposals are critical for secure off-chain message signing, which underpins many attestation systems.

• EIP-712: Structured Data Hashing and Signing: Allows users to sign human-readable, structured data (the attestation schema and content). This is far safer than signing raw hex and is the preferred method for meta-transactions and complex attestations.
• EIP-191: Signed Data Standard: Defines a version byte and specific format for signed data, ensuring consistency and preventing signature reuse across different contexts. It's a simpler standard often used as a basis for EIP-712. Together, they ensure attestation signatures are verifiable and context-specific.

An attestation's core security property is its cryptographic verifiability. It is a digital signature (e.g., using ECDSA or EdDSA) created by an attester's private key over a structured data payload. Anyone can verify the signature against the attester's public key, proving the statement's authenticity and integrity without trusting a central authority. This creates tamper-evident records where any alteration invalidates the proof.

Trust in an attestation derives from the trust in its issuer. Different models exist:

• Decentralized Identifiers (DIDs): Self-sovereign identities where the attester is the subject.
• Trusted Issuers: Recognized entities like universities or corporations acting as oracles.
• Algorithmic/Protocol Attesters: Code-based attestations from smart contracts or zero-knowledge proof circuits.
• Crowdsourced/Consensus: Attestations validated by a decentralized network, reducing single-point trust failures.

A critical security consideration is how to invalidate an attestation if the underlying claim becomes false. Common mechanisms include:

• Revocation Registries: A smart contract or ledger where the attester publishes a revocation list.
• Status Lists: Standardized W3C method using bitstrings to indicate credential status.
• Expiry Timestamps: Built-in expiration to limit credential lifetime.
• On-Chain State Proofs: Linking the attestation's validity to the state of another on-chain asset or condition.

Secure attestation design emphasizes data minimization to protect user privacy. Techniques include:

• Selective Disclosure: Revealing only specific attributes from a credential.
• Zero-Knowledge Proofs (ZKPs): Proving a claim (e.g., 'I am over 18') without revealing the underlying data (your birth date).
• Blind Signatures: Allowing an attester to sign a claim without viewing its content.
• Off-Chain Storage: Storing the full attestation data in decentralized storage (e.g., IPFS) and only publishing a cryptographic hash on-chain.

Preventing duplicate or fake identities (Sybil attacks) is essential for systems like proof-of-personhood or voting. Attestations enable this through:

• Biometric Binding: Linking a credential to a unique physical trait (controversial but highly resistant).
• Social Graph Attestations: Verification through a web of trusted connections.
• Hardware-Bound Attestations: Using secure enclaves (e.g., TPM, Secure Element) to generate device-unique keys.
• Consensus-Based Uniqueness: Protocols like Proof of Humanity that use community verification.

A predefined template or structure that defines the fields and data types for an attestation. Schemas ensure consistency, interoperability, and ease of parsing for verifiers across different applications.

• In Ethereum Attestation Service (EAS), schemas are registered on-chain with a unique UID.
• A schema for a "KYC Attestation" might define fields for fullName (string), expiryDate (uint64), and issuerDID (string).
• Using a common schema allows different dApps to understand and trust the same type of attested data.

The mechanism to invalidate a previously issued attestation. This is critical for maintaining the integrity and freshness of attested data when credentials expire, are compromised, or need updating.

• On-chain revocation (e.g., in EAS) involves sending a transaction to a registry to flag an attestation ID as revoked.
• Off-chain revocation often uses revocation lists or status endpoints.
• Verifiers must always check the revocation status of an attestation before trusting it.