What it is
A verifiable credential is a digitally signed claim issued by some trusted party (a government, an identity provider, a DAO, a KYC vendor) about a subject (a person or wallet), which the subject can present to third parties who can cryptographically verify it's authentic without contacting the issuer every time. In crypto, these are often used to prove humanity, jurisdiction, age, or accreditation without revealing the raw documents behind the claim.
How it works
- An issuer (an ID verification company, a DAO, a government-backed system) collects some real-world proof from a user — a passport scan, a biometric check, a proof of address.
- The issuer runs its own verification process off-chain, then generates a credential: a signed data object stating a claim ("this person passed liveness+ID check", "this wallet is not on a sanctions list") tied to the user's identity or wallet.
- The credential is handed to the user, who stores it in a wallet or identity app — sometimes as an onchain attestation (e.g., via an attestation registry), sometimes off-chain as a portable signed object.
- When a dApp needs to gate access (a mint, a vote, a regulated product), it asks the user to present the credential.
- The dApp verifies the issuer's signature against a known public key or registry, confirming the claim is authentic and unexpired, without needing to see the original passport or re-run KYC.
- Advanced schemes layer zero-knowledge proofs on top, letting the user prove a derived fact (e.g., "I am over 18") from the credential without revealing the credential's other contents (exact birthdate, name).
- Revocation lists or expiry timestamps let issuers invalidate credentials later (a ban, a status change) without needing users to interact again.
Why designers use it
- Lets protocols meet compliance or Sybil-resistance requirements (KYC, uniqueness, age-gating) without becoming a data custodian themselves.
- Decouples "who verified this" from "who uses this" — one issuer's work can be reused across many apps, reducing redundant verification.
- With zero-knowledge layering, enables selective disclosure: prove a fact without exposing the underlying sensitive data, improving privacy over raw document uploads.
- Provides Sybil resistance for airdrops, governance, and quadratic funding by attaching a scarce, hard-to-fake "one real human" or "verified entity" signal to a wallet.
Failure modes
- Issuer capture or compromise: if the issuing key or backend is compromised, arbitrarily many fake credentials can be minted, undermining every downstream app relying on them.
- Credential markets emerge — people sell or rent verified identities/wallets to Sybil attackers, especially when the credential unlocks valuable airdrops or votes.
- Centralization risk: most schemes still rely on a small number of issuers, recreating the "trusted third party" problem crypto often tries to avoid.
- Privacy leakage: naive implementations expose more data than needed (linking a wallet permanently to a real identity) instead of using selective disclosure, creating a honeypot for deanonymization.
- Revocation is often weak or delayed in practice, meaning a credential from a now-banned or compromised identity can remain "valid" longer than it should.
What to check before using it
- Who is the issuer, how are they vetted, and what happens to your app if that issuer is compromised or goes offline?
- Does the credential support selective disclosure/zero-knowledge proofs, or does verifying it require exposing more personal data than necessary?
- Is there a functioning revocation mechanism, and how quickly does your app pick up revocations?
- How resistant is the underlying real-world verification to Sybil attacks (buying accounts, renting verified identities, using stolen documents)?
- Are you creating a single point of censorship — could the issuer selectively refuse or revoke credentials to exclude certain users from your app?