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 "an open, public, permissionless Layer 2 Decentralized Identifier network that runs atop the Bitcoin blockchain". The decentralized identity team of Microsoft launched ION on Bitcoin mainnet in March 2021. ION implements the Sidetree protocol, a specification of the Decentralized Identity Foundation (DIF). The Sidetree spec lists editors and contributors from Microsoft, Transmute, SecureKey, Consensys, and Mattr. ION uses Sidetree to put many DID operations into one Bitcoin anchor transaction.

The commercial path of ION changed in December 2023, when Microsoft removed did:ion as a trust system option in Entra Verified ID. The same release note says that "The only trust system available is did:web". The open-source ION code is a project of the Decentralized Identity Foundation (DIF) and is in the DIF GitHub organization. The ION FAQ says that Microsoft "has been an important sustaining sponsor, but no more than that". The ION architecture and its design tradeoffs are still a useful example of how a DID layer can use Bitcoin for settlement.

The Sidetree Protocol

Sidetree is a protocol to create scalable DID networks on top of other anchor systems, for example Bitcoin. Its status is "DIF Ratified Specification" (version 1.0.1). It defines four operations:

  • Create: Make a DID with an initial operation.
  • Update: Change a DID document (rotate keys, add services, change endpoints).
  • Recover: Recover a DID with a separate recovery key. Each recovery sets a new recovery commitment.
  • Deactivate: Deactivate a DID permanently.

The main idea is that Sidetree does not need one transaction for each DID operation. Instead, it puts many operations into one anchor transaction. The MAX_OPERATION_COUNT parameter sets the maximum number of operations in one batch. Its suggested default value in Sidetree v1.0.1 is 10,000 operations.

How ION Uses Bitcoin

The architecture has three layers:

1. Bitcoin Layer

ION writes an anchor string into an OP_RETURN output of a Bitcoin transaction (ION design). The Sidetree spec defines the anchor string as the operation count, a ., and the IPFS CID of the Core Index File (for example 10000.QmWd5PH...). ION puts the prefix ion: in front (ION configuration). Thus, the full OP_RETURN value has the form ion:10000.QmWd5PH.... ION does not store identity data on-chain. It stores a small commitment that points to off-chain data.

One anchor transaction can commit to up to 10,000 operations (ION design). Thus, ION divides one Bitcoin fee across many DIDs. The cost for each operation is the transaction fee divided by the number of operations in the batch.

2. Content-Addressable Storage Layer

The operation data is in IPFS (InterPlanetary File System). This data contains Sidetree Patch Actions that tell how the DID document changes, and operation metadata. Examples of patch actions are add-public-keys, remove-public-keys, add-services, remove-services, replace, and ietf-json-patch for RFC 6902 patches. The data is in several Sidetree files: the Core Index File, the Provisional Index File, the proof files, and the Chunk Files. The Bitcoin anchor refers to the Core Index File by its CID, and resolvers follow references from there to the other files. Anyone with the CID can get and verify the data independently.

3. Resolution Layer

ION nodes observe the Bitcoin blockchain, read anchor transactions, get the related data from IPFS, and calculate the current state of each DID. Resolution is deterministic: with the same chain data and IPFS content, each node gets the same state (Sidetree introduction).

Key Technical Properties

  • No special tokens: ION uses Bitcoin directly. ION has no token of its own and no trusted validators (DIF ION page). You pay Bitcoin transaction fees and nothing more.
  • No additional consensus: ION does not run its own consensus mechanism. It uses the consensus of Bitcoin directly (ION README).
  • Permissionless: Anyone can create a DID, run a node, or anchor operations. There is no registration authority (ION README).
  • Deterministic resolution: A DID resolution needs no trusted third party (Sidetree abstract). Any node that observed the Bitcoin chain and got the IPFS data can resolve DIDs independently.

DID Operations in Practice

To create an ION DID, you do these steps:

  1. Generate key pairs (a signing key, an update key, and a recovery key).
  2. Make an initial DID document with public keys and service endpoints.
  3. Send the create operation to an ION node.

The node then puts the operation in a batch with other operations and anchors the batch to Bitcoin.

The DID has the form did:ion:EiD3.... The prefix Ei is not a brand name. It is the base64url encoding of the multihash header (0x12 0x20) for a 32-byte SHA-256 hash. Sidetree uses these multihash values for DID suffixes and commitments (Default Parameters).

ION DIDs have two forms:

  • Long-form (did:ion:Ei...:eyJk...): This form adds a base64url-encoded JSON payload to the DID. The payload contains the delta of the create operation (DID document patches and the next update commitment). It also contains the suffixData (the delta hash and the next recovery commitment). Sidetree §Long-Form DID URIs says that this form is "self-certifying and self-resolving". You can use it immediately, before Bitcoin anchors the create operation, because the DID string contains the full initial state.
  • Short-form (did:ion:Ei...): This form contains only the suffix. A resolver can resolve it only after Bitcoin anchors the create operation and an ION node indexes it.

Updates follow a similar pattern. Each update reveals the value for the previous update commitment and sets a new commitment. Thus, the state changes of each DID make a hash-linked chain.

Limitations and Considerations

  • Latency for short-form DIDs: A resolver can resolve a short-form ION DID only after the anchor transaction has a confirmation. Bitcoin targets one block every 10 minutes on average (nPowTargetSpacing in Bitcoin Core), and stronger finality needs more confirmations. Long-form DIDs remove this delay for the initial state. After publication, both forms resolve to the anchored state, so the initial state in a long-form DID does not show later updates (Long-Form DID URIs).
  • IPFS dependency: If the off-chain operation data becomes unavailable, nobody can resolve the affected short-form DIDs until someone pins the data again. Your own IPFS node reduces this risk. If you use a public gateway, you depend on its operator.
  • Node operation cost: An ION node runs Bitcoin Core, Kubo (IPFS), and MongoDB. The ION install guide recommends an i5 processor (2017 or newer), 6 GB of RAM, and 1 TB of storage. If you run your own node, you do not depend on a third party to resolve DIDs.
  • A smaller ecosystem: Microsoft was an important sponsor of ION, and it removed did:ion from Entra Verified ID in December 2023. As of September 2026, the ION repository has no commits after August 2023. The DIF Universal Resolver test instance still resolves did:ion DIDs through a mainnet ION node that Danube Tech operates. Thus, ION has less commercial support than it had before 2024.

Conclusion

ION is a useful case study of a Sidetree-style Layer 2 that settles on Bitcoin. It has a small on-chain anchor, a larger off-chain operation log on IPFS, and deterministic resolution that any node can replay. The architecture shows that Bitcoin can be a settlement layer for non-monetary state commitments, with only one small on-chain commitment for each batch.

The tradeoffs are real: the latency of Bitcoin confirmations, the dependency on IPFS data availability, and the operational cost of nodes. The general situation also changed. After Microsoft moved to did:web, ION does not have the commercial support that it had before. If you evaluate a Bitcoin-anchored DID approach today, ION is more useful as a reference design than as a default choice.

Jintek LLC