Bitcoin Wallet Standards Reference: BIPs Every Developer Needs

Wallet-Critical BIP Standards

Bitcoin wallet development requires implementing a specific set of Bitcoin Improvement Proposals (BIPs) that govern how keys are generated, addresses are derived, transactions are signed, and backups are structured. Getting any of these wrong means lost funds, broken interoperability, or security vulnerabilities. This reference covers every standard a wallet developer needs to implement, organized by function.

The following table provides a quick-reference overview of the most critical wallet BIPs, their purpose, and current adoption status across the ecosystem.

Key Generation and Backup

BIP32: Hierarchical Deterministic Wallets

BIP32, authored by Pieter Wuille, defines the foundational mechanism for deriving an entire tree of keypairs from a single seed. A 128 to 512-bit seed is processed through HMAC-SHA512 with the key "Bitcoin seed" to produce a master private key and master chain code. From there, child keys are derived using two functions: CKDpriv (private parent to private child) and CKDpub (public parent to public child, non-hardened only).

The tree supports 2^31 normal child keys (indices 0 to 2^31-1) and 2^31 hardened child keys (indices 2^31 to 2^32-1). Hardened derivation prevents a compromised child key from exposing the parent. Extended keys serialize to 78 bytes (version, depth, parent fingerprint, child index, chain code, key data) and Base58Check-encode to produce xpub/xprv strings. Every HD wallet in the ecosystem implements BIP32. View derived keys using our xpub viewer tool.

BIP39: Mnemonic Seed Phrases

BIP39, authored by Marek Palatinus, Pavol Rusnak, Aaron Voisine, and Sean Bowe, converts random entropy into a human-readable seed phrase. Entropy (128 to 256 bits) gets a checksum appended (the first ENT/32 bits of its SHA-256 hash), then is split into 11-bit groups mapped to a 2048-word list. The result is 12 words for 128-bit entropy or 24 words for 256-bit entropy.

Seed derivation uses PBKDF2-HMAC-SHA512 with the mnemonic as the password and "mnemonic" + passphrase as the salt, run for 2048 iterations to produce a 512-bit seed. The optional passphrase (sometimes called the "25th word") creates an entirely different wallet for each value, enabling plausible deniability. BIP39 is supported by Ledger, Trezor, Coldcard, BlueWallet, Sparrow, and nearly all other wallets. Notable exceptions: Electrum uses its own versioned seed format, and Bitcoin Core does not generate BIP39 mnemonics natively (it uses descriptor-based backups).

SLIP39: Shamir's Secret Sharing Backup

SLIP39, developed by SatoshiLabs, implements Shamir's Secret Sharing to split a master secret into N shares where any T shares reconstruct it. The scheme operates over GF(256) using the Rijndael irreducible polynomial, with the secret encoded at polynomial index 255. Each share is encoded as a 20 or 33-word mnemonic from a distinct 1024-word list (not the BIP39 wordlist).

SLIP39 supports a two-level hierarchy: up to 16 groups with independent thresholds, each containing up to 16 member shares. This enables sophisticated custody arrangements: a company might require 3-of-5 group threshold where each group has its own internal 2-of-3 requirement. Shares are encrypted with a 4-round Feistel network using PBKDF2-HMAC-SHA256, making partial share attacks infeasible. Adoption remains limited: Trezor Safe 3, Safe 5, and Model T support SLIP39 natively. Sparrow can import SLIP39 shares. Coldcard and Ledger do not support it.

Note: SLIP39 is not compatible with BIP39. A SLIP39 share set cannot be converted to a BIP39 mnemonic or vice versa. Wallet developers who support both must treat them as entirely separate backup mechanisms.

Derivation Path Standards

BIP43 defines the first level of a BIP32 tree as a "purpose" field (m / purpose' / *), where the purpose number routes to the BIP governing the subtree structure below it. Each address-type BIP assigns its own purpose number, following the five-level path structure defined by BIP44: m / purpose' / coin_type' / account' / change / address_index. The derivation path a wallet uses determines which address format it produces.

In all paths, c is 0 for external (receiving) addresses and 1 for internal (change) addresses. i is the sequential address index. All levels through account are hardened. BIP86 reuses the original xpub/xprv version bytes rather than defining new prefixes: wallets rely on the purpose=86' context to determine address type.

BIP49 (wrapped SegWit) is declining in relevance as bech32 send support is now near-universal. BIP84 (native SegWit) is the current default for most wallets. BIP86 (Taproot) adoption is growing: Bitcoin Core, Sparrow, Coldcard, Nunchuk, and Specter fully support it, while Electrum and several mobile wallets are still adding send and receive support. For a deeper look at how these address types differ on-chain, see our research on Bitcoin address types from P2PKH to Taproot.

Wallets performing seed recovery must scan all four purpose paths (44', 49', 84', 86') to locate funds. The address gap limit (typically 20 unused addresses) determines when scanning stops on each path.

Transaction Signing: PSBT

BIP174 defines the Partially Signed Bitcoin Transaction (PSBT) format, the standard for passing unsigned or partially signed transactions between wallets, hardware devices, and coordinators. PSBT is the foundation of every modern air-gapped signing and multisig workflow.

A PSBT begins with the magic bytes 0x70736274FF (ASCII "psbt" + 0xFF) followed by a global map and per-input/per-output maps. Each map contains key-value records. The format defines six roles: Creator (constructs the unsigned transaction), Updater (adds UTXO data and BIP32 derivation paths), Signer (produces signatures using only PSBT-contained data), Combiner (merges multiple PSBTs), Input Finalizer (constructs final scriptSig/witness), and Transaction Extractor (produces the broadcastable transaction). For a detailed walkthrough of the signing workflow, see the PSBT workflow guide.

The critical security property: a hardware signing device can verify the full transaction (amounts, addresses, change outputs) from the PSBT data alone, without blockchain access or trusting the coordinator software. PSBT support is implemented in Bitcoin Core, Sparrow, Electrum, BlueWallet, Coldcard, Trezor, Ledger (via HWI), and BTCPay Server.

BIP370: PSBTv2

BIP370 extends the PSBT format for interactive transaction construction. The key change: PSBTv2 removes the fixed PSBT_GLOBAL_UNSIGNED_TX field and distributes transaction data into individual per-input and per-output fields. This allows a new Constructor role to add or remove inputs and outputs after initial creation, governed by TX_MODIFIABLE flags.

PSBTv2 enables protocols where multiple parties contribute inputs incrementally: CoinJoin, PayJoin, and collaborative transaction building. Adoption is still limited: Ledger's Bitcoin app was an early adopter, and Bitcoin Core has merged PSBTv2 support. Most hardware wallets still primarily use PSBTv1.

Replace-by-Fee: BIP125

BIP125 defines opt-in Replace-by-Fee signaling. A transaction signals replaceability when any input has nSequence < 0xFFFFFFFE. Replacement transactions must pay a higher absolute fee than all transactions they replace and cover their own bandwidth at the minimum relay fee rate.

Since Bitcoin Core 26.0 (released in late 2023), full RBF is enabled by default. All unconfirmed transactions are now replaceable in Bitcoin Core mempools regardless of nSequence signaling. BIP125 opt-in signaling remains a useful convention for communicating intent to other wallet software, but it is no longer the enforcement boundary at the mempool level. Wallet developers should implement fee-bumping UIs and set nSequence to signal BIP125 by convention. For the practical differences between RBF and CPFP fee bumping, see our RBF vs CPFP comparison.

Output Descriptors: BIP380-386

Output script descriptors solve the problem that an xpub alone is insufficient to reconstruct a wallet. A descriptor encodes the script type, master fingerprint, full derivation path, extended public key, and a BCH error-detecting checksum in a single portable string. The combination of a BIP39 seed (or any seed) plus output descriptors is the current best practice for complete wallet backup and portability.

Descriptors are Bitcoin Core's primary wallet model: legacy wallet creation was removed in v26.0 and all new wallets are descriptor-based. Sparrow, Coldcard, Specter, Nunchuk, Liana, and the Bitcoin Dev Kit (BDK) all use descriptors extensively. For hardware wallet coordination, BIP388 defines a simplified descriptor subset called "wallet policies" that Ledger, Trezor, and Coldcard support. For more on descriptor syntax and usage, see our output descriptors reference.

Taproot Standards: BIP340, BIP341, BIP342

The Taproot upgrade, activated at block 709,632 in November 2021, consists of three tightly coupled BIPs that wallet developers must understand together.

BIP340 defines Schnorr signatures for secp256k1. Signatures are exactly 64 bytes (32-byte R x-coordinate + 32-byte s scalar), compared to ECDSA's variable-length DER encoding of up to 72 bytes. BIP340 uses 32-byte x-only public keys (even Y assumed), which is why Taproot keys look different from legacy compressed keys. Schnorr signatures are provably non-malleable and enable native batch verification and key aggregation via MuSig2.

BIP341 defines SegWit version 1 spending rules. The output key Q is computed as Q = P + hash(P || m) * G where P is the internal key and m is the Merkle root of an optional script tree. Key-path spends require only a single 64-byte Schnorr signature and are indistinguishable on-chain from script-path spends: maximum privacy when all parties cooperate. Script-path spends reveal only the executed branch, keeping unused conditions private.

BIP342 (Tapscript) modifies Bitcoin Script rules within Taproot: OP_CHECKSIG now verifies Schnorr signatures, a new OP_CHECKSIGADD opcode replaces OP_CHECKMULTISIG for batch-verifiable k-of-n schemes, the 10,000-byte script size limit is removed, and the 201 non-push opcode limit is removed. For practical Taproot usage patterns, see our Taproot and Schnorr signatures explainer.

Implementation Priority for Wallet Developers

Not all BIPs carry equal weight. The following prioritization reflects the minimum viable standards for a new Bitcoin wallet in 2026:

Required for any wallet:

• BIP32 + BIP39 for key generation and seed backup
• BIP84 (native SegWit) as the default derivation path
• BIP174 (PSBT) for hardware wallet and multisig interoperability
• BIP125 signaling for fee bumping support

Required for modern wallets:

• BIP86 (Taproot) derivation and BIP340/341/342 for Schnorr signing
• BIP380-386 (output descriptors) for portable wallet backup
• BIP44 and BIP49 scanning for seed recovery from older wallets

Recommended for advanced wallets:

• SLIP39 for Shamir backup support
• BIP370 (PSBTv2) for interactive protocol support
• BIP389 for multipath descriptor key expressions

Wallets building on Bitcoin layer-2 protocols like Spark still need these base-layer standards for on-chain operations, key management, and interoperability with the broader Bitcoin ecosystem. For a comparison of wallet SDKs that implement these standards, see our Bitcoin wallet SDK comparison.

Frequently Asked Questions

What is the difference between BIP39 and SLIP39?

BIP39 generates a single 12 or 24-word mnemonic that encodes the entire seed. SLIP39 splits the seed into multiple share mnemonics (each 20 or 33 words from a different wordlist) using Shamir's Secret Sharing, requiring a threshold number of shares to reconstruct the original. BIP39 is simpler and universally supported. SLIP39 provides redundancy for self-custody setups where a single backup point of failure is unacceptable. The two formats are not interchangeable.

Which derivation path should a new wallet use by default?

Use m/84'/0'/0' (BIP84, native SegWit) as the primary default. It produces bc1q addresses with the lowest transaction fees among widely supported formats. Add m/86'/0'/0' (BIP86, Taproot) as a secondary option. During seed import and recovery, scan all four standard paths (44', 49', 84', 86') to locate any existing funds.

Why does BIP39 not include a version number?

BIP39 was designed before the proliferation of address types. Its checksum validates the mnemonic itself but encodes no information about which derivation scheme or script type to use. This means a BIP39 seed alone does not tell a wallet whether to derive P2PKH, P2WPKH, or P2TR addresses. Electrum addressed this by creating its own versioned seed format, and LND created Aezeed (which also includes a wallet birthday for faster chain scanning). Output descriptors (BIP380-386) are the ecosystem's answer: they encode derivation path and script type alongside the key, making a descriptor + seed a complete wallet backup.

What is PSBT used for in practice?

PSBT is the standard format for passing transactions between software wallets and hardware signing devices. In a typical cold storage workflow, a watch-only wallet constructs the PSBT, transfers it to an air-gapped device (via microSD or QR code), the device signs and returns it, and the watch-only wallet broadcasts the final transaction. PSBT is also essential for multisig coordination where cosigners sign independently and their partial signatures are combined.

Do all wallets support Taproot (BIP86)?

Not yet. As of 2026, Bitcoin Core, Sparrow, Coldcard, Nunchuk, Specter, Liana, and several Lightning wallets fully support BIP86 Taproot derivation for both sending and receiving. Electrum has partial support. Some mobile wallets (BlueWallet, Mycelium) and older hardware firmware versions lack full Taproot receive support. Wallet developers should support BIP86 but must also maintain BIP84 as the primary fallback for maximum ecosystem compatibility.

What are output descriptors and why do they matter?

Output descriptors (BIP380-386) are a compact language for describing exactly how a wallet derives its addresses. A descriptor string like wpkh([d34db33f/84h/0h/0h]xpub.../0/*)#checksum encodes the script type, master key fingerprint, derivation path, extended public key, and an error-detecting checksum. This solves the "xpub is not enough" problem: without descriptors, recovering a wallet from just an xpub requires guessing the script type, derivation path, and gap limit. Descriptors make wallet backup deterministic and portable across any compatible software.

How does full RBF affect BIP125 opt-in signaling?

Since Bitcoin Core 26.0 enabled full RBF by default, all unconfirmed transactions are replaceable in Bitcoin Core mempools regardless of nSequence values. BIP125 opt-in signaling is no longer the enforcement boundary: it functions as a convention that communicates intent to other wallet software. Wallet developers should still set nSequence < 0xFFFFFFFE to signal replaceability, as some non-Core node implementations and services still check for BIP125 signaling. Wallets should also assume that any unconfirmed transaction they receive could be replaced.

This reference is for informational purposes only and does not constitute financial or security advice. BIP statuses and wallet support levels change over time. Always verify current implementation details against the official BIP repository and individual wallet documentation before shipping production code.