Codex32 Comes to Bitcoin Core: The Case for Paper-Based Wallet Backups | Bitcoin Index

Bitcoin custody has always been about eliminating trust. You don’t trust banks, so you hold your own keys. You don’t trust online storage, so you use cold wallets. But here’s the uncomfortable truth: most backup schemes still make you trust electronics.

Your hardware wallet could have compromised firmware. Your computer could leak secrets through electromagnetic side channels. The encrypted file format might become obsolete. Even steel backups usually involve electronic devices at some point in the creation process.

What if you could back up Bitcoin the way Satoshi did: just you, paper, and math?

Enter Codex32, a backup scheme that makes the entire lifecycle computable by hand. No hardware, no software, just pen, paper, and lookup tables. Bitcoin Core pull request #33043 wants to bring this capability to the reference implementation, letting users create paper backups that can be verified, split into shares, and recovered without ever trusting a computer.

What is Codex32?

Codex32 is a checksummed encoding scheme for BIP32 master seeds, specified as BIP-93. It was created by Leon Olsson Curr, Pearlwort Sneed, and Andrew Poelstra (Director of Research at Blockstream), with the BIP formally assigned in February 2023.

A Codex32 string looks like this:

ms10testsxxxxxxxxxxxxxxxxxxxxxxxxxx4nzvca9cmczlw

Breaking it down:

ms = “master seed” (human-readable prefix)
1 = separator
0 = threshold (0 means unshared)
test = 4-character identifier
s = share index (s = the secret itself)
xxxxxxxxxxxxxxxxxxxxxxxxxx = payload (26 characters = 128 bits)
4nzvca9cmczlw = 13-character checksum

It uses the same 32-character alphabet as Bitcoin’s bech32 addresses, making it compact and QR-code friendly.

The magic: hand-computable checksums

Here’s what sets Codex32 apart: the 13-character checksum can be verified using only lookup tables or paper “volvelles” (calculation wheels). No calculator, no computer, no hardware wallet. Just you and a printed worksheet.

It takes 30-60 minutes the first time. With practice, maybe 20 minutes. But you can do it, fully verifying your backup’s integrity without exposing your seed to any electronic device. You can repeat this verification annually, confirming your backup hasn’t degraded, without ever plugging anything in.

As Andrew Poelstra put it:

“By computing with pen and paper, we can be assured that no secret data appears anywhere we did not write it. We can create our own random data in a transparent way. We can choose how long we want to take to do various operations, confounding timing attacks.”

Codex32 natively supports Shamir secret sharing, letting you split a seed into up to 31 shares with configurable thresholds (2-9). A 2-of-3 scheme requires any 2 shares to recover the seed, while possessing only 1 share reveals nothing about the original secret.

Each share has its own checksum. You can verify shares independently, store them in different locations, and recover your wallet from any threshold-sufficient combination.

Error correction

The checksum isn’t just for detection. It can correct up to 4 character substitutions, 8 erasures (unreadable characters), or 13 consecutive errors. If you spill coffee on your backup and a few characters smudge, the scheme can often recover the original value.

It guarantees detection of up to 8 errors, far stronger than BIP39’s weak 4-8 bit checksum.

Why paper backups matter

Most Bitcoin custody guides treat electronic devices as unavoidable. Hardware wallets are the gold standard. Encrypted digital backups are the backup plan. But every electronic device is a trust boundary and an attack surface.

The electronic trust problem

Modern seed backup methods create several risks:

Malware and side channels. Electronic devices can leak secrets through electromagnetic emissions, timing attacks, or compromised firmware. Even air-gapped computers have been demonstrated to leak information via power consumption, heat, or acoustic signals.

Vendor lock-in. Proprietary backup formats may become unsupported as companies fold or abandon products. What happens to your Trezor SLIP39 shares if Trezor disappears?

Update cycles. Every software or firmware update introduces risk of compatibility breaks or newly-discovered vulnerabilities. Cold storage shouldn’t require maintenance patches.

Long-term verification. Checking backup integrity typically requires exposing the seed to new hardware, creating a fresh attack surface each time you test your disaster recovery process.

The Codex32 approach

Codex32 addresses these by making the entire backup lifecycle computable without electronics:

Generation: Random shares can be created using dice and a von Neumann extractor worksheet
Verification: Checksums verifiable annually with 30-60 minutes of work using lookup tables
Recovery: Any threshold-sufficient set of shares can be combined by hand to recover the secret
Long-term compatibility: As long as the BIP-93 specification text survives, the scheme remains recoverable

A Codex32 backup made in 2026 will be recoverable in 2126 with nothing but the specification document and a pencil. No hardware, no software, no SDK, no API. Just math.

How it compares to existing schemes

BIP39

BIP39 (12/24-word seed phrases) is the most widely-used backup standard, but has significant limitations:

Feature	BIP39	Codex32
Checksum strength	4-8 bits (weak)	65 bits (strong)
Error correction	None	Up to 4 errors
Hand-computable	No (requires SHA-512)	Yes (lookup tables)
Secret sharing	No native support	Built-in (2-31 shares)
Encoding	11-bit words	5-bit Bech32

BIP39’s checksum uses multiple SHA-512 rounds, making hand verification effectively impossible. If you make a transcription error writing down your seed phrase, you won’t know until you try to recover, and by then it might be too late.

SLIP39

SLIP39 (Trezor’s secret-sharing scheme) is closer to Codex32, offering native Shamir secret sharing and stronger checksums. But it still requires electronic computation. You can’t verify a SLIP39 share’s integrity without a computer.

SLIP39 shares also can’t be converted to Codex32 shares because they use different underlying mathematical fields. However, SLIP39 master seeds can be re-encoded as Codex32 secrets if you’re willing to expose the seed to a computer during conversion.

Bitcoin Core PR #33043

The pull request, opened by contributor w0xlt in July 2025, adds two new RPC commands to Bitcoin Core:

backupcodex32

Exports the wallet’s BIP32 master seed in Codex32 format.

bitcoin-cli backupcodex32 "test"

Returns:

{
  "codex32": "ms10testxxxxxxxxxxxxxxxxxxxxxxxxxx4nzvca9cmczlw",
  "seed_hex": "318c6318c6318c6318c6318c6318c631"
}

restorecodex32

Creates a new descriptor wallet from a Codex32 string.

bitcoin-cli restorecodex32 "my_wallet" "ms10testxxxxxxxxxxxxxxxxxxxxxxxxxx4nzvca9cmczlw"

Current status

As of March 2026, the PR is in draft status and needs rebase (conflicts with other wallet PRs). Last updated January 28, 2026.

Active discussion between w0xlt, Andrew Poelstra (Codex32 co-author), and reviewer Sjors centers on whether import functionality should merge before export, and how this PR relates to earlier Codex32 work in PRs #27351 and #32652.

Current limitations

The PR has several constraints:

Descriptor wallets only. Works only with Bitcoin Core’s modern descriptor wallets (v0.21.0+), not legacy wallets.

No secret sharing yet. While the command accepts a threshold parameter, share generation and derivation aren’t implemented. Users must use external tools like the rust-codex32 library or the Codex32 website to split and combine shares.

No passphrase support. Unlike SLIP39, Codex32 has no built-in passphrase mechanism. Earlier discussion suggested implementing deterministic seed+passphrase combination, but this was deemed out of scope.

Who’s already using it?

Core Lightning shipped Codex32 support in v23.08 (August 2023). Users can now save and restore Core Lightning’s HSM secret using Codex32 format. This is the first production implementation in a major Bitcoin project.

Blockstream Green, Anchorwatch, and Liana have all indicated interest, but no concrete timelines.

The practical reality

Time investment is real:

Setup (2-of-3 scheme): ~2 hours 15 minutes (3 checksum worksheets at 40 min each, plus 3 share translations at 5 min each)
Setup (3-of-5 scheme): ~5 hours
Recovery: 10-15 minutes (plus 40 min to verify recovered secret)
Annual verification: 30-60 minutes per share

Inexperienced users may take 2-3× longer initially.

When to use Codex32

Good fit:

Long-term cold storage (years to decades)
Multi-generational wealth transfer
High-value holdings where electronic risks outweigh time costs
Paranoia about supply chain attacks on hardware
Geographically-distributed backups (shares in different jurisdictions)

Poor fit:

Active hot wallets (too slow for frequent recovery)
Low-value holdings (time cost exceeds value protected)
Users unwilling to invest hours in setup and maintenance
Lightning nodes or other cases requiring quick automated recovery

Tools available

Physical booklet. Blockstream sells a Codex32 booklet with tear-out worksheets and paper “volvelles” (calculation wheels). Includes artwork by Micaela Paez and M. Lufti’ As’ad.

Website. secretcodex32.com provides interactive documentation, downloadable worksheets (PDF), and conversion tables.

Rust library. rust-codex32 for software implementations.

Command-line tools. Several community-built CLI tools for share generation and derivation (for users who want software assistance but not full electronic storage).

What comes next

The Codex32 team is developing “quickchecks”: single-sheet partial checksum verifications that detect 99.9% of errors in 10-15 minutes. Seven quickchecks together equal a full verification. This would make annual checks far more practical.

From Andrew Poelstra’s March 2023 bitcoin-dev post:

“Quickchecks are partial checksum checks that still detect 99.9% of errors, and can be contained (instructions, lookup tables, and all) on a single sheet of paper.”

The ultimate goal? Hand-computable transaction signing. Currently impossible due to elliptic curve operations, but Blockstream Research considers this an open research question. If solved, it would enable truly air-gapped signing without electronics.

The bigger picture

Bitcoin’s value proposition centers on self-custody: “be your own bank.” But most backup schemes still require trusting electronic devices at critical moments. Codex32 extends self-custody to the backup layer itself.

This isn’t just another wallet format. It’s a different philosophy: computing without electronics. The time investment is real, but so is the sovereignty gain.

There’s something delightfully anachronistic about using 21st-century error-correcting codes on paper wheels. Like a cryptographic slide rule. But maybe that’s the point. A backup scheme for people who don’t trust hardware. For holdings meant to outlive hardware generations.

Bitcoin Core’s adoption would legitimize the approach and make it accessible to a broader audience. Whether PR #33043 merges in its current form or evolves through further iteration, Codex32 has already proven itself in production with Core Lightning.

The question isn’t whether paper backups work. It’s whether you value computational sovereignty enough to spend a few hours with a pencil.

Data as of March 16, 2026.