Introduction
Decentralized identity (DID) systems promise to return control of personal data to individuals. But not all DID infrastructure is created equal. The system you anchor to determines the trust model you inherit — and every option comes with tradeoffs. Bitcoin's proof-of-work consensus, immutability, and decentralization make it a compelling foundation for certain kinds of identity systems, though it's far from the only viable approach.
Why the Anchor Layer Matters
A DID is only as trustworthy as the system that records its creation and updates. The properties of the underlying layer — ordering, immutability, availability, cost — directly shape what the identity system built on top can and can't do.
Bitcoin offers a combination of properties that are particularly relevant for identity infrastructure:
- Immutability — Once a transaction is confirmed, reversing it requires an economically prohibitive amount of energy. DID operations anchored to Bitcoin benefit from this finality.
- Censorship resistance — No single entity can prevent a DID operation from being included in a block. This matters when identity systems serve people in adversarial environments.
- Decentralization — Bitcoin's mining network is globally distributed. There's no foundation, council, or validator set that can unilaterally change the rules.
- Longevity — Bitcoin has operated continuously since 2009. Identity systems need to outlive the organizations that create them.
What It Costs
Every technology has costs. Bitcoin's are often overstated, but they're real and worth understanding:
Transaction fees fluctuate with network demand. During fee spikes, individual DID operations can become expensive. Batching architectures (used by ION and btcr2) amortize costs across many operations, bringing per-DID costs to fractions of a cent in normal conditions.
Confirmation latency averages around 10 minutes per block. DID updates aren't instant. For many identity use cases this is fine — you don't rotate keys every second — but it's a meaningful constraint compared to systems with sub-second finality.
Full node operation requires storing the full blockchain — currently around 727 GB — and keeping it synced. In practice, the hardware bar is low: a full node needs just 2 GB of RAM and a broadband connection. People run them on Raspberry Pi hardware. Dedicated node products like Umbrel and myNode cost a few hundred dollars and run on modest home hardware with a 1 TB drive.
Energy consumption from proof-of-work mining is Bitcoin's most frequently cited cost. Bitcoin mining consumes an estimated 110 TWh per year — about 0.55% of global electricity production. That's a real number, but context matters:
- Global standby ("vampire") power draw — devices idling in homes and offices — accounts for 5–10% of residential electricity use in the US alone. The IEA has estimated global standby waste at roughly 200–400 TWh annually — several times Bitcoin's total consumption.
- Clothes dryers in the US consume approximately 60 billion kWh (60 TWh) per year, for a single country and a single appliance.
- As of 2025, 52% of Bitcoin mining electricity comes from sustainable sources (Cambridge CCAF), and that share has been trending upward as miners seek the cheapest energy — which is increasingly renewable.
Energy use is a legitimate consideration, but the scale is often overstated relative to other global energy draws.
How Bitcoin-Anchored DIDs Work
Rather than storing full identity documents on-chain (which would be expensive and impractical), Bitcoin-anchored DID systems use a layered approach:
- Batch anchoring — Multiple DID operations can be collected and hashed together into a single Bitcoin transaction. This amortizes cost across many operations.
- Off-chain document management — DID documents and operation data live off-chain. Different methods handle this differently — some use content-addressable storage like IPFS (e.g., ION), while others like did:btcr2 use a sidecar model where the controller provides operation history directly to verifiers as plain JSON.
- Deterministic resolution — Given the same inputs, anyone can replay the chain of operations to independently reconstruct the current state of any DID, without trusting a central authority.
Comparing Anchor Layer Approaches
Different DID base layers optimize for different things.
Proof-of-stake chains offer lower transaction costs and faster finality. For identity operations that need to be cheap and quick, this is a real advantage. The tradeoffs to evaluate:
- Validator concentration — Staking economics can lead to a small number of large validators with outsized influence, though delegation models vary.
- Economic finality — PoS finality depends on economic incentives rather than energy expenditure. Whether this is sufficient depends on your threat model and time horizon.
- Governance flexibility — The ability to change consensus rules through governance is a feature for some use cases and a risk for others. For long-lived identity infrastructure, stability matters.
Non-blockchain approaches like the Mainline DHT (used by BitTorrent) offer yet another set of tradeoffs — high availability, no transaction costs, and no energy overhead, but without the strong ordering and immutability that a blockchain provides. For identity systems where availability and cost matter more than anchored history, DHT-based methods can be a good fit.
Lightweight methods like did:key and did:web avoid the blockchain question entirely. did:key is instant and free (derived from a public key, no ledger), while did:web leverages existing DNS/HTTP infrastructure. Both sacrifice Bitcoin's immutability properties but are perfectly adequate for many use cases.
The right choice depends on what properties your identity system actually needs.
Conclusion
Bitcoin brings real strengths to decentralized identity — immutability, censorship resistance, and a long operational track record. Its costs — fees, latency, and the energy required for proof-of-work — are real but often smaller than commonly assumed, especially for node operation and when mining's energy use is compared to other global energy draws. Other approaches offer different balances. The question isn't which base layer is "best" in the abstract, but which tradeoffs are acceptable for a given use case.