Brrq: A Hash-First Execution Layer for Bitcoin

Version: 0.1.0 Website: https://brrq.net Contact: brrq@brrq.net Source: https://github.com/brrq-net/brrq

Abstract

We propose Brrq, a Bitcoin Layer 2 execution environment built on a Hash-First Architecture (HFA) in which every cryptographic layer is designed around hash functions rather than elliptic curves. Existing Bitcoin L2 solutions — Lightning, Liquid, Stacks, Citrea, BOB — all depend on elliptic curve assumptions (ECDSA, Schnorr, BN254) that are vulnerable to Shor's algorithm on a sufficiently powerful quantum computer. Brrq structures its protocol across five cryptographic layers — signatures, proofs, state, fraud detection, and settlement — such that at launch two layers operate on pure hash functions (ZK-STARKs and SHA-256 Merkle trees), two have a hash-based path available (SLH-DSA signatures and equivocation detection), and the remaining layer (settlement) uses a transitional SNARK wrapper with three independent removal paths. The protocol employs BTC as its sole collateral and fee currency with no governance token, uses a BitVM2 bridge for trustless deposits and withdrawals, and enforces structural fairness through nine mathematical mechanisms against centralization.

1. Introduction

Bitcoin [1] processes approximately seven transactions per second with limited programmability beyond its native Script language. This throughput limitation has driven the development of Layer 2 (L2) solutions: Lightning Network for payment channels [2], Liquid as a federated sidechain with Simplicity smart contracts [3][48], Stacks with its Clarity smart contracts [4], Citrea as a ZK rollup [5], and BOB using the OP Stack [6].

All of these systems share a common structural property: their cryptographic foundations depend on elliptic curve assumptions. Lightning and Liquid use ECDSA and Schnorr signatures on secp256k1. Stacks relies on ECDSA for transaction signing. Citrea uses RISC Zero with Groth16 proofs over BN254. BOB inherits Ethereum's ECDSA infrastructure. These assumptions — specifically the hardness of the Elliptic Curve Discrete Logarithm Problem — are known to be solvable in polynomial time by Shor's algorithm [7] given a sufficiently large quantum computer.

The timeline for such a computer remains uncertain but is accelerating. As of early 2026, IBM's Condor processor contains 1,121 physical qubits, Quantinuum's Helios system has demonstrated 48 error-corrected logical qubits [8], and Gidney's 2025 paper reduced the estimated resources for breaking RSA-2048 by 95% [9]. Breaking secp256k1 requires approximately 2,000-2,500 logical qubits, equivalent to 10^5 to 10^6 physical qubits — an 8-20 year horizon with 17-34% probability by 2034 according to the Global Risk Institute [10]. Google's Willow processor [44] and Microsoft and Atom Computing's 24 entangled logical qubit demonstration [45] suggest the gap is closing faster than earlier estimates predicted, while IonQ targets 1,600 logical qubits by 2028 [49].

Hash functions face a fundamentally different threat model. Grover's algorithm [11] provides only a quadratic speedup against hash functions, degrading 256-bit security to an effective 128 bits — a level that remains computationally infeasible.

We present Brrq, the first Bitcoin L2 designed from day one around what we call a Hash-First Architecture: every cryptographic component is built on hash functions or has a defined migration path to hash-based alternatives. This single design decision yields four natural properties:

1. Quantum resistance through hash-based cryptographic primitives across all protocol layers
2. Trustless bridging via BitVM2 [12] with permissionless verification on Bitcoin L1
3. BTC-native economics with no governance token — Bitcoin is the sole collateral and fee currency
4. Structural fairness through nine mathematical mechanisms that bound centralization

2. Hash-First Architecture

We define the Hash-First Architecture (HFA) as a protocol design in which every cryptographic operation relies solely on the security of hash functions — no elliptic curve assumptions, no algebraic group structure, and no trusted setup.

The protocol is structured into five cryptographic layers:

+--------------------+  +--------------------+  +------------------------+
| Layer 1            |  | Layer 2            |  | Layer 3                |
| SIGNATURES         |  | PROOFS             |  | STATE DATA             |
| SLH-DSA (FIPS 205) |  | ZK-STARKs (FRI)    |  | SHA-256 Merkle Trees   |
| Hash-based         |  | Hash-based         |  | Hash-based             |
+--------------------+  +--------------------+  +------------------------+

+------------------------+  +------------------------------------+
| Layer 4                |  | Layer 5                            |
| FRAUD DETECTION        |  | SETTLEMENT                         |
| SLH-DSA Equivocation   |  | STARK Verifier in BitVM (target)   |
| Hash-based             |  | Groth16 SNARK wrap (transitional)  |
+------------------------+  +------------------------------------+

At launch, Layers 2 and 3 operate on pure hash functions. Layers 1 and 4 have a hash-based path available (SLH-DSA is implemented alongside the default Schnorr signatures). Layer 5 uses a transitional SNARK wrapper — the internal proof is a hash-based STARK, but it is wrapped in a ~300-byte SNARK (Groth16 over BN254) for efficient on-chain verification. Three independent paths exist for removing this wrapper: (a) a native STARK verifier implemented in Bitcoin Script via BitVM2 sub-programs [36], (b) maturation of quantum-resistant SNARK constructions (lattice-based or hash-based), and (c) a Bitcoin soft fork enabling OP_CAT for direct STARK verification. Any single path suffices.

The security argument for hash functions is straightforward. Shor's algorithm breaks the discrete logarithm problem underlying all elliptic curve cryptography — rendering ECDSA, Schnorr, and pairing-based systems (BN254, BLS12-381) completely insecure. Grover's algorithm, by contrast, provides only a square-root speedup against hash pre-image search, degrading SHA-256 from 256-bit to 128-bit effective security. A system built on hash functions degrades gracefully under quantum attack rather than catastrophically.

3. Transactions and Signatures

Brrq offers two signature schemes operating in parallel:

SLH-DSA (formerly SPHINCS+) is a stateless hash-based signature scheme standardized by NIST in 2024 [13][31]. Hardware acceleration techniques using SHA-NI and AVX2 instructions can improve SLH-DSA performance by 10-100x [35]. It constructs signatures entirely from Merkle trees and hash function evaluations — no elliptic curves, no lattice assumptions. The choice of SLH-DSA over alternatives is constrained:

• ML-DSA-65 (Dilithium) offers smaller signatures (3,309 bytes) but is built on lattice assumptions, violating the Hash-First Architecture.
• XMSS [32] and LMS [33] are hash-based and compact (~1.5-2.5 KB) but are stateful — reusing a one-time signature index breaks security entirely. In a decentralized environment where wallets may be replicated across devices, stateful schemes are unacceptable.
• SLH-DSA-SHA2-128s is the only scheme that satisfies all three requirements: hash-based (HFA-compliant), stateless (safe under replication), and standardized (FIPS 205). The Open Quantum Safe project provides reference implementations [34], and the choice between 128s (small, slower) and 128f (fast, larger) parameter sets is analyzed in [40].

The transition from Schnorr to SLH-DSA follows a milestone-driven schedule rather than fixed calendar dates: Stage 1 (launch) makes SLH-DSA available as a user-selectable option; Stage 2 (triggered by concrete quantum hardware advances) makes SLH-DSA the default for new wallets; Stage 3 (triggered by an imminent quantum threat) makes SLH-DSA mandatory for all new transactions.

On L2, Brrq uses an account model rather than Bitcoin's UTXO model, as it better supports stateful smart contracts. Each account consists of a 20-byte address derived from SHA-256 of the public key, a balance denominated in brqBTC (1:1 pegged to BTC), a nonce for replay protection, a code hash (for contract accounts), and a storage root (Merkle root of contract state).

4. Execution Environment

Transactions on Brrq are executed within a zero-knowledge virtual machine (zkVM) implementing the RISC-V RV32IM instruction set — a 32-bit base integer ISA with the multiplication extension. The choice of RISC-V is motivated by its adoption across production zkVMs: SP1 Hypercube (Succinct) [14], R0VM 2.0 (RISC Zero) [15], and Airbender (ZKsync) [16]. An alternative approach using binary fields (Binius [37]) is under consideration for future optimization. The VM provides 64 MB of addressable memory in a Harvard-style architecture where code is read-only.

Gas metering is tied directly to the cost of generating a STARK proof for each operation, ensuring that fees reflect actual computational burden rather than arbitrary units:

The execution engine implements what we call Bifurcated State Logging to eliminate free-riding denial-of-service attacks. Every transaction's effects are internally divided into intrinsic changes (gas payment and nonce update) and execution changes (contract state modifications). If a transaction fails during execution — due to gas exhaustion, a revert, or a runtime error — the execution changes are rolled back but the intrinsic changes are committed. This guarantees that an attacker cannot consume sequencer resources without paying the full economic cost of gas, eliminating costless mempool spam.

5. Proof System

Brrq generates validity proofs using ZK-STARKs (Zero-Knowledge Scalable Transparent Arguments of Knowledge) [17]. The construction, building on the SP1 prover architecture [14], proceeds as follows:

1. Execution trace: The zkVM records every state transition during transaction execution as a 152-column trace table (76 base execution columns plus auxiliary columns for bitwise operations, memory permutations, and cross-table arguments) over the BabyBear prime field (p = 2^31 - 2^27 + 1). Base columns capture the program counter, general-purpose registers, memory operations, ALU results, and control flags.

2. Algebraic Intermediate Representation (AIR): Polynomial constraints encode the correctness rules — each valid state transition satisfies a set of low-degree polynomial equations over the trace columns. Invalid execution violates at least one constraint.

3. FRI commitment: The trace polynomials are committed using the Fast Reed-Solomon Interactive Oracle Proof (FRI) protocol [18], which reduces polynomial evaluation claims to Merkle tree path checks. Domain-separated SHA-256 commitments provide 128-bit security via 64 FRI queries.

4. Fiat-Shamir transform: Interactive verifier challenges are replaced by domain-keyed SHA-256 hashes of the transcript, producing a non-interactive proof. Poseidon2 [20] is used for FRI commitment Merkle trees in the SNARK wrapping layer, not for Fiat-Shamir challenges.

The protocol uses a dual hash system optimized for different contexts:

• SHA-256 for all L1-facing data: state roots registered on Bitcoin, inclusion proofs, and bridge commitments. This provides compatibility with Bitcoin's native hash function and benefits from SHA-NI hardware acceleration.
• Poseidon2 [20] for zkVM-internal computations: state trees within smart contracts and proof transcript hashing. Poseidon2 is an algebraic hash function (not an elliptic curve construction) that is significantly more efficient than SHA-256 inside arithmetic circuits. Its security degrades under Grover's algorithm identically to SHA-256 — it remains HFA-compliant. Ongoing cryptanalysis efforts [42][43] have not found practical attacks on Poseidon2, though its shorter track record relative to SHA-256 motivates its restriction to internal-only use.

Recursive proof aggregation [39] combines multiple batch proofs into a single composite proof, reducing L1 settlement frequency from approximately 20 per hour to 1-3 per hour — a 7-20x reduction in on-chain cost.

The transitional SNARK wrapping compresses a STARK proof (10-100 KB) into a ~300-byte SNARK for efficient Bitcoin L1 verification. Importantly, the internal proof is always a hash-based STARK; only the final L1 verification step relies on the BN254 curve. This wrapping is explicitly temporary, with three independent removal paths defined in Section 2.

6. Data Availability

Brrq employs a dual data availability model:

L1 anchoring: Each batch posts less than 400 bytes to Bitcoin: a 32-byte state root (SHA-256 Merkle root [38] of the full L2 state), a ~300-byte wrapped SNARK proof, and a 32-byte batch fingerprint. This is sufficient to verify correctness and prove account balances.

Full node network: Complete state diffs and compressed transaction data are maintained by the network of full nodes. Sequencers are required to store and serve this data as a precondition for consensus participation — failure to provide data availability disqualifies a sequencer from earning rewards. Provers require full transaction data to generate STARK proofs, creating a natural economic incentive for data retention.

Light clients can verify their balances by requesting a Merkle inclusion proof (~1 KB) and checking it against the state root anchored on Bitcoin L1. This requires no trust in any L2 participant — only trust in Bitcoin's own consensus.

DAS integration is a research direction for enhanced data availability. A hybrid on-chain/off-chain DA model (volition) as proposed by StarkWare [47] is another viable direction.

7. Bridge

The Brrq bridge enables trustless transfer of BTC between Bitcoin L1 and the Brrq L2, producing a 1:1 pegged asset called brqBTC.

7.1 BitVM2

The bridge uses BitVM2 [12], which reduces the challenge-response dispute protocol to three on-chain transactions (compared to dozens in BitVM1), limits the on-chain footprint to less than 4 MB, and enables permissionless challenging — any observer can submit a dispute, not just a designated set. Early implementations of BitVM2 bridges include Bitlayer's mainnet beta [28] and Citrea's Clementine design [46]. The GOAT Network BitVM2 whitepaper [29] and Fidelity Digital Assets' analysis [30] provide additional context on bridge economics and trust assumptions.

7.2 Deposits (Peg-in)

A user deposits BTC by sending it to a Taproot address encumbered with BitVM2 conditions. After six L1 confirmations, the deposit is verified by a Zero-Trust SPV Enclave embedded in the consensus engine. No sequencer can mint brqBTC without a cryptographic proof derived directly from Bitcoin block headers — the sequencer submits a synthetic deposit transaction, and the bridge manager verifies the existence of a valid SPV Merkle proof before authorizing minting. A dedicated Merkle tree of processed deposits prevents replay attacks. Daily deposit limits provide an additional safety margin against zero-day exploits.

User                          Bitcoin L1                  Brrq L2
  |                              |                          |
  |-- BTC to Taproot address --> |                          |
  |   (BitVM2 conditions)        |                          |
  |                              |-- 6 confirmations -----> |
  |                              |                   [SPV Verification]
  |                              |                   [No mint without]
  |                              |                   [L1 proof      ]
  |                              |                          |
  |<----------- brqBTC minted (1:1) in user's L2 wallet --|

7.3 Withdrawals (Peg-out)

Withdrawal follows a four-step process:

1. The user burns brqBTC on L2 and specifies a Bitcoin destination address.
2. A liquidity operator immediately pays BTC to the user from the operator's own funds.
3. The operator publishes a Kickoff transaction on Bitcoin L1, opening an approximately two-week challenge window.
4. If no valid Disprove transaction is submitted during the challenge period, the operator claims their bond via a Take transaction. If a challenger proves the operator's claim was fraudulent (via a Disprove transaction), the operator forfeits their bond.

Each operator may register up to 4 independent BitVM2 bonds (MAX_BONDS_PER_OPERATOR = 4), each with its own verified_onchain status. This multi-bond architecture isolates disputes — a challenge against one bond does not affect the operator's other bonds. The exposure cap for any single withdrawal is bounded by smallest_bond × 50% (not total bond value), ensuring economic security even when bond values vary. The global verification flag is set only when all of an operator's bonds have been individually verified on-chain.

The trust model requires only a 1-of-N honest assumption among the initial signer committee (for covenant simulation until Bitcoin natively supports covenants) and permits fully permissionless challenging. One honest observer is sufficient to prevent fraud.

7.4 Failure Recovery

If BitVM2 proves unable to achieve the required security guarantees, the bridge can fall back to a federated model with a 12-of-15 threshold — a higher security threshold than Liquid's 11-of-15 [3]. This fallback includes a mandatory sunset timer enforced in code: the federated mode automatically expires, forcing a transition back to permissionless verification when BitVM2 or its successors mature. The fallback is strictly an emergency measure, not a design target. In the worst case, withdrawals are delayed but funds are never lost — user BTC remains locked in UTXOs on Bitcoin L1.

8. Consensus and Slashing

Brrq uses a Proof-of-Stake consensus mechanism with BTC as the sole collateral asset, drawing on Bitcoin staking constructions from Babylon Labs [23][24]. There is no separate staking token.

8.1 Network Roles

Sequencers receive transactions, verify signatures, order them into blocks (produced every 3 seconds), and sign each block. They must lock BTC in a Taproot UTXO on Bitcoin L1 as collateral.

Provers generate STARK proofs for transaction batches. They operate in a competitive market — the fastest valid proof earns the proving reward. No collateral is required. Prover pools allow participants with modest hardware (4 GB GPU VRAM minimum) to contribute collectively.

8.2 Dual Signing

Every sequencer signs each block with two independent signatures:

(a) Schnorr/EOTS (Extractable One-Time Signature): The sequencer derives a deterministic nonce from HMAC-SHA256(sk, "EOTS_NONCE" || height || epoch). If a sequencer equivocates — signing two different blocks at the same height — the two signatures with the same nonce allow anyone to extract the sequencer's private key via sk = (s1 - s2) / (e1 - e2) mod n. The extracted key enables immediate, self-enforcing slashing with no committee or governance vote required.

(b) SLH-DSA equivocation: The sequencer also signs each block with their SLH-DSA key. Two different SLH-DSA signatures at the same block height constitute a mathematical proof of equivocation — verifiable by anyone using only hash function computations. This mechanism is quantum-resistant by construction.

Either mechanism alone provides equivocation detection. Together they provide defense in depth: even if a quantum computer breaks the Schnorr-based EOTS, the SLH-DSA equivocation proof remains valid. The protocol plans to retire EOTS once the SLH-DSA path is fully operational, achieving pure hash-based fraud detection.

8.3 Key Isolation

Each sequencer maintains three cryptographically independent keys to limit exposure:

• main_key (Schnorr, secp256k1): Identity key that controls the main UTXO holding 66.67% of the sequencer's stake. Never used for block signing.
• eots_key (EOTS, secp256k1): Signs blocks for EOTS equivocation detection. Controls the bond UTXO holding 33.33% of the stake. Derived deterministically from the epoch seed and rotated every epoch — old keys are destroyed.
• slh_dsa_key (SLH-DSA, FIPS 205): Signs blocks for hash-based equivocation detection. Quantum-resistant. Never exposed even under equivocation (SLH-DSA does not have the extractability property of EOTS).

This isolation ensures that equivocation exposes at most the bond UTXO (33.33%), not the full stake.

8.4 Graduated Slashing

Slashed funds are distributed: 70% burned, 20% to the challenger who detected the offense, 10% to the community fund. The challenger reward creates a positive economic incentive for network monitoring.

The slashing mechanism is formally verified through model checking, ensuring that equivocation is always attributable and no honest validator can be falsely slashed. Core safety properties — including uniqueness of finalization at each height, finalization stability, and quorum requirements — are verified alongside slashing completeness.

Additionally, the simulation framework includes Byzantine fault injection testing that intercepts messages from designated Byzantine nodes and applies mutation strategies including equivocation, liveness attacks, timeout testing, verification testing, and replay protection testing. This enables systematic Byzantine fault injection testing across the full consensus pipeline.

8.5 Effective Stake Cap

To prevent plutocratic control, voting power (effective stake) is bounded by a sublinear function:

f(s) = s                        if s <= Cap
f(s) = Cap + sqrt(s - Cap)      if s > Cap

where Cap = 3 * TWAP_30d(median(active_stakes)) is a dynamic threshold calculated as three times the 30-day time-weighted average price of the median active stake. Under this formula, a sequencer with 500 BTC in a network where the cap is 100 BTC has an effective stake of only 120 BTC — a 76% reduction in influence. Meanwhile, a small sequencer with 15 BTC retains their full 15 BTC effective stake.

Leader election is weighted by effective stake using rejection sampling to ensure unbiased selection.

8.6 Time Protection and Secure Unbonding

The protocol does not rely on local system clocks to avoid fork-inducing time disagreements. Instead, block timestamps must exceed the Median Time Past (MTP) of the previous 11 blocks, with a bounded future drift allowance — following Bitcoin's own MTP rule. This deterministic time model ensures that STARK proofs can be generated without depending on non-deterministic external inputs.

Stake withdrawal follows a mandatory 28-day unbonding period. This duration is deliberately set to exceed the BitVM2 challenge period (approximately 14 days) by a factor of two, ensuring that a sequencer cannot initiate unbonding and escape with their stake before a pending fraud challenge can be resolved.

8.7 Liveness Recovery (U-ZKHR)

Standard L2 protocols face a fundamental paradox: if 34% of validators halt the network, no new blocks can be produced through which to remove the halted validators. Brrq resolves this with the Unbonded Zero-Knowledge Liveness Recovery (U-ZKHR) protocol:

1. Bitcoin as clock: If 144 Bitcoin blocks (~24 hours) pass with no new L2 block registered on L1, a liveness fault is declared. Bitcoin L1 serves as an unforgeable external clock that cannot be halted.

2. L1 anchor transaction: A coalition holding >50% of the remaining effective stake publishes an L1ZklaAnchor transaction (OP_RETURN, ~300 bytes) containing: (a) the last agreed L2 state root, (b) public keys of non-producing sequencers, (c) a STARK proof that these sequencers failed to produce blocks during the 144-block window, and (d) signatures from the >50% coalition.

3. Force unbond: L2 nodes that observe the anchor transaction verify the STARK proof and signatures, then execute a forced unbond of the non-producing sequencers. The quorum is recalculated over the remaining set. Crucially, no funds are slashed — downtime is not proof of malice (it could result from an eclipse attack isolating honest nodes). Unbonded funds enter the standard 28-day withdrawal queue.

8.8 Game-Theoretic Analysis

Honest sequencing is a Nash equilibrium under the protocol's incentive structure:

The penalty for equivocation (33.33% bond loss) exceeds any realistic profit from double-spending, and the 20% challenger reward ensures that monitoring is economically rational.

9. MEV Protection

Maximal Extractable Value (MEV) — profit extracted by reordering, inserting, or censoring transactions — is a structural problem in most L2 systems where the sequencer sees transaction contents before ordering them.

Brrq implements a Commit-Reveal scheme similar in spirit to Shutter Network's encrypted mempool [25] and Chainlink's Fair Sequencing Services [26], but using an epoch key derived entirely from hash functions:

1. Commit phase: Each transaction is submitted as an encrypted envelope via MevEncryptor, a production-safe wrapper that uses a monotonic NonceCounter (format: node_id[8] || counter_be[8]) to guarantee nonce uniqueness across blocks and epochs. The transaction kind (transfer, contract call, deposit, withdrawal) is encrypted using SHA-256 in counter mode (CTR) with the epoch key. Transaction metadata — sender address, gas price, and nonce — remains in cleartext to allow ordering. The sequencer orders transactions by gas price without knowing their contents. The MevEncryptor supports state recovery after node restart via new_recovering(node_id, last_block_in_epoch, max_txs_per_block).

2. Lock: The ordering is cryptographically committed and cannot be changed.

3. Reveal phase: The sequencer publishes the epoch key, all transactions are decrypted, and execution proceeds in the committed order.

Epoch key distribution uses Shamir Secret Sharing: at each epoch transition, the epoch key is split into shares and distributed to validators via ShareDistribution network messages. Each message contains the epoch number, share index, 32-byte share data, recipient address, sender address, and a cryptographic signature. Receiving nodes collect shares in a PendingShares accumulator; once the threshold is reached, the epoch key is reconstructed automatically. Shares from non-validators or wrong epochs are rejected.

The epoch key is derived deterministically from the epoch seed: epoch_key = tagged_hash("BRRQ_EPOCH_KEY", epoch_seed || epoch_number). No intermediaries or elliptic curves are involved — the entire scheme uses SHA-256, maintaining HFA compliance. The use of authenticated encryption rather than AES or ChaCha20 is deliberate: it keeps the protocol's cryptographic surface area to a single well-studied primitive.

Within each batch, transactions are ordered by a deterministic hash: order = SHA-256(tx_data || block_hash), which produces a pseudo-random ordering that no party can predict or manipulate. Recent work on batched threshold encryption [27] suggests further improvements to commit-reveal schemes that may be incorporated in future protocol versions.

10. Governance and Structural Fairness

10.1 Immutable Laws

Three constitutional laws are enforced automatically by a DoctrineFirewall — a filter implemented at the node level that rejects violating proposals before they reach a vote:

1. Key sovereignty: No entity — including sequencers, operators, and developers — may access or block user private keys.
2. Hash-First Architecture: No new elliptic curve primitives may be introduced as permanent replacements in the protocol's cryptographic stack.
3. Unconditional exit right: Every user's right to withdraw brqBTC to Bitcoin L1 via the bridge may never be suspended or delayed by any governance vote, protocol update, or declared emergency.

Any proposal that violates these laws is auto-rejected with a logged reason. No vote threshold can override them.

10.2 Three-Chamber Governance

Governance decisions require approval from up to three chambers depending on the decision type:

Sequencer Chamber: Every registered sequencer with locked BTC. Votes are weighted by effective stake (after the square-root cap). Approval threshold: 67% of total effective stake.

User Chamber: Any user meeting triple Sybil resistance criteria: at least 10 real transactions in the past 90 days, a minimum balance of 0.01 BTC maintained during voting, and an account age of at least 60 days. Votes are weighted by the square root of the user's balance in satoshis — a form of quadratic voting that limits the influence of large holders. Approval threshold: 51% of participating votes. The User Chamber holds absolute veto power over proposals affecting consensus or bridge parameters.

Technical Council: Seven elected members — three security auditors, two core protocol developers, and two cryptographers — nominated by the Sequencer Chamber and confirmed by 67% of the User Chamber. Terms are six months, non-consecutively renewable, with a maximum of one member per organization. The Council holds a security veto (30-day pause for audit) and must produce a mandatory technical report before voting begins on any technical or constitutional proposal. The Council cannot propose legislation.

10.3 Rage Quit

During any time-lock period, users may execute a Rage Quit — withdrawing their full brqBTC balance to Bitcoin L1 in protest. Rage Quit withdrawals are fee-exempt and processed with highest priority. If cumulative Rage Quit withdrawals exceed 33% of total brqBTC supply, the triggering proposal is automatically cancelled (VetoedByExodus). Time-lock durations are set to at least twice the BitVM2 challenge period (~28 days) to ensure users have sufficient time to exit.

10.4 Nine Mechanisms Against Centralization

The protocol enforces structural fairness through nine protocol-level mechanisms, each implemented in code rather than social norms:

1. Effective stake cap (square-root function above dynamic threshold)
2. Three-chamber governance (sequencers, users, and technical council)
3. Triple Sybil resistance (activity, balance, and account age requirements)
4. Elected covenant committee (9 members with geographic and institutional diversity constraints)
5. Delegated staking (small holders participate without running infrastructure)
6. Progressive fee schedule (larger transactions pay proportionally higher protocol fees)
7. Temporal fairness (no early-mover advantage — reputation considers only the last 6 months)
8. Geographic fairness (no more than 33% of sequencers from any single geographic region)
9. Guaranteed exit rights (28-day unbonding period; unconditional withdrawal at any time)

11. Incentives

The total fee for each transaction is: TotalFee = BaseFee + PriorityFee + ProtocolFee.

The base fee follows an EIP-1559-adapted mechanism [22]: it increases by up to 12.5% when blocks exceed 50% gas utilization and decreases symmetrically when below. Base fees are burned — reducing the circulating brqBTC supply — with a cumulative burn cap of 5% of initial supply and a per-epoch rate limit of 0.1% to prevent deflationary spirals. Once caps are reached, excess burns redirect to the protocol treasury.

The priority fee (tip) is paid to the block-producing sequencer. The protocol fee is a fixed 10% share of each transaction's fee, allocated as: 40% development and maintenance, 25% security fund (audits and bug bounties), 20% ecosystem fund (developer grants and education), and 15% emergency reserve.

No governance token exists. BTC, in the form of brqBTC, is the sole currency for all fees, collateral, and staking. Target transaction costs are 100-400 satoshis for Schnorr-signed transfers and 400-1,000 satoshis for SLH-DSA-signed transfers. Brrq does not aim to be the cheapest Bitcoin L2 — Lightning is cheaper for simple payments — but rather the most structurally secure.

12. Security Analysis

12.1 Threat Model

We assume an attacker with the following capabilities:

12.2 Protected Objectives

1. Fund safety: It must be impossible to mint brqBTC without a corresponding BTC deposit or to steal existing brqBTC balances.
2. State integrity: No invalid state transition can be registered on Bitcoin L1.
3. Censorship resistance: Any valid transaction must be included within a bounded time period.
4. Exit guarantee: A user must always be able to withdraw their BTC from L2, even if the L2 network halts entirely.

12.3 Quantum Security Assessment

Brrq directly controls five cryptographic layers. At launch, two layers are pure hash-based, two have hash-based alternatives available, and one is transitional. The design target is 5/5 hash-based — achievable through any one of the three SNARK wrapper removal paths.

12.4 Bridge Security

The Zero-Trust SPV Enclave ensures that no brqBTC can be minted without a valid Bitcoin block header proof. The BitVM2 dispute game ensures that fraudulent withdrawals are caught by any honest observer within the challenge period. In the worst case (complete L2 failure), user BTC remains locked in UTXOs on Bitcoin L1 — delayed but never lost.

13. Conclusion

Brrq introduces Hash-First Architecture as a design principle for Bitcoin Layer 2 systems: the systematic construction of every protocol layer around hash function security. This approach provides a natural path to quantum resistance without requiring a complete protocol redesign when quantum computers become practical. The dual signing mechanism (EOTS + SLH-DSA) provides defense-in-depth fraud detection, the BitVM2 bridge enables trustless operation, the absence of a governance token aligns economic incentives with Bitcoin's ethos, and nine mathematical mechanisms enforce structural fairness against centralization.

Research Directions:

• Native STARK verification in Bitcoin Script: A complete STARK verifier within BitVM2's computational model would eliminate the SNARK wrapping layer entirely.
• Data Availability Sampling: DAS integration would strengthen data availability guarantees across the full node network.
• Solidity-to-Rust transpilation: A source-level transpiler would enable Ethereum developers to deploy existing Solidity contracts on Brrq's RISC-V zkVM, broadening the developer ecosystem.
• Privacy: Zero-knowledge proofs for transaction privacy, allowing users to transact without revealing amounts or counterparties on the public L2 state.

References

Post-Quantum Cryptography

[1] S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System," 2008.

[2] J. Poon and T. Dryja, "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments," 2016.

[3] Blockstream, "Liquid Network Technical Overview," 2018. Updated: Simplicity Smart Contracts Launch, July 2025.

[4] Stacks Foundation, "Stacks: A Bitcoin Layer for Smart Contracts — Nakamoto Upgrade and sBTC," 2024.

[5] Citrea, "Bitcoin's First ZK Rollup — Mainnet Launch," January 2026.

[6] BOB (Build on Bitcoin), "BOB Documentation — OP Stack Hybrid L2," 2025.

[7] P. W. Shor, "Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer," SIAM Journal on Computing, vol. 26, no. 5, pp. 1484-1509, 1997.

[8] Quantinuum, "Helios: 48 Error-Corrected Logical Qubits," November 2025.

[9] C. Gidney, "How to Factor 2048-bit RSA Integers with Less Than a Million Noisy Qubits," arXiv:2505.15917, 2025. (Supersedes the 2019 estimate of 20 million qubits.)

[10] Global Risk Institute, "Quantum Threat Timeline: 17-34% Probability of Cryptographically Relevant Quantum Computer by 2034," 2024.

[11] L. K. Grover, "A Fast Quantum Mechanical Algorithm for Database Search," Proceedings of the 28th Annual ACM Symposium on Theory of Computing, pp. 212-219, 1996.

[12] R. Linus, "BitVM2: Permissionless Verification on Bitcoin," 2024.

[13] NIST, "FIPS 205 — Stateless Hash-Based Digital Signature Standard (SLH-DSA)," 2024.

Zero-Knowledge Proofs

[14] Succinct Labs, "SP1 Hypercube: Multilinear Polynomial Proof System," 2025-2026.

[15] RISC Zero, "R0VM 2.0: 47x Speedup for Ethereum Block Proving," 2025.

[16] ZKsync, "Airbender: 21.8M cycles/sec Open-Source RISC-V zkVM," 2026.

[17] E. Ben-Sasson, I. Bentov, Y. Horesh, and M. Riabzev, "Scalable Zero Knowledge with No Trusted Setup," Advances in Cryptology — CRYPTO 2019.

[18] E. Ben-Sasson, I. Bentov, Y. Horesh, and M. Riabzev, "Fast Reed-Solomon Interactive Oracle Proofs of Proximity," Proceedings of the 45th ICALP, 2018.

[19] L. Grassi, D. Khovratovich, C. Rechberger, A. Roy, and M. Schofnegger, "Poseidon: A New Hash Function for Zero-Knowledge Proof Systems," USENIX Security Symposium, 2021.

[20] L. Grassi, D. Khovratovich, and M. Schofnegger, "Poseidon2: A Faster Version of the Poseidon Hash Function," AFRICACRYPT, 2023.

Data Availability

[21] Celestia, "Blob Economics and Data Availability Costs," 2024.

Ethereum Fee Market

[22] V. Buterin, E. Conner, R. Dudley, M. Slipper, I. Norden, and A. Bakhta, "EIP-1559: Fee Market Change for ETH 1.0 Chain," 2019.

Proof of Stake and Bitcoin Staking

[23] Babylon Labs, "Bitcoin Staking Protocol Specification," 2024.

[24] Babylon Labs, "Bitcoin Staking Scripts (Taproot) and EOTS," 2024.

MEV Protection

[25] Shutter Network, "Threshold Encrypted Mempool on Gnosis Chain," Live July 2024.

[26] Chainlink, "Fair Sequencing Services (FSS)," 2021.

[27] BEAST-MEV, "Batched Threshold Encryption," ePrint 2025/1419.

Competitive Analysis

[28] Bitlayer, "BitVM Bridge Mainnet Beta," July 2025.

[29] GOAT Network, "BitVM2 Whitepaper 1.0," 2024.

[30] Fidelity Digital Assets, "Overview of BitVM," 2025.

Hash Architecture and Cryptographic Foundations

[31] NIST, "Post-Quantum Cryptography Standardization Process — Final Standards," 2024.

[32] RFC 8391, "XMSS: eXtended Merkle Signature Scheme," 2018.

[33] RFC 8554, "Leighton-Micali Hash-Based Signatures (LMS)," 2019.

[34] Open Quantum Safe Project, "liboqs SLH-DSA Implementation," 2024.

[35] conduition.io, "Making SLH-DSA 10x-100x Faster with SHA-NI, AVX2, and GPU Acceleration," 2025.

[36] StarkWare and Bitcoin Wildlife Sanctuary, "ColliderVM and Circle STARK Verifier for Bitcoin Script," 2025.

Implementation Techniques

[37] B. Diamond and J. Posen, "Binius: Efficient Proofs over Binary Fields," 2024.

[38] R. Dahlberg, T. Pulls, and R. Peeters, "Efficient Sparse Merkle Trees: Caching Strategies and Secure (Non-)Membership Proofs," ePrint 2016/683, 2016.

[39] B. Bunz, A. Chiesa, P. Mishra, and N. Spooner, "Recursive Proof Composition from Accumulation Schemes," TCC 2020, ePrint 2020/499.

[40] NIST, "FIPS 205 — Stateless Hash-Based Digital Signature Standard," Section 10: Parameter Sets, 2024.

Recent Research (2025-2026)

[41] StarkWare, "Stwo Prover (Circle STARK, Mersenne Prime Field)," 2025.

[42] L. Grassi et al., "Poseidon and Neptune: Groebner Basis Cryptanalysis," IACR ToSC, 2025.

[43] Ethereum Foundation, "Poseidon Cryptanalysis Initiative," 2024-2026.

[44] Google Quantum AI, "Willow: Below Surface Code Threshold," Nature, 2025.

[45] Microsoft and Atom Computing, "24 Entangled Logical Qubits (Computation on 28 Logical Qubits)," 2025.

[46] Citrea, "R&D for Clementine v2: Garbled SNARK Verifiers + TOOP," 2025.

[47] StarkWare, "Volition: Hybrid Data Availability," 2024.

[48] Blockstream, "Simplicity Smart Contracts Launch on Liquid," July 2025.

[49] IonQ, "1,600 Logical Qubits by 2028 Roadmap," 2025.