Introduction
One of the sharpest criticisms of blockchain-based identity has always been cost. If creating an identifier requires a transaction, and transactions cost fees, the system can't scale to billions of identities. did:btcr2 addresses this directly: DID creation happens entirely offline, at zero cost, with no Bitcoin transaction required.
How the Original BTCR Handled Creation
In the original did:btcr method, creating a DID required broadcasting a Bitcoin transaction. The identifier was a TxRef (BIP-136) — an encoded reference to the transaction's position in the chain (network magic code, block height, transaction index, with an optional outpoint index) — which meant the DID string only existed after the transaction was confirmed. This design had three consequences:
- Minimum cost of one Bitcoin transaction fee per DID
- Latency of at least one block confirmation before the DID existed
- Dependency on network access and a funded wallet just to create an identifier
For individual use, this was manageable. For issuing identities at organizational scale — employee credentials, IoT device identities, customer DIDs — the costs and friction compounded quickly.
btcr2's Offline Creation Model
btcr2 decouples creation from the blockchain entirely. There are two creation paths:
Key-Based DIDs (Deterministic)
Generate a secp256k1 key pair. Per the DID-BTCR2 Identifier Encoding algorithm, the DID is deterministically derived from the public key:
- Take the 33-byte compressed SEC-encoded public key (SEC 1 §2.3.3)
- Prepend a single byte that packs a 4-bit spec version nibble and a 4-bit network nibble (e.g.
bitcoin,signet,testnet4) - Encode the result using Bech32m (BIP-350) with the human-readable prefix
k
The result is a DID like did:btcr2:k1... that is globally unique, cryptographically bound to your key pair, and instantly usable. No transaction, no fee, no waiting.
Document-Based DIDs (External)
For cases where the DID needs to be bound to an initial document rather than a single key:
- Construct the genesis DID document (containing multiple keys, services, etc.)
- Canonicalize it with JCS (RFC 8785) and hash the result with SHA-256 to produce 32 bytes
- Prepend the same version/network byte and encode using Bech32m with the prefix
x
This produces a did:btcr2:x1... identifier that is bound to the content of the genesis document rather than a single key.
Why Bech32m?
The choice of Bech32m encoding isn't arbitrary. It's the same encoding Bitcoin uses for Taproot (P2TR) addresses, which means:
- Error detection — Bech32m includes a checksum that catches transcription errors, important for identifiers that humans might type or copy.
- Case handling — Per BIP-173, encoders MUST emit all-lowercase, but the whole string MAY be uppercased for QR codes (QR's alphanumeric mode only supports uppercase and encodes it more compactly). Mixed case is invalid. The practical effect: a Bech32m identifier always appears lowercase in text, with an unambiguous uppercase form available for QR scanning.
- Ecosystem alignment — Bitcoin wallets and libraries already understand Bech32m. Using the same encoding for DIDs means less new code and more familiar patterns.
When Does Bitcoin Enter the Picture?
Bitcoin is used for updates, not creation. When a DID controller needs to rotate keys, add service endpoints, or modify their DID document, they anchor that update to Bitcoin through the beacon system. This means:
- Identity exists before any on-chain activity — A DID is valid and resolvable (from its genesis state) the moment it's created.
- On-chain costs are deferred and optional — If you never update your DID, you never pay a transaction fee.
- Costs are amortized when updates happen — Through
CASBeaconandSMTBeaconservices, a single Bitcoin transaction can commit to updates for many DIDs — via a hash of a shared announcement map (CAS) or a Sparse Merkle Tree root (SMT).
What This Enables
Mass Issuance
An organization can issue thousands of DIDs — for employees, devices, or digital assets — without touching the blockchain. Each DID is immediately usable for receiving and presenting Verifiable Credentials.
Ephemeral and Pairwise DIDs
Because creation is free, there's no economic barrier to creating a unique DID for each relationship. Pairwise DIDs prevent correlation across contexts — a core privacy requirement that's impractical when every DID costs a transaction fee.
Offline-First Identity
A device in a disconnected environment can create a DID, build a DID document, and begin using it locally. When connectivity is restored, updates can be anchored to Bitcoin. The identity doesn't depend on network access to exist.
Developer Experience
For developers building on btcr2, the creation path is straightforward: generate keys, encode, done. No wallet setup, no testnet faucets, no transaction construction just to get an identifier. The barrier to entry for experimentation and prototyping drops dramatically.
The Tradeoff
Zero-cost creation means the genesis state of a DID isn't anchored to Bitcoin. An unupdated DID's security rests on the holder's key management, not on blockchain immutability. The moment an update is anchored, the DID gains Bitcoin's security guarantees for its history from that point forward. This is a deliberate design choice — pay for security only when you need it, rather than front-loading costs.
Conclusion
By making DID creation a purely offline, zero-cost operation, btcr2 removes the biggest scalability barrier for Bitcoin-based identity. Identifiers are instant, free, and cryptographically bound to their controller from the moment of creation. Bitcoin's role shifts from gatekeeper to guarantor — securing the history of DIDs that need it, without taxing the creation of DIDs that don't yet.