cBTC Technical Documentation

01 Abstract

Bitcoin's long-term cryptographic security is constrained by two structural facts: exposed public keys remain vulnerable to future quantum attacks, and Bitcoin's base-layer upgrade path is socially and operationally slow. cBTC is a claim-based post-quantum representation of Bitcoin built on Cellframe, a blockchain architecture designed around post-quantum cryptography rather than retrofitted to it.

The protocol starts from a verifiable snapshot of the Bitcoin UTXO set, lets BTC holders prove entitlement, and mints cBTC 1:1 to a post-quantum destination address on a dedicated Cellframe network. The launch scope is intentionally narrow: cBTC is designed to be useful on day one as a claim-first migration environment without requiring a live BTC ↔ cBTC bridge at launch.

This document describes the problem statement, design principles, system architecture, claim model, monetary policy, security boundaries, and phased expansion logic for cBTC. It is a protocol and system document, not a legal offering document or financing term sheet. Selected references and citation notes appear in §18.

02 Scope and Document Boundary

This document covers:

• the cBTC product thesis and protocol design
• the BTC snapshot and claim architecture
• monetary policy, claim windows, and validator incentives
• security assumptions, trust boundaries, and bridge sequencing
• the role of Cellframe as the execution environment for cBTC

This document does not replace:

• investor legal documents such as the SAFE, term sheet, side letter, or commitment letter
• closing workflows, KYC/AML procedures, or issuance paperwork
• deep implementation appendices for advanced privacy claims, hardware devices, or future migration adapters

Companion legal and commercial materials remain separate by design. Investment into the issuer entity is distinct from cBTC as a protocol asset, and cBTC itself is not the fundraising instrument for the seed round.

03 Problem Statement

Bitcoin's quantum risk should not be treated as a single date or a single binary event. It is better understood as a stacked systems problem:

1. Some BTC is already more exposed than the market typically prices in, especially coins linked to reused or otherwise exposed public keys.
2. Even if Bitcoin converges on a post-quantum upgrade path, in-place migration for a globally held asset is slow, politically difficult, and operationally uneven. This is especially relevant for forward-looking proposals such as P2MR, which improve future output structure but do not by themselves migrate already exposed balances ^[R1].
3. Retrofitting post-quantum signatures onto legacy high-value chains creates throughput and fee pressure, especially where signature sizes increase materially ^[R4][R5][R8].
4. Opt-in protection on Bitcoin L1 may help individual holders, but it does not automatically create a shared migration destination, shared liquidity, or a standardized post-quantum operating environment.

cBTC is therefore designed as a parallel migration destination rather than an in-place Bitcoin patch. It gives BTC holders a way to establish a post-quantum parallel position without requiring a sale of BTC, an immediate fork choice, or a wait for Bitcoin Core to complete a production migration ^[R1][R3].

04 Design Principles

The protocol is built around six design principles:

1. Parallel exposure without forced BTC disposition. A holder keeps BTC and claims a parallel cBTC position; the launch flow is a claim, not a swap or sale.
2. Claim-first before bridge-first. The bridge is the highest-risk subsystem and is not required for launch.
3. Separate ledger, not Bitcoin L2. cBTC does not inherit Bitcoin consensus and is not presented as a rollup anchored to Bitcoin.
4. Verifiability over narrative. Snapshot inclusion, claim rules, supply transitions, and post-cut-off policy should be auditable.
5. Security before convertibility. Day-one utility matters, but not at the cost of pretending current Bitcoin-side bridge custody is fully quantum-safe.
6. Controlled monetary policy. cBTC preserves the 21M hard cap while handling unclaimed supply explicitly rather than leaving it as an indefinite overhang.

05 System Overview

At launch, cBTC is a dedicated Cellframe network that stores:

• the canonical aggregated BTC snapshot
• claim state and claim history
• recovery logic and cut-off policy
• the native cBTC asset ledger

The dedicated cBTC network is peered with Backbone, which provides broader liquidity and utility surfaces inside the Cellframe ecosystem. This allows cBTC to circulate in a post-quantum environment before any optional Bitcoin-side bridge is added.

06 What cBTC Is and Is Not

If Bitcoin eventually deploys a credible post-quantum path, cBTC may remain useful as an execution and liquidity environment around PQ-Bitcoin. In the broad economic sense it may function like an execution layer around Bitcoin liquidity, but not as a system that inherits Bitcoin settlement guarantees.

07 Snapshot and Claim Architecture

7.1 Snapshot

The protocol begins from a Bitcoin UTXO snapshot at a pre-announced block height H.

The snapshot process:

1. Parses all UTXOs at height H
2. Aggregates balances by BTC address
3. Builds a Merkle tree over (address, balance) pairs
4. Commits the Merkle root into the genesis of the dedicated cBTC network
5. Publishes the full dataset as open data for independent audit and replication

The result is a hash-verifiable ledger copy of Bitcoin balances at the selected height. cBTC supply is then minted only through protocol-approved claim and post-cut-off issuance logic.

7.2 Claim Methods

Two claim families exist in the protocol design:

• Method A — Signature Claim. A one-time ECDSA signature proves BTC ownership and mints cBTC to a new post-quantum destination address. This is the default launch method and the easiest onboarding path.
• Method B — ZK HD-Seed Claim. A stricter recovery path proves knowledge of the wallet lineage without requiring a public ECDSA signature at claim time. This is the preferred recovery method as the migration window matures and is the basis of the post-cut-off narrow recovery channel.

For launch and core documentation purposes, Method A is the canonical default. Method B is the stricter recovery path. More advanced privacy-preserving variants belong in the appendices because they remain research-heavy and operationally optional.

7.3 Destination Addressing

The claim destination is always a new post-quantum address on the cBTC side.

Two destination forms are supported:

• Bitcoin-style PQ-key-hash address: SHA-256(PQ public key) for users who want Bitcoin-like address expectations
• Cellframe-native address: network-aware addressing with algorithm and routing metadata encoded in the native format

The user-facing claim flow may default to the Bitcoin-style PQ-key-hash presentation while preserving the native Cellframe form as the canonical network address format.

08 Claim Windows and Hard Cut-Off

The claim timeline is intentionally staged.

Window 1 — Fast Claim

• Duration: 90 days from mainnet
• Primary method: Method A
• Goal: lowest-friction migration for the largest share of reachable holders

Window 2 — Recovery Claim

• Duration: from the end of Window 1 until the Hard Cut-Off at T+3 years from mainnet
• Primary method: stricter recovery proofs, centered on Method B
• Goal: continue legitimate migration without keeping the easy ECDSA path open indefinitely

Hard Cut-Off

At T+3 years from mainnet, the standard claim windows close. ECDSA-based claims are no longer accepted. From that point, the protocol can keep only a narrow recovery channel for stricter seed-knowledge proofs if governance explicitly enables it.

The strategic purpose of the Hard Cut-Off is to stop treating unclaimed BTC entitlements as a permanent floating shadow supply that a future quantum attacker could exploit.

09 Monetary Policy

cBTC preserves Bitcoin's 21,000,000 unit hard cap, but it does not copy Bitcoin's halving schedule.

9.1 Supply Model

• Maximum supply: 21,000,000 cBTC
• Genesis allocation: mapped 1:1 to the BTC snapshot at height H
• Team allocation at genesis: none
• Investor allocation at genesis: none
• Treasury allocation at genesis: none

At launch, all unclaimed entitlements remain in a non-circulating claim pool.

9.2 Post-Cut-Off Supply Handling

After the Hard Cut-Off:

• the default path is to burn unclaimed entitlements
• a narrow recovery channel may remain open for stricter post-cut-off proofs
• the delta between the claimed floor and the 21M cap becomes the reserve that funds long-term validator issuance

The current working estimate is that claimed supply may settle materially below 21M, potentially near ~3M, but this should be treated as a planning scenario rather than a deterministic outcome. The scenario is informed by widely cited lost-BTC and inactive-supply estimates used across the cBTC document set ^[R6].

9.3 Long-Term Emission

The reserve is released on a smooth long-horizon curve rather than Bitcoin-style halvings:

• no cliffs
• no periodic halving shock
• validator-oriented emission under protocol governance
• permanent stop once the combined claimed-plus-emitted supply reaches 21M

This design keeps the cap intact while giving the network a sustainable post-claim validator economy.

10 Consensus and Execution Environment

cBTC launches on Cellframe's Proof-of-Stake environment.

Why PoS first:

• faster and more realistic launch path
• lower fees for post-quantum transaction sizes
• better fit for claim processing, utility, and institutional treasury operations
• avoids forcing the product into an early ideological PoW succession debate

Launch target parameters:

• target block time: 30 seconds
• engineering envelope: 12–20 seconds with tighter block-size budgets if justified later
• user-facing finality target: approximately ~90 seconds at the launch target cadence

The protocol does not require a claim that PoS is the only acceptable long-term end state. A later PoW successor remains optional future work if the market eventually demands a Bitcoin-like final form. It is not part of the launch scope.

11 Security Model and Trust Boundaries

This section defines the practical trust model of the system.

11.1 What Is Cryptographically Verified

• inclusion of a BTC address and balance in the canonical snapshot
• one-time claim state per entitlement
• validity of the cBTC destination and mint result
• native cBTC ledger state after issuance

11.2 What Depends on Cellframe Consensus

• ordering and finality of claims on the cBTC network
• validator execution of issuance and burn rules
• governance-approved parameter changes

11.3 What Depends on Governance

• the exact shape of the post-cut-off narrow recovery channel
• the validator emission curve inside the 21M cap
• future algorithm additions and some operational security parameters

11.4 What Does Not Yet Have Full Quantum-Safe Guarantees

Any optional Bitcoin-side bridge remains constrained by Bitcoin's current transaction model. On present Bitcoin, there is no fully trustless and fully quantum-safe bridge design. This is why the bridge is not part of the launch scope and why the launch product is claim-first. Future Bitcoin-side improvements such as P2MR may improve some custody patterns, but they do not remove the present launch-boundary constraint ^[R1].

11.5 Non-Goals at Launch

cBTC does not promise at launch:

• a fully quantum-safe bidirectional Bitcoin bridge
• universal wallet support for advanced privacy proofs
• zero-trust recovery for every edge case
• instant conversion back into legacy BTC

12 Bridge and Exit Paths

The bridge exists to improve optionality, not to define the launch thesis.

The intended phased logic is:

1. no bridge at launch
2. optional inbound-first bridge only after traction and audit
3. optional full two-way bridge only after stronger demand and operating maturity
4. later migration adapter if a canonical PQ-Bitcoin path emerges

The bridge should therefore be read as a sequenced infrastructure module, not as a prerequisite for cBTC to exist or a claim that Bitcoin-side custody has already been solved.

13 Why Cellframe

Cellframe is relevant to cBTC for specific technical reasons:

• it is a production environment designed around post-quantum cryptography
• it supports algorithm agility at the address and transaction level
• it already supports network peering, letting a dedicated cBTC network interoperate with Backbone
• it provides a realistic execution environment for post-quantum signatures without assuming legacy-chain performance

This matters because cBTC is not only a balance-mapping exercise. It is intended to operate in an environment where holders can store, move, and use a post-quantum BTC representation before Bitcoin itself completes that transition.

14 Related Work and Comparative Framing

The cBTC design sits between three broad categories:

1. In-place Bitcoin upgrades such as future script or output-model improvements, including P2MR-oriented discussions ^[R1]
2. Opt-in protection layers on Bitcoin that protect only the holders who use them
3. Separate-ledger migration destinations that provide a new operating environment

cBTC intentionally chooses category three. It does so because the project is not only trying to harden key ownership in theory, but to create a shared migration destination with shared liquidity, shared utility, and explicit monetary-policy handling for unclaimed supply.

This does not imply that the other paths are invalid. It means cBTC is optimized for a different problem: not merely proving that protection is possible, but building a usable post-quantum destination before Bitcoin's own migration path is complete.

15 Roadmap and Open Questions

15.1 Launch Scope

The core launch scope is:

• snapshot finalization
• dedicated cBTC network launch
• Method A claim flow
• native wallet and utility surface
• claim-state verification and cut-off enforcement

15.2 Post-Launch Expansion

Post-launch work may include:

• stricter recovery tooling
• bridge pilots
• hardware-assisted post-quantum key custody
• broader institutional treasury and reporting surfaces

15.3 Open Questions

The following should remain explicit rather than hidden:

• final governance parameters for the narrow post-cut-off recovery channel
• exact validator emission curve parameters inside the 21M cap
• production maturity threshold for advanced privacy-wrapped claims
• future bridge activation criteria and reserve-sizing policy

16 Companion Documents

This document is supported by, but intentionally separate from:

• the deeper implementation-facing specification in cBTC Technical Details
• strategy and rollout material in cBTC Strategic Plan and cBTC Business Page
• bridge-risk materials in cBTC Bridge Options Memo and cBTC Bridge Economics
• investor, legal, and financing documents in the separate terms, SAFE, commitment, side-letter, and signing files

Readers who want implementation depth should move from this document into the technical specification and appendices. Readers who want financing terms should use the separate legal and commercial package rather than infer them from this document.

17 Disclaimers

This document is a system and protocol description. It is not:

• an offer to sell securities
• a SAFE, term sheet, or other investment instrument
• legal, tax, or regulatory advice
• a guarantee of future protocol parameters or market outcomes

All timelines, adoption scenarios, benchmark references, and market-structure outcomes should be treated as forward-looking statements and planning assumptions rather than binding commitments.