ION and Bitcoin: How a DID Layer-2 Anchored Itself to the Chain

May 1, 2026

ION and Bitcoin: How a DID Layer-2 Anchored Itself to the Chain

Introduction

ION (Identity Overlay Network) is a Layer 2 decentralized identifier network that runs on top of Bitcoin. ION itself was primarily built by Microsoft's identity team, and launched on Bitcoin mainnet in March 2021. The underlying Sidetree protocol it implements is a broader DIF collaboration with contributors from Microsoft, ConsenSys, Mattr, and Transmute. ION uses Sidetree to batch many DID operations into a single Bitcoin anchor transaction.

Worth stating up front: ION's commercial trajectory has changed. In December 2023, Microsoft removed did:ion as a trust system option in Entra Verified ID, leaving did:web as the only supported trust system. The open-source ION codebase is now stewarded by the Decentralized Identity Foundation (DIF) rather than Microsoft. The architecture below is still one of the more instructive examples of how a DID layer can ride Bitcoin's settlement guarantees — and the design tradeoffs are worth understanding either way.

What Is the Sidetree Protocol?

Sidetree is a DIF-ratified protocol for creating scalable DID networks on top of existing blockchains. It defines four CRUD operations:

  • Create a DID by publishing an initial operation
  • Update a DID document (rotate keys, add services, change endpoints)
  • Recover a DID using a separate recovery key (with rotating recovery commitments)
  • Deactivate a DID permanently

The key insight is that Sidetree doesn't require one transaction per DID operation. Instead, it batches many operations into a single anchor transaction. The protocol's MAX_OPERATION_COUNT parameter — set to 10,000 operations per batch in the v1.0 default profile — caps how much a single anchor can commit to.

How ION Uses Bitcoin

The architecture has three layers:

1. Bitcoin Layer

ION writes its method marker plus a Sidetree anchor string into an OP_RETURN output of a Bitcoin transaction. Per the Sidetree spec, the anchor string is the operation count joined to the IPFS CID of the Core Index File (e.g., 10000.QmWd5PH...); ION prepends ion: as its method tag, so the full OP_RETURN value looks like ion:10000.QmWd5PH.... It doesn't store identity data on-chain; it stores a tiny commitment that points to off-chain data.

A single anchor transaction can commit to up to 10,000 operations (per Sidetree's MAX_OPERATION_COUNT), which amortizes the Bitcoin fee across many DIDs and brings the per-operation cost down to fractions of a cent.

2. Content-Addressable Storage Layer

The actual operation data — Sidetree Patch Actions describing how the DID document changes (add-public-keys, remove-public-keys, add-services, replace, and an ietf-json-patch escape hatch for RFC 6902), plus operation metadata — lives in IPFS (InterPlanetary File System), spread across Sidetree's Core Index, Provisional Index, and Chunk files. The Bitcoin anchor references the Core Index File by its CID; resolvers walk from there to the rest. Anyone with the CID can retrieve and verify the data independently.

3. Resolution Layer

ION nodes observe the Bitcoin blockchain, read anchor transactions, fetch the corresponding data from IPFS, and reconstruct the current state of every DID. Resolution is deterministic: given the same chain data and IPFS content, every node arrives at the same state.

Key Technical Properties

  • No special tokens — ION uses Bitcoin natively. There's no ION token, no staking, no governance token. You pay Bitcoin transaction fees and that's it.
  • No additional consensus — ION doesn't run its own consensus mechanism. It inherits Bitcoin's consensus directly.
  • Permissionless — Anyone can create a DID, run a node, or anchor operations. There's no registration authority.
  • Deterministic resolution — No trusted third party is needed to resolve a DID. Any node that has observed the Bitcoin chain and fetched the IPFS data can resolve independently.

DID Operations in Practice

Creating an ION DID involves:

  1. Generating key pairs (signing key, update key, recovery key)
  2. Constructing an initial DID document with public keys and service endpoints
  3. Submitting the create operation to an ION node
  4. The node batches it with other operations and anchors to Bitcoin

The resulting DID looks like did:ion:EiD3.... The leading Ei is not branding — it's the base64url-encoded multihash header (0x12 0x20) for a 32-byte SHA-256, which is what Sidetree uses for operation suffixes and commitments.

ION DIDs come in two forms:

  • Long-form (did:ion:Ei...:eyJk...) — appends a base64url-encoded JSON payload containing the create operation's delta (DID document patches and the next update commitment) and suffixData (delta hash and the next recovery commitment). Per Sidetree §Long-Form DID URIs, this makes the DID self-certifying and self-resolving — usable immediately without waiting for Bitcoin anchoring, because everything needed to deterministically reconstruct the initial DID document is in the DID string itself.
  • Short-form (did:ion:Ei...) — the suffix-only form. Resolvable only after the Create operation has been anchored on Bitcoin and indexed by an ION node.

Updates follow a similar pattern but reference the previous operation via rotating commitments, forming a hash-linked chain of state changes for each DID.

Limitations and Considerations

  • Latency for short-form DIDs — A short-form ION DID is only resolvable after the anchoring Bitcoin transaction is confirmed (~10 minutes for one confirmation, longer for stronger finality). Long-form DIDs sidestep this for the genesis state but lose the property once an update lands on chain.
  • IPFS dependency — If the off-chain operation data becomes unavailable, short-form DIDs can't be resolved until the data is re-pinned. Running your own IPFS node mitigates this; relying on a public gateway makes you a dependent.
  • Node operation cost — Running a full ION node requires syncing the Bitcoin blockchain and indexing all ION anchor transactions. Resource-intensive, but it's the only configuration that gives full resolution sovereignty.
  • Ecosystem retrenchment — Microsoft was ION's most visible commercial backer and removed did:ion from Entra Verified ID in December 2023. The protocol and network still operate as a DIF community project, but the practical ecosystem is smaller than it was at peak.

Conclusion

ION is a useful case study in what a Sidetree-style Layer 2 looks like when settled on Bitcoin: a small on-chain anchor, a larger off-chain operation log on IPFS, and deterministic resolution that any node can replay. The architecture demonstrates that Bitcoin can serve as a settlement layer for non-monetary state commitments without bloating the chain.

The tradeoffs are real — Bitcoin-confirmation latency, IPFS data-availability dependency, and operational cost of running nodes. And the broader landscape has shifted: with Microsoft's pivot to did:web, ION is no longer where the commercial weight sits. For projects evaluating a Bitcoin-anchored DID approach today, ION is more interesting as a reference design than as a default destination.

Jintek LLC