The W3C DID Standard and Bitcoin: Current State, Tooling, and What's Next

Introduction

The W3C Decentralized Identifiers (DID) specification reached v1.0 recommendation status in 2022, establishing a universal standard for creating and resolving decentralized identifiers. This standard provides the interoperability layer that lets Bitcoin-anchored identities work with the broader DID world. Here's where things stand.

The W3C DID Core Specification

DID Core defines the syntax and data model for DIDs. Every DID, regardless of the underlying network, follows the same format:

did:<method>:<method-specific-identifier>

The DID Core spec defines how DID documents are structured, what verification methods look like, how services are described, and how resolution works. It's intentionally method-agnostic — the same tooling can resolve any DID regardless of its underlying network.

Bitcoin-Anchored DID Methods

did:ion

Status: Deployed on mainnet (v1.0.4), development dormant since mid-2023

ION (Identity Overlay Network) is a Layer 2 DID network built on the Sidetree protocol, developed primarily by Microsoft under the Decentralized Identity Foundation. It batches DID operations — create, update, recover, and deactivate — into a hierarchical file structure (Core Index, Provisional Index, Chunk Files, Proof Files), stores them on IPFS, and anchors a single hash to a Bitcoin transaction. This allows thousands of operations per transaction.

Resolution works by replaying anchored operations in chronological order from Bitcoin, downloading the referenced files from IPFS, and deterministically reconstructing each DID's current state. No additional consensus layer is needed — Bitcoin provides the only ordering oracle.

Strengths:

• Massive batching efficiency — thousands of DID operations per Bitcoin transaction
• No special token required — just Bitcoin
• Permissionless and self-certifying — anyone can run a node and create DIDs
• Deterministic resolution from Bitcoin + IPFS without additional consensus

Considerations:

• Critically depends on IPFS for off-chain data storage and retrieval — if CAS content is not pinned, resolution can fail
• Running a node requires a Bitcoin full node, an IPFS node, and the ION/Sidetree stack — substantial infrastructure overhead
• Both the ION and Sidetree repos have seen no meaningful development since mid-2023, and the Sidetree reference implementation was removed in April 2023
• The hierarchical file structure and deterministic replay algorithm add significant implementation complexity
• Operations require Bitcoin confirmation (~10 minutes) plus IPFS propagation before they are globally resolvable

did:btcr

Status: Draft Community Group Report (August 2019), specification stalled

BTCR (Bitcoin Reference) was developed through the W3C Credentials Community Group as a minimal, conservative DID method anchored directly to Bitcoin transactions. A BTCR DID encodes a transaction position using BIP-136 TxRef (Bech32-encoded block height + transaction index). Identity lifecycle is managed through a chain of Bitcoin transactions — the initial transaction creates the DID, subsequent transactions spending the designated output update it, and an unspent output indicates the current version.

Each transaction's signing key (ECDSA secp256k1) becomes the authentication key for that DID version, with key rotation happening naturally as each spend reveals the current key. An optional OP_RETURN field can reference an external "continuation document" for richer DID Document content beyond what the transaction encodes.

Strengths:

• Direct Bitcoin integration — no separate protocol layer or token
• Minimal design with a transparent, auditable update history on-chain
• Implicit DID Document generation from just the transaction data

Considerations:

• Every create, update, and revoke operation requires its own Bitcoin transaction (no batching)
• Continuation documents are fetched via HTTP URLs, introducing availability and censorship concerns
• The specification has not been updated since 2019 and remains incomplete (security/privacy sections are empty)
• Each active DID maintains a permanent unspent output, contributing to UTXO set growth

did:btcr2

Status: Active specification and implementation development

BTCR2 is a second-generation Bitcoin DID method developed by Digital Contract Design, Legendary Requirements, Jintek LLC, and BlipJoy LLC. It addresses the privacy shortcomings of did:btcr — where DID documents were publicly visible on-chain — by making documents private by default through sidecar delivery. Instead of storing data on a public ledger, DID controllers deliver update history directly to verifiers through any private channel.

DIDs use Bech32m encoding with two types: key-based (k prefix) where the genesis document is deterministically generated from the DID string alone (no sidecar needed for baseline resolution), and document-based (x prefix) where the controller provides a genesis document via sidecar. Updates are JSON Patches (RFC 6902) signed with BIP340 Schnorr signatures using the bip340-jcs-2025 Data Integrity cryptosuite.

The three-tier beacon system anchors updates on Bitcoin with different privacy/cost tradeoffs:

• Singleton Beacon — one update per transaction, simplest model
• CAS Beacon — aggregates multiple DIDs into a single transaction via Content-Addressable Storage (IPFS in practice), enabling cost-sharing
• SMT Beacon — maximum privacy aggregation using Sparse Merkle Trees where even the aggregation service cannot see which DIDs are being updated

CAS and SMT Beacons use n-of-n MuSig2 (BIP327) multisig over Pay-to-Taproot addresses, ensuring the aggregation service cannot compromise any participant's DID without their cooperation.

Strengths:

• Zero-cost offline DID creation — no transaction or network interaction needed
• Privacy by default — DID documents never appear on any public ledger
• Key-based DIDs resolve deterministically from the DID string alone
• Scalable on-chain costs through CAS and SMT aggregation
• Late-publishing attack detection — hidden updates that attempt to rewrite history cause resolution to fail

Considerations:

• The DID controller must retain and deliver the complete update history; lost sidecar data makes the DID unresolvable
• CAS Beacons currently depend on IPFS as the only practical CAS option
• Specification is still under active development and subject to breaking changes
• CAS Beacon cohort members can see which DIDs are updated in each signal (SMT Beacons solve this)

did:btc

Status: Unofficial specification (MicroStrategy), development stalled since August 2024

did:btc is a DID method created by MicroStrategy that stores all DID data directly on-chain in Bitcoin transactions, eliminating external dependencies like IPFS or sidecar files. Creation transactions embed the initial public key and verification relationship flags in an OP_RETURN output (up to 76 bytes). An optional second P2TR output creates a "DID UTXO" that controls future updates — if omitted, the DID is permanently immutable.

A key design feature is controller/subject key separation: the secp256k1 wallet keys controlling the DID UTXO are distinct from the subject keys in the DID Document, which can be any Multikey-supported type (Ed25519, P-256, secp256k1). This enables custodial management and different security tiers for control vs. subject keys.

Batch creation uses a two-step commit/reveal inscription pattern (similar to Ordinals) that benefits from the SegWit 75% witness discount, scaling from ~151 vbytes/DID for 2 DIDs down to ~8 vbytes/DID for 10,000 DIDs. Updates use JSON payloads inscribed in witness data, supporting granular operations (add, update, delete verification methods and document properties).

Strengths:

• Fully on-chain — no IPFS, no external URLs, no sidecar files; eliminates data availability concerns
• Efficient batch creation at scale via commit/reveal inscription pattern
• Subject keys are type-agnostic (not limited to secp256k1)
• DIDs can be made permanently immutable by omitting the DID UTXO

Considerations:

• The spec acknowledges this is "likely to be the most expensive per byte of DID document data" of any DID method
• The spec requires waiting 6 block confirmations (~60 minutes) before publishing identifiers
• Trustless resolution requires running a full Bitcoin node; using public APIs reintroduces trust dependencies
• No commits since August 2024, with several unresolved fundamental design questions in open issues
• All DID data is fully public on-chain with no mechanism for selective disclosure

did:btco

Status: Editor's Draft (v0.2.0), DIF Labs incubation

did:btco anchors digital identities to individual satoshis using Ordinal Theory. Each satoshi has a unique ordinal number, and a DID Document is inscribed as CBOR-encoded metadata onto that satoshi — the ordinal number becomes the DID identifier (e.g., did:btco:1066296127976657). The specification is published under DIF Labs (Ordinals Plus).

Resolution works by querying a satoshi's full inscription history through the ord reference client and taking the most recent valid inscription with metadata as authoritative. Updates are reinscriptions on the same satoshi, forming a version history. The method uses a dual-key model: the Bitcoin UTXO key controls the satoshi (and therefore the DID), while the DID Document keys (Ed25519, X25519, or secp256k1 via Multikey) handle authentication and assertion independently.

Strengths:

• Clean identifier model — a single integer (the satoshi ordinal) is the entire method-specific ID
• DID Document keys are independent from the Bitcoin control key, allowing key rotation without transferring the satoshi
• Permanent, immutable inscription history inherits Bitcoin's durability
• Supports multiple cryptographic suites via Multikey encoding

Considerations:

• Every create, update, and deactivate requires a Bitcoin inscription transaction
• Resolution depends on the ord indexer's interpretation of inscription ordering — changes to ord's rules could affect resolution
• All DID data is permanently public on-chain; mistakes cannot be erased, only superseded
• Loss of the UTXO private key means permanent loss of the DID with no recovery mechanism
• The v0.1.0 to v0.2.0 breaking change (dropping name and decimal identifier formats) signals the spec is still in flux

did:dht

Status: Implementer's Draft (v1.0), multiple SDK implementations available

did:dht stores DID Documents on Mainline DHT — the distributed hash table powering BitTorrent — with DID Documents encoded as DNS Resource Records per RFC 1035. Every did:dht is derived from an Ed25519 key pair, with the public key z-base-32 encoded as the DID suffix. The specification was created by TBD (Block, Inc.) with implementations in Go, TypeScript, Kotlin, Swift, Dart, and Rust.

DID Documents are stored as BEP44 signed mutable items on Mainline, which provides ~10 million concurrent nodes and 15+ years of proven operation. Records naturally expire after ~2 hours and must be republished. Gateway servers extend this model by republishing DIDs on behalf of controllers (earned through proof-of-work retention challenges) and providing historical resolution, type-based indexing, and discovery.

Bitcoin's role is optional and peripheral: gateways can use Bitcoin block hashes as proof-of-work challenge inputs, and gateways can register themselves on-chain via timelock transactions with OP_RETURN for decentralized gateway discovery. Bitcoin is not used for anchoring DIDs themselves.

Strengths:

• Zero-cost DID creation and updates — no transaction fees or blockchain interaction required
• Leverages Mainline's massive existing infrastructure (~10 million nodes) with no new network to bootstrap
• Deterministic fallback — a did:dht can always be expanded to a minimal DID Document from just the DID string
• Interoperable with did:key and did:jwk when using Ed25519 keys
• Broad SDK support across six languages

Considerations:

• The Identity Key (Ed25519) cannot be rotated because it serves as the DHT address; key compromise requires migrating to a new DID
• Records expire in ~2 hours without active republishing or gateway retention
• BEP44 payload limit of 1000 bytes constrains DID Document size
• All data on Mainline is public with no mechanism for private DID Documents
• Bitcoin integration is limited to gateway discovery and retention challenges — it does not provide immutability guarantees for the DID data itself

The Companion Specifications

DID Core is only part of the picture. Several companion specifications complete the ecosystem:

Verifiable Credentials Data Model (v2.0)

Status: W3C Recommendation (May 2025). Defines the data model for tamper-evident digital credentials — how they are structured, secured, and verified across a three-party ecosystem of issuers, holders, and verifiers. v2.0 adds support for multiple securing mechanisms beyond Data Integrity signatures, including JOSE/COSE-based enveloping proofs (e.g., JWT-secured credentials), selective disclosure, and zero-knowledge proof support.

Verifiable Presentations

Defined within the VC Data Model spec (not a separate document). Verifiable Presentations are how holders selectively disclose information from one or more credentials to a verifier. A presentation can combine credentials from different issuers and include additional data beyond the credentials themselves, enabling privacy-preserving disclosure — sharing only what's relevant rather than entire credentials.

DID Resolution (v0.3)

Status: W3C Working Draft (still in progress, not yet a Recommendation). Defines the algorithms for resolving a DID into its DID Document and for dereferencing DID URLs to obtain specific resources. Covers input options, output metadata, error handling, multiple resolver architectures (local, remote, proxied), and an HTTP(S) binding for network-based resolution. The actual steps for communicating with a specific verifiable data registry are left to each DID method specification.

DIDComm Messaging (v2.1)

Status: DIF Working Group Approved. A protocol for secure, private, encrypted communication between DIDs — published by the Decentralized Identity Foundation. DIDComm defines plaintext message formats, encryption and signing mechanisms, intermediary routing, and the foundation for building higher-level protocols on top of peer-to-peer DID-authenticated channels.

Available Tooling

Method-Specific Libraries

• did:ion — ion-tools (JavaScript/TypeScript) for creating, updating, and resolving ION DIDs
• did:btcr2 — @did-btcr2 monorepo with nine packages: method core, BIP340 cryptosuite, keypair management, Bitcoin RPC/Esplora clients, SMT implementation, KMS, high-level SDK, and CLI
• did:dht — Client SDKs in Go, TypeScript, Kotlin, Swift, Dart, and Rust as part of TBD's Web5 ecosystem, plus a reference gateway server in Go
• did:btco — labs-ordinals-plus from DIF Labs for Ordinals-based DID operations

Cross-Method Libraries

• did-resolver — Universal resolver library with pluggable method drivers
• did-jwt / did-jwt-vc — Create and verify JWTs and Verifiable Credentials using any DID method

Infrastructure

• Bitcoin Core — A full node is the foundation for any Bitcoin-anchored DID method; the official guide covers setup on all major platforms
• DIF Universal Resolver — Multi-method resolution gateway supporting dozens of DID methods via pluggable drivers
• did:dht Gateways — Specialized servers that republish DHT records, provide historical resolution, and enable type-based DID discovery
• ION nodes — Self-hostable Bitcoin + IPFS + Sidetree stack for sovereign ION resolution (note: no active maintenance since mid-2023)

Conclusion

The W3C DID standard provides a solid, vendor-neutral foundation for decentralized identity, and the companion specs — Verifiable Credentials v2.0, DID Resolution, DIDComm — are maturing alongside it. On the Bitcoin side, the landscape is uneven. ION and did:btcr reached production or draft status but have seen little development in years. did:btc and did:btco are fully on-chain approaches still in early specification. did:btcr2 and did:dht represent the more active frontier — btcr2 with its privacy-first sidecar model and aggregated beacons, did:dht with its zero-cost DHT-based resolution and optional Bitcoin anchoring.

Each method makes different tradeoffs between cost, privacy, resolution speed, data availability, and infrastructure requirements. No single method is the right choice for every use case. The standards layer is stable enough to build on, but the method layer is still sorting out which designs will prove durable in practice.