BitLooper: Post-Quantum Money with
Protocol-Level Account Safety

1. Introduction
2. Background and related work
3. System and threat model
4. Design
5. Security analysis
6. Implementation
7. Evaluation
8. Limitations
9. Scaling roadmap
10. Conclusion

1. Introduction

Bitcoin [1] showed that a monetary system can operate without a trusted issuer. Two problems remain for ordinary holders. First, nearly all deployed chains authenticate spending with elliptic-curve signatures, which Shor's algorithm [6] breaks given a sufficiently large fault-tolerant quantum computer. Published resource estimates for such attacks have fallen substantially in recent years. Second, possession of a key is equivalent to ownership. A lost key permanently destroys funds, and a stolen key or a single deceived approval transfers them irreversibly. Existing mitigations either return custody to intermediaries, or implement recovery in wallet-specific contracts whose guarantees depend on that code rather than on the protocol.

BitLooper treats both as protocol problems. Our contributions are:

1. A payment protocol using only post-quantum signatures and hashes, with algorithm identifiers in addresses for later migration (§4.1).
2. Account-safety rules in the state-transition function: vaults, guardian recovery and inheritance, including the rule that weakening an account's protection is itself delayed (§4.2), with stated bounds on what a key thief can take (§5.2).
3. A consensus configuration without a randomness beacon, combining deterministic stake-weighted rotation with correlated slashing, so that safety violations are fully penalised (§4.3, §5.1).
4. A fixed-supply monetary rule with an explicit conservation invariant and fee recycling, analysed without assuming it solves long-run security funding (§4.4).
5. An open implementation and a local evaluation with measured transaction sizes, fault behaviour, pruning and checkpoint synchronisation (§6, §7).

None of the individual components is new: BFT consensus, post-quantum signatures, social recovery and vault designs all have precedents (§2). The contribution is combining them at protocol level into one system, with an honest accounting of costs and assumptions.

2. Background and Related Work

Post-quantum signatures. NIST standardised ML-DSA (FIPS 204), a module-lattice scheme, and SLH-DSA (FIPS 205), a stateless hash-based scheme, in 2024 [2–4]. FN-DSA (Falcon) is being standardised. These schemes have much larger keys and signatures than elliptic-curve schemes (Table 1).

Post-quantum ledgers. QRL uses the stateful hash-based XMSS scheme. Algorand added Falcon-based state proofs and accounts. Ethereum and Bitcoin have post-quantum migration research and draft proposals (e.g. BIP-360 [10]). Unlike systems migrating from elliptic curves, BitLooper starts without them.

Consensus. Tendermint [5] provides BFT agreement with finality under partial synchrony and fewer than one-third Byzantine voting weight. CometBFT's light-client specification introduced a trusting period shorter than the unbonding period [9], which we adopt. Ethereum's proof-of-stake applies correlation penalties that grow with the number of simultaneous offenders; our rule follows the same principle.

Account safety. Smart-contract wallets offer guardian-based social recovery and spending limits, and account-abstraction standards generalise them. Bitcoin vault proposals (e.g. OP_VAULT, BIP-345) add delayed withdrawals with a recovery path. BitLooper provides these properties natively, so every wallet and every node enforce the same rules.

3. System and Threat Model

Participants. Accounts hold balances and are controlled by a key. Validators bond stake and vote on blocks. Full nodes verify every block. Guardians, cancellers and heirs are ordinary accounts named in another account's safety settings.

Network. Partial synchrony: after an unknown global stabilisation time, messages between honest validators arrive within a bounded delay.

Adversary. The adversary may (a) control validators holding less than one-third of voting weight; (b) possess a large quantum computer; (c) obtain the signing key of any user account, for example by stealing a device; (d) deceive a user into signing a transaction; (e) corrupt guardians below an account's threshold; (f) mount denial-of-service attacks on known leaders.

Assumptions. (A1) ML-DSA, SLH-DSA, SHA3-256 and SHA-256 resist classical and quantum attackers as currently believed. (A2) Honest validators hold more than two-thirds of voting weight. (A3) A node starting from a snapshot is given a genuine checkpoint within the trusting period. (A4) The implementation is correct. Account-safety guarantees additionally assume that the owner, a guardian or the canceller observes pending actions within the configured delay, and that the cancel key is not compromised together with the account key.

4. Design

4.1 Accounts and transactions

An address commits to an algorithm identifier and a public key:

The public key is recorded in state on an account's first transaction; later transactions carry only a signature. Guardian recovery (§4.2) can replace the recorded key while the address stays the same. People read and type an address as Bech32m text with the prefix blpr (tblpr on test networks), whose checksum detects any error in up to four characters, so a mistyped address is refused rather than paid. A transaction contains a format version, the sender, chain identifier, nonce, action, maximum base fee, tip, algorithm identifier, optional public key, signature, and an optional sponsor with a second signature over the same bytes. A sponsor pays the fee and tip, which lets a merchant make payments free for customers. Every signature covers the chain identifier and the hash of the genesis block, so a signature made for one network is worthless on any other, even one with the same name. A transaction's identifier is the hash of its signed content without the signatures; the signatures are committed separately, so nodes can drop them after finality and still prove the rest. An account can register one name (3 to 20 letters and digits, first come first served, with a fee to the reserve that is higher for short names); wallets turn "pay @name" into the address before signing.

4.2 Safe accounts

An account may carry a safety record S = (G, k, d_r, ℓ, d_v, c, H, τ): guardians G with threshold k, recovery delay d_r, vault limit ℓ per rolling 24-hour window, vault delay d_v, canceller c, heirs H with shares summing to 100%, and inactivity period τ. All delays are at most 90 days.

4.3 Consensus

Validators bond stake; the active set holds up to 100 validators (ceiling 150) and is recomputed each epoch. Epochs are fixed spans of time, because blocks are not produced when idle. At an epoch change at most a third of the set's weight can be added and at most a third displaced, and a newcomer replaces the weakest member of a full set only with more than 10% more stake. With at least 20 members no key may exceed 5% of weight (with 4 to 19, a third). Agreement follows Algorithm 1 of [5]: propose, prevote, precommit, with locking, valid-value re-proposal, round skipping on one-third of weight and growing timeouts. A block is final when precommits from more than two-thirds of weight are collected.

A commit-reveal randomness beacon considered earlier was rejected: the last revealer can evaluate both outcomes and choose. Instead, each epoch every node builds the same smooth weighted round-robin schedule over normalised weights, in an order shuffled with the hash of the previous epoch's last block, and

Correlated slashing. For validators holding total weight share F that equivocate within one epoch, each loses (F is taken from each validator's weight when it equivocated, so leaving the set does not lower it)

and is jailed; it cannot unbond until the epoch-long fault window ends. Unbonding takes 21 days. Downtime: a validator whose signatures are credited for at most 5% of the blocks it had to sign over a window of 10,000 blocks loses 0.1% of its bond and leaves the set at the next epoch. Validators persist their last signed vote before signing, and re-broadcast it after a restart rather than signing anew. Precommits that arrive after the first two-thirds are added to the certificate carried by the next block, and a precommit left out of it is still credited if any of the next ten blocks carries it. Otherwise honest but slightly slower validators, or validators a proposer chose to leave out, would lose uptime credit and rewards; an early version of our implementation showed exactly this.

4.4 Monetary policy

Let C be circulating coins (balances, stake, unbonding and held pending transfers) and R the unissued reserve. Every block must satisfy

Genesis assigns 80% to R, 15% to a retroactive airdrop and 5% to a foundation vesting over 48 months. No coins are sold. A block with timestamp gap Δt (capped at 10 minutes) issues

shared in proportion to weight by the whole set that had to sign the previous block: a validator whose signature is missing is not paid, and its share stays in R. 5% of it pays the proposer, in proportion to the signature weight it includes beyond two-thirds. Issuance is scaled down when more than 50% of C is staked. The base fee per byte adjusts by at most 12.5% per block towards half-full blocks, rises by at least one unit after a block above that target, never falls below 10 units, and is returned to R. A transaction that creates an account pays 0.001 coin more, and issuing an asset 10 coins, also returned to R. Tips go to the proposer. Returning fees smooths income but creates no revenue: R changes at rate (fees − λR). Without fees, rewards decay towards zero, and a recycled fee is paid out over a half-life of ln2/λ ≈ 23 years. Long-run security therefore depends on fee demand and on the coin's value.

4.5 Storage

Blocks are produced only when there are transactions, evidence or due actions, with a heartbeat at least every 10 minutes on mainnet (30 s on test networks); an idle block still carries one post-quantum signature per validator, so the heartbeat sets the storage floor. Everything hashed or signed uses one binary encoding. The block header commits separately to transactions, their signatures, evidence, the state, the validator sets and the commit certificates, and has a version, a rules version for upgrades scheduled by height, and a slot reserved for validity proofs. The state is committed to by sparse Merkle trees, so a block re-hashes only the entries it changes, and a phone that has verified a header can check its balance with a proof instead of trusting a node. Nodes that keep history store blocks outside their window without signatures, about 90 times smaller, plus the certificate of each epoch's last block. Nodes save a complete snapshot (every account, key, pending action, recovery and validator) every 500 blocks, and prune full blocks outside their retention window: 2 days for ordinary nodes, 22 days for validators, so equivocation evidence outlives the 21-day unbonding period. A new node may start from a snapshot only if its header hash equals an operator-supplied trusted checkpoint and its contents hash to that header's state root.

5. Security Analysis

We give informal arguments. Formal verification is future work.

5.1 Consensus

Safety and liveness. Under A2 and partial synchrony, the properties of [5] carry over: no two conflicting blocks are finalised at the same height, and blocks keep being finalised after stabilisation. Deterministic rotation does not affect safety. A leader under denial-of-service attack causes a round timeout, and the next slot proposes.

Accountability. Suppose two conflicting blocks are finalised at one height. Their certificates each carry more than two-thirds of weight, so validators with at least one-third of weight signed both, and each such pair of signatures is evidence. By (3) with F ≥ 1/3, each offender loses its entire bond, provided the evidence is included within the unbonding period. The 22-day retention by validators is designed to make that possible.

Validity. Full nodes re-execute every transaction and check (4). A certificate cannot make an invalid state transition acceptable to them.

5.2 Account safety

Proposition 1 (vault bound). Under Rules V and D, an adversary holding only an account's key can move out immediately at most ℓ per 24-hour window. Every other outflow, including any attempt to change the safety record, is delayed by at least d_v and can be cancelled by an honest canceller or guardian.

Argument. Immediate outflow happens only through Rule V's first branch, which is capped at ℓ per window. Removing the vault requires a new safety record, which Rule D delays. Recovery, which the adversary cannot start without guardians, cancels pending transfers on execution. ∎

Proposition 2 (recovery). If at least k guardians are honest and available, and neither the owner's key nor c is used to cancel, a lost key is replaced after d_r. If fewer than k guardians collude, they cannot change the key. If k or more collude, they must wait d_r, during which c can cancel (A's current key only before approvals reach k).

Limitation. One guardian can replace a pending proposal and so reset approvals, which delays recovery without completing one. A guardian whose recovery c stopped must wait d_r before trying again. Coercion that lasts longer than the delays is not prevented.

5.3 Quantum adversary

Under A1, signatures resist forgery, and Grover's algorithm leaves 256-bit hashes at about 128-bit security. Because no elliptic-curve key is ever published, there is no data to harvest now and break later. The exposed components are external. For example, the Bitcoin side of an atomic swap stays protected only by Bitcoin's own signatures.

6. Implementation

The reference node bitlooper is about 3,800 lines of Rust (tests included), built on the fips204/fips205 crates, SHA3, tokio and axum. Its modules are: cryptography; transaction and block types with canonical encodings; the state-transition function; consensus with a persistent double-sign guard and vote re-gossip; length-prefixed JSON peer-to-peer transport; block, snapshot and pruning storage; an HTTP API; and a command-line wallet. Ten unit tests cover transfers with key storage, sponsored fees, vault delay and cancellation, delayed safety changes, guardian recovery, inheritance, block tampering and correlated slashing.

7. Evaluation

Setup. Four validators (ML-DSA-65) and one faucet account, run as separate processes on one Apple M1 laptop over the loopback network, with 2 s target block time. This setup measures correctness and message sizes, not wide-area performance.

Projected ceilings. With a 1 MB transaction-data limit per 2 s block and 2,632-byte transfers, capacity is about 190 transfers per second at full blocks, and 95 at the fee target. Full blocks plus 100-signature certificates would add about 21 TB of complete history per year. Ordinary nodes retaining 2 days would need about 70–115 GB plus state. These are calculated ceilings, not measurements.

8. Limitations

• Evaluation scope. No wide-area, sustained-load or adversarial-network measurements yet. No independent audit.
• Key splitting. One owner can run many validator keys. The 5% cap limits accidental concentration only, and when a few keys hold most of the stake it raises the weight share of every other key.
• Known leaders. The rotation is known once an epoch starts (the shuffle seed is the previous epoch's last block, which its proposer can influence slightly), which still exposes upcoming proposers to targeted denial of service.
• State growth. Each account stores its public key (~1.4 KB with ML-DSA-44), and pruning does not reduce current state.
• Cryptographic agility. Dual-family accounts, which require both lattice and hash-based signatures, are needed so that funds are protected before a break. They are not built yet.
• Atomic swaps. Hash time-locked swaps with Bitcoin and Ethereum are built and tested on local test networks but not audited. Their Bitcoin and Ethereum legs rely on those chains' elliptic-curve signatures.
• Not yet built. Private payments and vote aggregation. A second, independent client is in progress. Foundation and airdrop vesting exist only as genesis vesting schedules.
• Checkpoint trust. Snapshot sync trusts the chosen checkpoint within its trusting period. It does not re-verify prior history.
• Economics. Fee recycling does not guarantee adequate long-run validator income. Security depends on demand and on the coin's price, which this paper does not predict.

Status. Everything in §7 runs in the reference implementation today. §9 is a research direction.

9. Scaling Roadmap

A billion users making five payments a day require about 57,900 transfers per second on average. We set 100,000 as a long-term target, with bursts specified as a maximum settlement delay. At today's transfer size, that workload would produce about 4.7 PB per year, and a billion accounts would hold about 1.4 TB of keys. The base chain alone cannot carry this.

The direction under study is parallel lanes whose batches are verified by validity proofs settled on the base chain, with signatures checked inside the proofs. Before any lane holds value, we require the following:

• Each lane must be small enough to be re-executed on ordinary hardware.
• Two independently built proof systems must agree.
• Recovery data must be published through a post-quantum data-availability layer (hash-based commitments, not KZG).
• Anyone must be able to take over a failed lane, and users must be able to force transactions in through the base chain.
• Wallets must distinguish "accepted" from "final".

Published experiments already prove ML-DSA inside STARKs, so neither signature family is assumed cheaper to prove. The next step is an end-to-end benchmark of one lane, reporting settled throughput, 95th-percentile settlement time, cost per payment, proof size and memory, node requirements and recovery time. No lane capacity is claimed until those measurements exist.

10. Conclusion

BitLooper combines post-quantum authentication with protocol-level protection against the everyday ways people lose money: theft, lost keys and death. It does so without custodians, admin keys or a token sale, and with a supply fixed by an invariant every node enforces. The cost is larger transactions, and the paper quantifies it rather than hiding it. The reference implementation and local results show the design works end to end. Audits, wide-area measurements and the remaining components listed in §8 must come before any value is placed on it.

References

1. S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.
2. NIST. FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. 2024.
3. NIST. FIPS 204: Module-Lattice-Based Digital Signature Standard. 2024.
4. NIST. FIPS 205: Stateless Hash-Based Digital Signature Standard. 2024.
5. E. Buchman, J. Kwon, Z. Milosevic. The latest gossip on BFT consensus. arXiv:1807.04938, 2018.
6. P. W. Shor. Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer. SIAM J. Computing, 1997.
7. L. K. Grover. A fast quantum mechanical algorithm for database search. STOC, 1996.
8. E. Ben-Sasson et al. Scalable, transparent, and post-quantum secure computational integrity. IACR ePrint 2018/046.
9. CometBFT light-client and evidence specifications.
10. Bitcoin Improvement Proposals 65 (CHECKLOCKTIMEVERIFY), 345 (OP_VAULT, draft) and 360 (draft).
11. V. Buterin et al. EIP-1559: Fee market change for ETH 1.0 chain. 2019.