BIP-84 (Native SegWit Derivation)

What Is BIP-84?

BIP-84 is a Bitcoin Improvement Proposal that defines how hierarchical deterministic wallets should derive keys for native SegWit (P2WPKH) addresses. Published by Pavol Rusnak of SatoshiLabs in December 2017, it extends the derivation scheme established by BIP-44 to support bech32 addresses: the bc1q format introduced by Segregated Witness.

Before BIP-84, wallets that wanted to generate native SegWit addresses had no standardized derivation path to follow. Different wallet implementations could derive keys differently from the same seed phrase, making cross-wallet recovery unreliable. BIP-84 solves this by assigning purpose field 84 to P2WPKH accounts, ensuring that any BIP-84-compliant wallet will derive identical addresses from the same seed.

In the evolution of Bitcoin address standards, BIP-84 represents the third generation of derivation schemes: BIP-44 (purpose 44) handles legacy P2PKH addresses starting with "1", BIP-49 (purpose 49) handles wrapped SegWit P2SH-P2WPKH addresses starting with "3", and BIP-84 (purpose 84) handles native SegWit P2WPKH addresses starting with "bc1q". The latest addition, BIP-86 (purpose 86), covers Taproot P2TR addresses starting with "bc1p".

How It Works

BIP-84 builds on the hierarchical key derivation framework from BIP-32. A single master seed generates an entire tree of key pairs through a series of derivation steps, each identified by an index number. The full derivation path follows this structure:

m / purpose' / coin_type' / account' / change / address_index

m          - master key (derived from the seed)
purpose'   - 84' (hardened, signals native SegWit)
coin_type' - 0' for Bitcoin mainnet, 1' for testnet
account'   - 0' for the first account, 1' for the second, etc.
change     - 0 for receiving addresses, 1 for change addresses
address_index - 0, 1, 2... sequential address index

The apostrophe (') denotes hardened derivation, which means the child key cannot be used to compute the parent key. The first three levels are all hardened, preventing any compromise of a child key from exposing the master key or keys in other accounts.

Path Examples

Here are concrete derivation paths for common scenarios:

m/84'/0'/0'/0/0   - First receiving address, first account
m/84'/0'/0'/0/1   - Second receiving address, first account
m/84'/0'/0'/1/0   - First change address, first account
m/84'/0'/1'/0/0   - First receiving address, second account
m/84'/1'/0'/0/0   - First receiving address, testnet

Each path produces a unique key pair. The public key is hashed using HASH160 (SHA-256 followed by RIPEMD-160) to produce a 20-byte witness program, which is then encoded as a bech32 address with the bc1q prefix.

Extended Key Prefixes

BIP-84 introduces distinct version bytes for serialized extended keys to differentiate them from BIP-44 and BIP-49 keys:

These prefixes let wallet software immediately identify the address type an extended key is intended for. A zpub key always generates bc1q addresses, whereas the older xpub format generates legacy addresses starting with "1".

P2WPKH Output Script

The addresses derived via BIP-84 produce P2WPKH (Pay-to-Witness-Public-Key-Hash) outputs. The scriptPubKey is minimal: just witness version 0 followed by the 20-byte public key hash.

// P2WPKH scriptPubKey structure
OP_0 OP_PUSHBYTES_20 <20-byte-hash160-of-compressed-pubkey>

// Hex example
0x0014{hash160_of_pubkey}

// Witness data (provided when spending)
<signature>        // ~72 bytes, DER-encoded
<compressed_pubkey> // 33 bytes

Because signatures and public keys live in the witness field rather than the scriptSig, they receive the SegWit witness discount: witness bytes count as only 0.25 weight units each instead of 1.0, directly reducing the transaction's virtual size and fee cost.

Fee Savings Compared to Other Address Types

The primary motivation behind BIP-84 adoption is cost efficiency. By moving signature data into the discounted witness field, P2WPKH transactions are significantly lighter. For a standard single-input, two-output transaction:

While wrapped SegWit has a slightly lower weight for single-input transactions, P2WPKH outputs are smaller (31 bytes vs 32 bytes for P2SH), making native SegWit more efficient overall in multi-input transactions and when receiving payments. For a deeper look at how these address types compare, see the guide to Bitcoin address types.

Why It Matters

BIP-84 is important for both individual users and the Bitcoin ecosystem as a whole. Lower fees mean more affordable transactions, especially during high-fee periods when the fee market is competitive. The standardized derivation path ensures that users can recover their funds in any compatible wallet simply by importing their seed phrase.

For wallet developers and platforms building on Bitcoin, BIP-84 provides a clear specification for address generation. Platforms like Spark and other Bitcoin layer-2 solutions benefit from the standardized key management that BIP-84 enables, as users can maintain consistent key hierarchies across on-chain and off-chain wallets. Interoperability between self-custodial wallets, hardware signers, and software wallets depends on shared standards like BIP-84.

The transaction malleability fix provided by SegWit is also critical for layer-2 protocols. Because P2WPKH transactions exclude signature data from the transaction ID hash, pre-signed transactions cannot be invalidated by third-party malleability. This property underpins the security of Lightning channels, state channels, and other off-chain constructions. For more on how these protocols work, see the Bitcoin second-layer scaling landscape.

Use Cases

• Everyday payments: bc1q addresses are the standard for sending and receiving Bitcoin with optimal fee efficiency, supported by virtually all modern wallets and exchanges
• Wallet recovery: the standardized path ensures that importing a seed phrase into any BIP-84-compliant wallet reproduces the same set of addresses and balances
• Multi-account management: the account-level derivation (m/84'/0'/0', m/84'/0'/1', etc.) allows users to organize funds into separate accounts under one seed
• Hardware wallet integration: devices like Trezor, Ledger, and Coldcard use BIP-84 as their default derivation path for Bitcoin, enabling seamless interoperability with desktop and mobile signing software
• Watch-only wallets: sharing a zpub (extended public key) allows read-only access to all derived addresses without exposing private keys, useful for accounting and monitoring

Wallet Compatibility

BIP-84 native SegWit enjoys near-universal support. As of 2026, SegWit v0 transactions (including BIP-84 P2WPKH) account for approximately 90% or more of all Bitcoin transactions:

• Bitcoin Core: uses P2WPKH descriptors with m/84'/0'/0' as the default for descriptor wallets since version 23
• Sparrow Wallet: defaults to native SegWit (P2WPKH) for new wallets
• Trezor Suite, Ledger Live, and Coldcard: all support BIP-84 derivation natively
• BlueWallet, Electrum, and Exodus: full bc1q address support
• Major exchanges (Coinbase, Kraken, Binance): support both sending to and withdrawing from bc1q addresses

Risks and Considerations

No Backward Compatibility by Design

BIP-84 is intentionally incompatible with older wallet software that only understands BIP-44 derivation paths. If you import a seed phrase into a wallet that does not support BIP-84, it will not discover your bc1q addresses or balances. This is actually a safety feature: it alerts users that their wallet lacks native SegWit support rather than silently generating incorrect addresses. However, users must verify that their recovery wallet supports BIP-84 before relying on it for backup.

Address Gap Limits

Like all BIP-44-family derivation schemes, BIP-84 wallets scan for used addresses sequentially and stop after encountering a gap of unused addresses (typically 20). If a user generates addresses beyond this gap without using the intermediate ones, some wallets may fail to discover those funds during recovery. Understanding address gap limits is important when using BIP-84 wallets with advanced workflows.

Extended Key Exposure

Sharing a zpub allows anyone to derive all public keys and track every transaction in that account. While this does not compromise spending authority, it is a significant privacy risk. Users should treat zpub keys with the same care as other sensitive wallet data. For more on key security practices, see the Bitcoin custody solutions comparison.

Taproot as the Next Step

BIP-86 introduces Taproot derivation paths using purpose 86. Taproot (P2TR) inputs are cheaper to spend than P2WPKH inputs and offer enhanced privacy through Schnorr signatures. However, P2WPKH outputs remain smaller, and Taproot adoption is still growing. For most users in 2026, BIP-84 remains the safest default due to its universal support, though BIP-86 may eventually supersede it as Taproot compatibility becomes ubiquitous.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.