What it is
An onchain attestation is a small, signed piece of data that says something about an address, person, or event — for example "this wallet passed KYC," "this contributor reviewed grant applications," or "this address is not a bot." Instead of a company's private database holding that claim, it's published (or its hash is published) on a blockchain or a shared attestation registry, so any application can look it up and verify who made the claim and when.
How it works
- An issuer (a person, DAO, protocol, or automated oracle) decides to make a claim about a subject (usually a wallet address).
- The issuer signs a structured piece of data — a schema defining fields like claim type, subject, expiration, and value — using their private key.
- The attestation is written to a registry contract (or an off-chain store with an on-chain anchor/hash) that indexes attestations by issuer, subject, and schema, making them publicly queryable.
- Any downstream application can query the registry: "show me all attestations issued by Gitcoin Passport about this address" or "does this address have an attestation from a trusted issuer for schema X."
- Because the attestation is signed, its authenticity can be verified independently of the issuer's server being online — the signature alone proves who issued it and that it hasn't been tampered with.
- Revocation is handled separately: issuers can mark an attestation revoked, and consuming applications must check revocation status, not just existence.
Why designers use it
- Decouples "who verified this fact" from "who is using this fact" — one issuer's work can be reused by many applications instead of every app rebuilding its own verification.
- Makes trust composable and auditable: anyone can see which issuer vouched for what, and weight issuers differently.
- Enables privacy-preserving identity and reputation systems that don't require a single central database of personal data.
Failure modes
- Issuer trust concentration: if only one or two issuers dominate a schema (e.g., a single KYC provider), the system re-creates the centralization it was meant to avoid — that issuer becomes a single point of failure or censorship.
- Stale or unrevoked claims: an attestation issued once (e.g., "verified human") may be trusted forever if apps don't check for revocation or expiration, even after the underlying fact changes.
- Sybil attestations: if issuance is cheap or automatable, an attacker can get an army of addresses attested, defeating the purpose (this is why attestation schemes are often paired with sybil-resistance mechanisms).
- Schema ambiguity: loosely defined schemas lead to apps interpreting the same attestation differently, causing inconsistent trust decisions across the ecosystem.
What to check before using it
- Who are the trusted issuers for the schemas you rely on, and what happens if one is compromised or goes offline?
- Does your application check for revocation and expiration, not just presence of an attestation?
- Is the schema well-specified enough that other consumers will interpret the claim the same way you do?
- What's the cost or friction of getting an attestation issued — is it sybil-resistant enough for your use case?
- Are attestations portable across chains/apps, or locked into one issuer's proprietary registry?