Verifiable Credential (VC)

What Is a Verifiable Credential?

A verifiable credential (VC) is a tamper-proof digital document that makes a claim about a subject and can be cryptographically verified by anyone, without contacting the entity that issued it. Think of it as a digital version of a physical credential like a passport, diploma, or professional license, but with built-in proof of authenticity that cannot be forged.

The World Wide Web Consortium (W3C) published the Verifiable Credentials Data Model (VCDM) 2.0 as a formal Recommendation on May 28, 2025. This standard defines how credentials are structured, signed, and presented across different systems. Unlike traditional digital certificates that require a live connection to the issuer for validation, verifiable credentials embed all the cryptographic proof needed for offline verification.

The core innovation is separating the act of issuing a credential from the act of verifying it. An employer can verify your university degree without calling the university. A DeFi protocol can confirm your accredited investor status without querying the original verification service. This decoupling creates a more private, portable, and efficient identity layer for both traditional and crypto-native applications.

How It Works

Verifiable credentials operate on a three-party trust model, sometimes called the "trust triangle." Each party plays a distinct role in the credential lifecycle.

The Three-Party Model

1. Issuer: an entity that creates and signs a credential. The issuer asserts claims about a subject (for example, a KYC provider asserting that a user has passed identity verification) and attaches a digital signature using their private key.
2. Holder: the entity that receives, stores, and presents credentials. The holder keeps credentials in a digital wallet and controls when and with whom they share them. Critically, the holder can select which specific claims to reveal.
3. Verifier: an entity that receives and validates a credential presentation. The verifier checks the cryptographic signature against the issuer's public key, confirms the credential has not expired or been revoked, and evaluates whether the issuer is trusted.

The verification process does not require the verifier to contact the issuer. The issuer's public key is discoverable through a Decentralized Identifier (DID) document or a hosted JSON Web Key Set (JWKS). The verifier resolves the issuer's DID, retrieves the public key, and validates the signature locally.

Credential Structure

Under VCDM 2.0, a verifiable credential is a JSON-LD document with a defined structure. The required fields include a context declaration, credential type, issuer identifier, and the claims about the subject:

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiableCredential", "KYCCredential"],
  "issuer": "did:web:kyc-provider.example.com",
  "validFrom": "2026-01-15T00:00:00Z",
  "validUntil": "2027-01-15T00:00:00Z",
  "credentialSubject": {
    "id": "did:key:z6MkhaXg...",
    "kycVerified": true,
    "jurisdiction": "US",
    "verificationLevel": "enhanced"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "verificationMethod": "did:web:kyc-provider.example.com#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3FXQqFg..."
  }
}

The proof field contains the cryptographic signature. Multiple proof formats are supported: Data Integrity Proofs (embedded in the document), JWTs (wrapping the credential as a signed token), and SD-JWTs (enabling per-claim selective disclosure). The choice of format affects privacy properties and interoperability.

Verifiable Presentations

When a holder shares credentials with a verifier, they wrap them in a Verifiable Presentation (VP). The holder signs the VP with their own key, proving they control the credentials. The VP can include a challenge nonce from the verifier to prevent replay attacks:

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiablePresentation"],
  "verifiableCredential": [
    { /* the KYC credential from above */ }
  ],
  "proof": {
    "type": "DataIntegrityProof",
    "challenge": "abc123-verifier-nonce",
    "verificationMethod": "did:key:z6MkhaXg...#key-1",
    "proofPurpose": "authentication",
    "proofValue": "z4pQr..."
  }
}

DIDs and Key Discovery

Verifiable credentials rely on Decentralized Identifiers (DIDs) to link issuers and subjects to their cryptographic keys. A DID is a globally unique identifier that the controller manages without a centralized registry. The W3C published DID Core 1.0 as a Recommendation in July 2022.

Several DID methods serve different needs: did:web resolves via HTTPS (the DID document is hosted at a well-known URL), did:key encodes the public key directly in the identifier (no resolution infrastructure needed), and did:pkh derives the DID from a blockchain address, bridging existing crypto wallets to the VC ecosystem.

Selective Disclosure and Zero-Knowledge Proofs

One of the most powerful features of verifiable credentials is the ability to prove a claim without revealing the underlying data. Instead of sharing your full date of birth to prove you are over 18, you present a zero-knowledge proof that demonstrates the claim is true without exposing the raw value.

Two primary approaches enable selective disclosure:

• BBS signatures: a pairing-based cryptographic scheme (standardized as the bbs-2023 Data Integrity cryptosuite) where the issuer signs all claims with a single signature. The holder can derive a new proof revealing only selected claims while proving the original signature is valid. BBS also provides unlinkability: multiple presentations of the same credential cannot be correlated.
• SD-JWT (Selective Disclosure JWT): each claim is individually hashed within the JWT payload. The holder chooses which claim disclosures to include when presenting the credential. Simpler to implement than BBS because it uses standard JWT infrastructure, but does not provide unlinkability.

Crypto Use Cases

Portable KYC Verification

Today, users must repeat KYC verification from scratch every time they sign up for a new exchange or DeFi platform. Verifiable credentials enable a "verify once, use everywhere" model: a licensed KYC provider issues a VC attesting to identity verification, and the user presents it to multiple platforms without re-uploading documents or re-submitting personal information each time.

For platforms, this reduces onboarding friction and KYC processing costs. For users, it minimizes the number of entities holding copies of sensitive identity documents, reducing exposure to data breaches.

Accredited Investor Verification

Securities regulations in many jurisdictions restrict certain investments to accredited investors. Traditionally, each platform independently verifies investor status. A verifiable credential issued by a licensed verifier (such as a law firm or CPA) can attest to accredited status, which the holder then presents to DeFi protocols, token sale platforms, or security token offerings without repeating the verification process.

Proof-of-Humanity and Sybil Resistance

Airdrop campaigns and governance systems need to ensure that one person cannot create multiple accounts to claim disproportionate rewards. Verifiable credentials can attest that an address belongs to a unique human being, providing sybil resistance without requiring on-chain identity disclosure.

Projects like Privado ID (formerly Polygon ID) use ZK-SNARKs in combination with verifiable credentials: the holder generates a zero-knowledge proof demonstrating they possess a valid humanity credential, which a smart contract can verify on-chain. The contract confirms uniqueness without learning the holder's identity.

VCs vs. Soulbound Tokens

Soulbound tokens (SBTs) serve a similar purpose as non-transferable on-chain attestations. However, VCs and SBTs differ in critical ways:

VCs are generally the more privacy-preserving and interoperable approach. SBTs offer simplicity and composability within a single blockchain ecosystem. Some protocols use both: issuing a VC for private verification and an SBT for public, on-chain reputation.

Why It Matters for Crypto

Verifiable credentials address a fundamental tension in crypto: the need for compliance and trust without sacrificing privacy or self-custody principles. As regulatory frameworks like the EU's eIDAS 2.0 (mandating digital identity wallets for all member states by 2026-2027) and the GENIUS Act reshape the compliance landscape, verifiable credentials offer a path to meet requirements without building centralized identity databases.

For payment protocols and wallet infrastructure, VCs can enable compliant transactions while preserving user privacy. A stablecoin payment rail could verify that a sender has passed KYC without ever seeing their personal data. An embedded wallet could store both financial assets and identity credentials, unifying the user experience. As identity and payments converge, verifiable credentials provide the cryptographic plumbing that makes privacy-preserving compliance possible.

For a deeper look at how identity primitives intersect with Bitcoin-native protocols, see the research on Nostr, Bitcoin identity, and payments and zero-knowledge proof applications in Bitcoin.

Risks and Considerations

Interoperability Fragmentation

Despite the W3C standard, the VC ecosystem is fragmented across competing formats (JSON-LD Data Integrity, JWT, SD-JWT, AnonCreds, ISO mdoc) and DID methods. Different deployments use different subsets of the specification, and the issuance/verification protocol layer is split between the VC API and OpenID for Verifiable Credentials (OpenID4VC). A credential issued in one ecosystem may not be verifiable in another without translation.

Privacy and Correlation Risks

If a holder uses the same credential identifier or DID across multiple verifiers, their interactions can be correlated. JWT-based credentials are particularly vulnerable because the signature is constant across presentations. BBS signatures mitigate this with unlinkability, but BBS adoption remains limited. Additionally, if a verifier queries the issuer's revocation status list, the issuer can potentially track when and where credentials are being used.

Key Management Burden

Holders must manage private keys to control their credentials. Losing a key means losing access to all credentials bound to it. Unlike passwords, there is no "forgot my key" recovery path unless the wallet implements social recovery or backup mechanisms. This mirrors the key management challenges familiar from self-custodial crypto wallets.

Issuer Trust and Governance

Verifiable credentials solve the technical problem of tamper-evidence, but not the governance problem of trust. A verifier must still decide which issuers to trust. A fraudulent issuer can produce technically valid but factually false credentials. Trust frameworks (registries of approved issuers, regulated industries with licensing requirements) are still being developed and vary by jurisdiction.

Revocation Complexity

Revoking a credential requires the issuer to maintain and publish a status list (such as the W3C Bitstring Status List). This introduces an ongoing operational burden and, if the status endpoint goes offline, verifiers cannot confirm revocation status. Privacy-preserving revocation mechanisms (like cryptographic accumulators) exist but add computational overhead.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.