The W3C DID Standard and Bitcoin: Current Status, Tools, and Outlook

Introduction

The W3C Decentralized Identifiers (DIDs) v1.0 specification became a W3C Recommendation in July 2022. It gives one standard to create and resolve decentralized identifiers. As of September 2026, DID v1.1 is a Candidate Recommendation, and v1.0 stays the current Recommendation. This standard is the interoperability layer that lets Bitcoin-anchored identifiers work with other DID systems. This post describes the status as of September 2026.

The W3C DID Core Specification

DID Core defines the syntax and the data model for DIDs. All DIDs use the same format, independent of the network below them:

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

The DID Core specification defines the structure of DID documents, verification methods, and services. It also defines the interface for resolution. The data model is the same for all methods, so the same tools can process DID documents from any method. But each DID method specification defines how to communicate with its verifiable data registry. Thus a resolver needs support for each method.

Bitcoin-Anchored DID Methods

did:ion

Status: Released for Bitcoin mainnet. The last release is v1.0.4 (June 2022). The repository has no commits after August 2023 (as of September 2026).

ION (Identity Overlay Network) is a public, permissionless Layer 2 DID network on Bitcoin. It uses the Sidetree protocol, a DIF specification with editors from Microsoft, Transmute, and SecureKey. Sidetree puts DID operations (create, update, recover, and deactivate) into a hierarchy of files: Core Index, Provisional Index, Chunk, and Proof files. ION stores these files on IPFS and anchors one hash in one Bitcoin transaction. One batch can hold up to 10,000 operations.

To resolve a DID, a node replays the anchored operations from Bitcoin in chronological order. The node downloads the referenced files from IPFS and computes the current state of each DID with deterministic rules. Bitcoin gives the order of operations, so ION needs no additional consensus mechanism.

Strengths:

• Efficient batches: up to 10,000 DID operations in one Bitcoin transaction
• No special token: ION uses only Bitcoin
• Public and permissionless: anyone can run a node and create DIDs
• Deterministic resolution from Bitcoin and IPFS, with no additional consensus

Considerations:

• Resolution depends on IPFS for off-chain data. If nobody pins the CAS content, resolution can fail.
• A node needs Bitcoin Core, Kubo (IPFS), and MongoDB, plus the ION services. This is a large infrastructure requirement.
• The ION and Sidetree repositories show no significant development after mid-2023. The maintainers removed the Sidetree reference implementation in April 2023.
• The file hierarchy and the deterministic replay algorithm add implementation complexity.
• An operation needs a Bitcoin confirmation (about 10 minutes) and IPFS propagation before all nodes can resolve it.

did:btcr

Status: Draft Community Group Report (8 August 2019). The specification has no substantive updates after August 2019.

BTCR (Bitcoin Reference) is a DID method from the W3C Credentials Community Group. Its design goals are minimal and conservative, with DIDs anchored directly in Bitcoin transactions. A BTCR DID encodes a transaction position with BIP-136 TxRef, which puts the block height and the transaction index into Bech32 format. A chain of Bitcoin transactions controls the DID lifecycle. The first transaction creates the DID, and each transaction that spends the current output updates the DID. The unspent output shows the current version.

If the first transaction has no OP_RETURN, the resolver generates the DID document from the transaction. The key that signed the transaction (ECDSA secp256k1) then gets two capabilities: "Authentication" and "Sign Verifiable Credentials". All later transactions must have an OP_RETURN with an HTTP URL to a continuation DID document. If the last transaction in the chain has no OP_RETURN, the DID is deleted (revoked).

Strengths:

• Direct Bitcoin integration: no separate protocol layer and no token
• Minimal design, with an on-chain update history that anyone can audit
• Implicit DID document from the transaction data only

Considerations:

• Each create, update, and revoke operation needs its own Bitcoin transaction (no batches)
• Resolvers get continuation documents through HTTP URLs. This adds availability and censorship risks.
• The specification has no updates after 2019 and is incomplete. The subsections of its security and privacy considerations are empty.
• Each active DID keeps an unspent output. The specification itself names this UTXO inflation.

did:btcr2

Status: Active development of the specification and the implementation (as of September 2026)

BTCR2 is a second-generation Bitcoin DID method. Its authors are from Digital Contract Design, Legendary Requirements, Jintek LLC, and BlipJoy LLC. The earlier did:btcr method focused on censorship resistance, and DID systems at that time relied heavily on public DID documents. The did:btcr2 method adds private DID documents through sidecar delivery. The DID controller does not store the data on a public ledger. Instead, the controller gives the update history directly to verifiers through any private channel.

DIDs use the Bech32m format and have two types:

• Key-based DIDs (k prefix): The resolver generates the initial DID document from the DID itself. The controller gives only the updates by sidecar.
• Document-based DIDs (x prefix): The DID encodes the hash of a genesis document. The controller gives the genesis document by sidecar.

Updates are JSON Patches (RFC 6902) with BIP340 Schnorr signatures. The signatures use the bip340-jcs-2025 Data Integrity cryptosuite.

The beacon system has three types. Each type anchors updates on Bitcoin with a different balance of privacy and cost:

• Singleton Beacon: one update in each transaction. This is the simplest model.
• CAS Beacon: one transaction for updates from many DIDs, with a Beacon Announcement Map in content-addressable storage (in practice, IPFS). The DIDs share the cost.
• SMT Beacon: aggregation with a Sparse Merkle Tree, for more privacy. A nonce in each leaf makes an update and a non-update look the same. Thus the Aggregation Service cannot see which cohort members updated.

For both CAS and SMT Beacons, the Aggregation Service must know all DIDs in the cohort. It needs the DIDs to build the CAS Announcement or to compute the SMT leaf paths. The SMT nonce hides two things: if a participant updated in a given signal, and the content of that update.

For CAS and SMT Beacons, the specification RECOMMENDS an n-of-n MuSig2 (BIP327) Pay-to-Taproot address. Each Beacon Signal then needs a partial signature from every participant. With this setup, neither the Aggregation Service nor other participants can compromise or invalidate the DID of a participant.

Strengths:

• Offline DID creation at zero cost: no transaction and no network interaction
• Private DID documents: DID documents do not go on Bitcoin, and the controller decides if updates go to a public CAS
• The initial document of a key-based DID comes from the DID itself
• On-chain costs that scale through CAS and SMT aggregation
• Detection of late publishing: if a hidden update tries to change the history, resolution fails with a LATE_PUBLISHING error

Considerations:

• The DID controller must keep and deliver the complete update history. If the sidecar data is lost, the DID can become unresolvable.
• In practice, IPFS is the only widely used CAS for CAS Beacons.
• The specification says that it "is still under active development and may be subject to breaking changes".
• CAS Beacon cohort members can see which DIDs update in each signal. SMT Beacons hide this from cohort members and from the Aggregation Service, but the Aggregation Service still knows all DIDs in the cohort.

did:btc

Status: Unofficial specification (MicroStrategy). The repository has no commits after August 2024 (as of September 2026).

did:btc is a DID method from MicroStrategy. It stores all DID data directly in Bitcoin transactions, so it has no external dependencies such as IPFS or sidecar files. The creation transaction has an OP_RETURN output with three parts. These are the ASCII text did, one byte of flags for verification relationships, and a Multikey public key of up to 76 bytes. An optional second output (P2TR) is the "DID UTXO", which controls future updates. If this output is not present, the DID is final and nobody can update it.

An important design feature is the separation of wallet keys and subject keys. The secp256k1 wallet keys control the DID UTXO. The subject keys in the DID document can use any key type that Multikey can encode, for example Ed25519. Thus a third party can manage a DID for its subject. Also, the keys that update or revoke a DID can have more protection than the subject keys.

Batch creation uses a commit and reveal pattern with inscriptions, similar to Ordinals. It gets the SegWit discount, because witness data counts at 25% weight. The cost goes from about 151 vbytes per DID for 2 DIDs to about 8 vbytes per DID for 10,000 DIDs. Updates are JSON payloads in witness data. They support operations that add, update, and delete verification methods and document properties.

Strengths:

• Fully on-chain: no IPFS, no external URLs, and no sidecar files. Data availability depends only on Bitcoin.
• Efficient batch creation at scale through commit and reveal inscriptions
• Subject keys can use any key type (not only secp256k1)
• A DID can be permanently immutable if you omit the DID UTXO

Considerations:

• The specification says that the method "is likely to be the most expensive per byte of DID document data used".
• The specification says that DID creators "MUST wait at least 6 blocks" after confirmation before they publish the identifier. That is about one hour at typical block times.
• Resolution needs access to a Bitcoin node. The specification says that public servers "introduce some degree of trust and external dependencies".
• The repository has no commits after August 2024. Open issues from 2024 ask basic design questions, for example about the choice of TxRef and JSON.
• All DID data is public on-chain, with no mechanism for selective disclosure.

did:btco

Status: Editor's Draft (v0.2.0), a DIF Labs project. The repository has no commits after June 2025 (as of September 2026).

did:btco anchors digital identities to individual satoshis with Ordinal Theory. Each satoshi has a unique ordinal number. The DID document goes into an inscription on that satoshi as CBOR metadata, and the ordinal number is the DID identifier (for example did:btco:1066296127976657). DIF Labs (Ordinals Plus) publishes the specification.

To resolve a DID, the resolver uses the ord reference client to get the inscription history of the satoshi. The most recent valid inscription with DID metadata is authoritative. An update is a reinscription on the same satoshi, so the inscriptions form a version history. The method has two types of keys. The Bitcoin UTXO key controls the satoshi and thus the DID. The DID document keys (Ed25519, X25519, or secp256k1, as Multikey) do authentication and assertion.

Strengths:

• Simple identifier model: one integer (the satoshi ordinal) is the full method-specific ID
• The DID document keys are independent of the Bitcoin control key, so you can rotate them and keep the same satoshi
• The inscription history is permanent and immutable on Bitcoin
• The Multikey format supports more than one cryptographic suite

Considerations:

• Each create, update, and deactivate operation needs a Bitcoin inscription transaction
• Resolution depends on how the ord indexer orders inscriptions. A change to the ord rules can change resolution results.
• All DID data is permanently public on-chain. You cannot erase a mistake. You can only replace it with a later version.
• If you lose the UTXO private key, you lose control of the DID. The specification puts UTXO recovery out of scope.
• The change from v0.1.0 to v0.2.0 removed the name and decimal identifier formats. This incompatible change shows that the specification can still change.

did:dht

Status: Implementer's Draft (DID DHT Method Specification 1.0, last updated July 2024). The repository has no commits after November 2024 (as of September 2026).

did:dht stores DID documents on the Mainline DHT, the distributed hash table of BitTorrent. It encodes DID documents as DNS resource records (RFC 1035). Each did:dht comes from an Ed25519 key pair: the DID suffix is the public key in z-base-32 format. TBD, a unit of Block, created the specification. In November 2024, Block announced the closure of TBD. The repositories are now in the Decentralized Identity Foundation (DIF) GitHub organization.

The DHT stores DID documents as BEP 44 signed mutable items. The did:dht specification cites a 15-year track record for Mainline and an estimated 10 million servers. Records can expire after about 2 hours, so somebody must publish them again. Gateway servers can do this for controllers. A controller earns this retention with a proof-of-work retention challenge. Gateways also give historical resolution, indexes by type, and discovery.

Bitcoin has an optional, secondary role. A gateway can use a Bitcoin block hash as the input for a retention challenge. Gateways can also register on Bitcoin with timelock transactions and an OP_RETURN output, for decentralized gateway discovery. The did:dht method does not use Bitcoin to anchor DIDs.

Strengths:

• DID creation and updates at zero cost: no transaction fees and no blockchain interaction
• Uses the large Mainline network that already operates, so there is no new network to start
• Deterministic fallback: a resolver can always expand a did:dht into a minimal DID document from the DID itself
• Interoperable with did:key and did:jwk for Ed25519 keys
• SDKs in six languages, but all six SDK repositories have no commits after 2024 (as of September 2026)

Considerations:

• The Identity Key (Ed25519) is also the DHT address, so you cannot rotate it. If the key is compromised, you must move to a new DID.
• Records expire in about 2 hours if nobody publishes them again and no gateway keeps them
• The BEP 44 payload limit of 1000 bytes limits the size of the DID document
• All data on Mainline is public. There is no mechanism for private DID documents.
• Bitcoin integration is only for gateway discovery and retention challenges. Bitcoin does not give immutability for the DID data.

The Companion Specifications

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

Verifiable Credentials Data Model (v2.0)

Status: W3C Recommendation (May 2025). This specification defines the data model for tamper-evident digital credentials. It defines how issuers, holders, and verifiers structure, secure, and verify credentials. Version 2.0 recognizes two classes of mechanisms to secure credentials:

• Proofs that envelop the credential, for example JOSE and COSE (which include JWT-secured credentials)
• Proofs that are embedded in the credential (Data Integrity)

The specification also describes zero-knowledge proofs and selective disclosure.

Verifiable Presentations

The VC Data Model specification defines Verifiable Presentations. They are not in a separate document. A holder uses a Verifiable Presentation to disclose information from one or more credentials to a verifier. A presentation can combine credentials from different issuers and can contain additional data. Thus the holder can share only the relevant data, not the full credentials.

DID Resolution (v1.0)

Status: W3C Candidate Recommendation Draft (28 August 2026), not yet a Recommendation. This specification defines the algorithms to resolve a DID into its DID document and to dereference DID URLs to specific resources. It covers input options, output metadata, and errors. It also covers resolver architectures (for example proxied resolution through local and remote bindings) and resolution over HTTP(S). Each DID method specification defines the steps to communicate with its verifiable data registry.

DIDComm Messaging (v2.1)

Status: DIF Working Group Approved. DIDComm is a protocol for secure, private, and encrypted communication between DIDs. The Decentralized Identity Foundation publishes it. DIDComm defines plaintext message formats, encryption and signature mechanisms, and the route of a message through intermediaries. It is also a base for higher-level protocols on channels where each party authenticates with a DID.

Available Tools

Method-Specific Libraries

• did:ion: ion-tools (JavaScript/TypeScript) to create, update, and resolve ION DIDs. The last commit is from July 2023 (as of September 2026).
• did:btcr2: the did-btcr2-js monorepo with ten packages:
  • the method core, a BIP340 cryptosuite, key pairs, and a key manager (KMS)
  • Bitcoin RPC and Esplora clients, and an SMT implementation
  • Aggregate Beacon coordination (cohort formation, MuSig2 sessions, and pluggable transports)
  • shared utilities, a high-level SDK, and a CLI
• did:dht: client SDKs from the former TBD Web5 project in Go, TypeScript, Kotlin, Swift, Dart, and Rust. A reference gateway server in Go is in the did-dht repository.
• did:btco: the DIF Labs labs-ordinals-plus repository has the BTCO DID Method and BTCO DID Linked Resources specifications. Resolution uses the ord reference client.

Cross-Method Libraries

• did-resolver: a TypeScript library with a common interface to resolve DIDs. Packages for each DID method plug into it.
• did-jwt / did-jwt-vc: create and verify JWTs, and Verifiable Credentials in JWT format, with DIDs

Infrastructure

• Bitcoin Core: the reference full node. The bitcoin.org full node guide describes the setup on Windows, macOS, and Linux. For did:btcr2, the specification RECOMMENDS an indexed Bitcoin RPC service such as electrs or Esplora. It also allows a resolver to traverse all blocks from the genesis block.
• DIF Universal Resolver: a resolver for many DID methods, with dozens of pluggable drivers. DIF hosts an instance for tests.
• did:dht gateways: servers that publish DHT records again, give historical resolution, and support DID discovery by type
• ION nodes: a stack of Bitcoin Core, IPFS, and Sidetree services that you can host yourself for ION resolution. Note: the ION repository has no maintenance after mid-2023.

Conclusion

The W3C DID standard is a vendor-neutral foundation for decentralized identity. The companion specifications (Verifiable Credentials v2.0, DID Resolution, DIDComm) continue to mature with it. The Bitcoin DID methods are at different stages. ION and did:btcr reached production or draft status, but they show little development in recent years. The did:btc and did:btco methods put all DID data on-chain, and their specifications are at an early stage. The did:dht method has a complete Implementer's Draft and SDKs, but its development stopped in late 2024.

As of September 2026, did:btcr2 shows active development, with a private sidecar model and aggregated beacons.

Each method has different tradeoffs between cost, privacy, speed of resolution, data availability, and infrastructure requirements. No single method is the correct choice for every use case. The standards layer is stable enough to use as a base. The method layer is still in development, and practice will show which designs last.