Introduction
Cost is a frequent criticism of blockchain-based identity. If each new identifier needs a transaction, and each transaction has a fee, the system cannot scale to billions of identities. did:btcr2 removes this problem for creation. You create a DID fully offline, at zero cost, and with no Bitcoin transaction (Offline Creation).
Creation in the Original BTCR
In the original did:btcr method, you had to broadcast a Bitcoin transaction to create a DID. The identifier was a TxRef (BIP 136), an encoded reference to the position of the transaction in the chain. A TxRef contains a magic code for the network, a version number, the block height, the transaction index, and an optional outpoint index. Thus, the DID string existed only after the transaction had a confirmation. This design had three consequences:
- Each DID cost at least one Bitcoin transaction fee.
- Each DID needed at least one block confirmation before it existed.
- To create an identifier, you needed network access and a funded wallet.
For individual use, these costs were manageable. For identities at organizational scale (employee credentials, IoT device identities, customer DIDs), the fees and the delays increased quickly.
The Offline Creation Model of btcr2
btcr2 fully separates creation from the blockchain. There are two creation paths:
Key-Based DIDs (Deterministic)
Generate a secp256k1 key pair. The DID-BTCR2 Identifier Encoding algorithm then derives the DID from the public key:
- Take the 33-byte compressed SEC-encoded public key (SEC 1 §2.3.3).
- Put one byte in front of the key. This byte contains a 4-bit spec version and a 4-bit network value (for example
bitcoin,signet, ortestnet4). - Encode the result with Bech32m (BIP 350) and the human-readable prefix
k.
The result is a DID such as did:btcr2:k1.... The DID is globally unique, it is cryptographically bound to your key pair, and you can use it immediately. You do not need a transaction, you pay no fee, and you do not wait.
Document-Based DIDs (External)
Use this path if the DID must be bound to an initial document and not to a single key:
- Make the genesis DID document (for example, with many keys and services). Use the placeholder
did:btcr2:_as its identifier (Genesis Document). - Canonicalize the document with JCS (RFC 8785), then hash the result with SHA-256 to get 32 bytes (JSON Document Hashing).
- Put the same version and network byte in front of the hash. Then encode the result with Bech32m and the prefix
x.
This path gives a did:btcr2:x1... identifier. The identifier is bound to the content of the genesis document, not to a single key.
Why btcr2 Uses Bech32m
The choice of Bech32m has clear reasons. Bitcoin uses the same encoding for Taproot (P2TR) addresses (BIP 350). This gives these properties:
- Error detection: The Bech32m checksum always detects up to 4 substituted characters (BIP 350). This is important for identifiers that people type or copy. Bech32m also fixes an insertion weakness of the original Bech32 checksum.
- Case rules: BIP 173 says that encoders MUST output all-lowercase strings and that decoders MUST NOT accept mixed case. For Bitcoin addresses, BIP 173 lets you use an uppercase form inside QR codes, because the QR alphanumeric mode is more compact. The did:btcr2 spec does not use this option: the method-specific identifier MUST be lowercase (Identifier Decoding). Thus, a btcr2 DID is always lowercase, also inside a QR code.
- Ecosystem alignment: BIP 350 lists reference Bech32m encoders in Python, C, C++, and JavaScript. For example, the reference implementation uses the general Bech32m encoder of the
@scure/baselibrary. Thus, a btcr2 implementation needs less new code.
The Role of Bitcoin: Updates, Not Creation
Bitcoin is for updates, not for creation. A DID controller can rotate keys, add service endpoints, or change the DID document in other ways. To do this, the controller anchors the update to Bitcoin through the Beacon system. The results are:
- The identity exists before any on-chain activity: A DID is valid from the moment of creation, and you can use it offline. A resolver still queries Bitcoin to make sure that no Beacon Signal exists for the DID (Find Beacon Signals).
- On-chain costs are optional and occur later: If you never update your DID, you never pay a transaction fee.
- Updates share costs: With
CASBeaconandSMTBeaconservices, one Bitcoin transaction can commit to updates for many DIDs. The commitment is the hash of a shared Beacon Announcement Map (CAS) or the root of a Sparse Merkle Tree (SMT).
What This Makes Possible
Mass Issuance
An organization can issue thousands of DIDs (for employees, devices, or digital assets) without a Bitcoin transaction. Each DID is immediately ready to receive and present Verifiable Credentials.
Ephemeral and Pairwise DIDs
Creation is free, so there is no economic barrier to a unique DID for each relationship. Pairwise DIDs help prevent correlation across contexts. This privacy property is not practical when each DID costs a transaction fee.
Offline-First Identity
A device in a disconnected environment can create a DID, make a DID document, and start to use the DID locally. The spec says that offline creation "allows unlimited DID creation and use without requiring any on-chain or online interactions" (Offline Creation). When the device has a connection again, the controller can anchor updates to Bitcoin. The identity does not need network access to exist.
Developer Experience
For developers, the btcr2 creation path is simple: generate keys, then encode them. You do not need a wallet, a testnet faucet, or a transaction to get an identifier. Thus, it is easier to start experiments and prototypes.
The Tradeoff
With zero-cost creation, the genesis state of a DID has no Bitcoin anchor. The DID string itself commits to the genesis state, because it contains the public key or the hash of the genesis document. Thus, a resolver can verify the genesis state without Bitcoin. Before the first update, the security of the DID depends on the key management of the controller, not on a Bitcoin anchor. After the controller anchors an update, Bitcoin orders and timestamps the history of the DID from that point. This is a deliberate design choice: the controller pays for an on-chain anchor only when the DID document changes.
Conclusion
btcr2 makes DID creation a fully offline operation at zero cost. This removes a large scalability barrier for Bitcoin-based identity. Identifiers are instant, free, and cryptographically bound to their controller from the moment of creation. The role of Bitcoin changes: Bitcoin does not control creation. It anchors the history of the DIDs that change, and it adds no cost to the creation of the other DIDs.