Verifiable Credentials on Bitcoin: Architecture and Implementation Patterns

Jul 3, 2026

Verifiable Credentials on Bitcoin: Architecture and Implementation Patterns

Introduction

Verifiable Credentials (VCs) are the practical payload of decentralized identity. While DIDs provide the identifiers, VCs carry the claims: a university degree, a professional license, proof of employment, KYC status. When both the issuer and holder use Bitcoin-anchored DIDs, the entire trust chain inherits Bitcoin's security properties, though the VC model works across any DID method.

The Verifiable Credential Model

The VC ecosystem has three roles:

  • Issuer: An entity that makes claims about a subject and signs them cryptographically. Examples: universities, employers, government agencies.
  • Holder: The subject of the credential who stores it and presents it when needed. Typically an individual or organization.
  • Verifier: An entity that receives a credential presentation and checks its validity.

The critical difference from traditional systems: the verifier doesn't need to contact the issuer at verification time. The cryptographic signature is self-contained and can be verified against the issuer's public DID.

Anatomy of a Verifiable Credential

A VC is a JSON (or JSON-LD) document with a specific structure:

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiableCredential", "ProfessionalLicense"],
  "issuer": "did:ion:EiA3...",
  "issuanceDate": "2026-03-16T00:00:00Z",
  "credentialSubject": {
    "id": "did:ion:EiD7...",
    "licenseType": "Software Engineering",
    "jurisdiction": "US-TX"
  },
  "proof": {
    "type": "JsonWebSignature2020",
    "created": "2026-03-16T00:00:00Z",
    "verificationMethod": "did:ion:EiA3...#key-1",
    "jws": "eyJhbGciOi..."
  }
}

The proof section contains a digital signature over the credential content, made with a key that can be resolved through the issuer's DID document.

(This example follows the VC Data Model 1.1 conventions: the https://www.w3.org/2018/credentials/v1 context, issuanceDate, and a JsonWebSignature2020 proof, whose signature lives in a jws member. VC Data Model 2.0 became a W3C Recommendation in May 2025: it uses the https://www.w3.org/ns/credentials/v2 context, replaces issuanceDate with validFrom, and favors a DataIntegrityProof or the enveloped VC-JOSE-COSE form over the now-deprecated JsonWebSignature2020.)

Issuance Flow with Bitcoin-Anchored DIDs

  1. Issuer setup: The issuing organization creates a DID anchored to Bitcoin. Their DID document lists public keys authorized for credential signing. ION was the best-known Bitcoin-anchored DID method, but its highest-profile deployment, Microsoft Entra Verified ID, only ever supported it in preview and retired it in December 2023 in favor of did:web (Microsoft Learn). did:btcr2 is an actively-developed alternative anchored directly to Bitcoin, though as a still-evolving specification it should be weighed against your method's maturity, tooling, and resolution requirements.
  2. Subject identification: The holder presents their own DID to the issuer through whatever verification process the issuer requires.
  3. Credential creation: The issuer constructs the VC, populating the credentialSubject with the holder's DID and the relevant claims.
  4. Signing: The issuer signs the credential with a private key corresponding to a public key in their DID document.
  5. Delivery: The signed credential is transmitted to the holder, who stores it in their credential wallet.

Verification Flow

  1. Presentation: The holder creates a Verifiable Presentation (VP) containing one or more VCs, signed with their own DID's private key.
  2. DID resolution: The verifier resolves the issuer's DID (via Bitcoin and the ION/Sidetree network) to obtain the issuer's public keys.
  3. Signature check: The verifier validates the credential's signature against the issuer's resolved public key.
  4. Status check: Optionally, the verifier checks a revocation registry to confirm the credential hasn't been revoked.
  5. Trust decision: The verifier decides whether they trust the issuer for the type of claim being made.

For signature verification the verifier never has to contact the issuer's servers: it resolves the issuer's DID instead. Revocation is the exception, since a status check (Step 4) typically dereferences a status list at a URL the issuer publishes. Note that for Sidetree-based methods like ION, the Bitcoin transaction anchors only a hash of the operation batch: the DID document data itself lives off-chain in content-addressable storage (IPFS), so a resolver must fetch and replay that off-chain data, and the model carries known caveats such as the late-publishing attack.

Implementation Patterns

Credential Wallet Architecture

Holder wallets need to:

  • Manage multiple DIDs and key pairs
  • Store credentials securely (encrypted at rest)
  • Construct presentations with selective disclosure
  • Handle credential refresh and revocation notifications

Revocation Strategies

The most common approaches for Bitcoin-anchored systems:

  • Status lists: The issuer publishes a bitstring status list where each position corresponds to a credential, and a 1 means revoked. The standard secures the list with its own credential proof served at a URL; integrity doesn't depend on Bitcoin, though an issuer could optionally anchor a hash of the list to Bitcoin as an extra check.
  • Expiration-based: Short-lived credentials that must be re-issued periodically, avoiding revocation complexity entirely.

Selective Disclosure

Not every verification needs the full credential. Techniques like SD-JWT (Selective Disclosure for JSON Web Tokens, RFC 9901) allow holders to reveal only specific fields. For example, proving you're over 21 without revealing your birth date or name.

Conclusion

Verifiable Credentials turn DIDs from abstract identifiers into practical tools. When anchored to Bitcoin, the trust chain doesn't depend on centralized infrastructure, though the VC model is designed to work across any DID method, and the choice of anchor layer depends on the use case. The core W3C VC Data Model is a stable Recommendation, libraries exist in major languages, and the architecture patterns are well-established, though the surrounding securing-mechanism and DID-method tooling layers are still evolving. The remaining challenges are around key management UX, revocation at scale, and ecosystem interoperability.

Jintek LLC