Nested SegWit (P2SH-P2WPKH)

Nested SegWit, formally P2SH-P2WPKH, embeds a native SegWit output inside a Pay-to-Script-Hash wrapper. The result is an address that begins with 3 on mainnet and is encoded in Base58Check like any other P2SH address, so older wallets and services that cannot parse Bech32 can still send to it without knowing SegWit exists. It was the transition format that let the ecosystem adopt SegWit immediately after the 2017 activation, capturing most of the fee savings years before Bech32 support became universal — a deliberately clever piece of backward compatibility layered on top of a soft fork that was itself a masterpiece of backward compatibility.

How the wrapping works

The on-chain scriptPubKey is an ordinary P2SH lock: OP_HASH160 <scriptHash> OP_EQUAL. The redeem script it commits to is not a conventional script but the native witness program itself: OP_0 <20-byte pubKeyHash>. When the coins are spent, the redeem script is revealed in the scriptSig (the only thing that ever appears there for this type), and a SegWit-aware node recognizes it as a witness program and applies segregated-witness validation: the actual signature and public key live in the witness field, where their bytes receive the witness discount. Legacy nodes, which do not understand witness programs, see a P2SH spend that satisfies the hash check and treat it as valid — which is precisely the mechanism that made SegWit deployable as a soft fork.

The fee arithmetic

Nested SegWit inputs are meaningfully cheaper to spend than legacy P2PKH, because the signature and pubkey move into the discounted witness. But they are moderately more expensive than native P2WPKH: the revealed redeem script adds bytes to the scriptSig, which is charged at full weight, and the output's scriptPubKey is also slightly larger. In round terms, nested SegWit sits between legacy and native on spend cost — most of the benefit, not all of it. Once your counterparties all recognize Bech32, the only thing nested SegWit still buys is compatibility with software that stopped being updated years ago, which is why wallets have steadily migrated defaults to native P2WPKH and, since 2021, to Taproot outputs.

What self-custody operators should know

The format's history explains its persistence. When SegWit activated in August 2017, the Bech32 address format was so new that most exchanges, wallets, and payment processors could not send to it; nested addresses let early adopters claim the witness discount immediately while remaining payable by everyone. Exchanges in particular ran nested deposit addresses for years precisely because rejecting a customer's legacy wallet was worse than paying slightly larger spend fees. The result is a long tail of type-3 UTXOs still sitting in old wallets — unremarkable, fully secure, and worth consolidating whenever fees are cheap and you are already touching the keys. Recovering such coins is routine with the right derivation path, which is exactly why documenting script types belongs in every backup plan.

A type-3 address is ambiguous from the outside: it may be a legacy multisig P2SH, a nested single-sig, or a nested SegWit multisig (P2SH-P2WSH) — nothing distinguishes them until the coins are spent and the redeem script is revealed. Anyone auditing an inheritance plan or old hardware wallet backups should therefore identify the wallet's script type and derivation path, not just its address prefix; the widely adopted convention places nested-SegWit single-sig wallets on BIP 49 derivation paths, distinct from legacy BIP 44 and native-SegWit BIP 84. Old nested-SegWit coins remain perfectly spendable indefinitely — there is no deadline and no risk in leaving them — but consolidating them into native or Taproot outputs during a low-fee period buys cheaper spends forever after. See Pay-to-Script-Hash (P2SH) for the wrapper mechanism itself.