Custody mechanics, not price

Taproot key path spend versus the quantum shield

Updated 22 October 2026

That is a key path spend. It is not a key that stays inside a sealed box. The moment a Taproot output is consumed through the key path, the tweaked internal key hits the chain in clear, and any future quantum adversary with the right hardware and a recorded transaction can run Shor against it. There is no quantum shield that retroactively seals a key that has already been broadcast.

What the key path actually is

Taproot, specified in BIP 341, describes two distinct ways to spend a SegWit v1 output. The first is the key path spend, where the witness contains a single Schnorr signature produced with the tweaked private key. The second is the script path spend, where the witness reveals a Merkle path to one of the committed scripts and satisfies it. Both spend paths spend the same UTXO. They differ in what hits the chain.

The key path, when used, looks like a single signature on chain. No script is published. No conditions are revealed beyond the fact that the key path was taken. This property is what gives Taproot its privacy profile: cooperative spends look identical to a single key signature, and the script tree only appears on chain if the script path is used.

The cost of that compactness is that the tweaked internal key, derived as Q = P + hash(P||c)·G from the internal key P and the merkle root c of the script tree, is implicitly exposed when the signature is verified. Verifiers need Q to check the signature. Once the signature is in a block, Q is on chain. The key was already implicit in the output's witness program, but the explicit verification material is now part of the permanent record.

Why the quantum shield does not reseal the key

The BIP 360 family of proposals, sometimes referred to under the broader "quantum shield" label, focuses on what to do with funds locked in legacy address types, particularly P2PKH outputs from the early blocks and the small set of early Taproot outputs that committed vulnerable keys. The proposals do not, and cannot, rewrite history. Once a key path signature is in a block, the tweaked internal key is recoverable by any party that keeps the chain.

Harvest now, decrypt later is the phrase used for this threat model. An adversary records the chain today, waits for fault tolerant quantum hardware with enough logical qubits to run Shor against an ECDSA or Schnorr public key, and then derives the private key from the recorded public key. The cost of running Shor against one recorded key drops as the hardware improves, but the recorded material is permanent. There is no migration that erases a broadcast key.

This is the part that is easy to misread. The quantum shield debate is about the future key set, about new output types that commit a post-quantum signature or a hash based commitment, and about how to incentivise migration of dormant vulnerable coins. It is not about making a key that was already broadcast safe again. Once a key path spend has happened, the clock on that key has been ticking since the block was confirmed.

What this means for a wallet that holds the box

For a custody user, the operational consequence is direct. A Taproot receive address is fine for receiving. The public key is not yet on chain at the receive step. The risk surface starts when funds are spent. A key path spend, by definition, reveals the key. A script path spend, by contrast, does not reveal any key that was not already part of a script branch chosen at spending time, and even then only reveals the keys required by that branch.

If the threat model includes a future quantum adversary, the custody rules sharpen. Treat every key path spend of a Taproot output as a public key reveal event. For new wallets, consider committing only post-quantum scripts, or using a script path spend that does not touch the vulnerable key. For old wallets, recognise that any key path spend in the chain history has already started the clock on that key. Refilling that same address type and re spending it via the key path just resets the clock on a new key, not on the old one.

It is also worth being clear about what a watch only wallet does in this picture. A watch only wallet sees the chain. It sees that a key path spend happened. It does not, by itself, expose the key any further. The exposure happened in the spending transaction. The role of the watch only wallet is to let the holder monitor reveals without holding spend authority, which is the correct posture during a migration window.

The script path as a deliberate countermeasure

Some custody strategies from late 2026 explicitly avoid the key path for outputs that hold material value. The script path can be constructed so that spending requires a hash based signature, for example a Lamport one time signature committed at output creation time and revealed only when spent, or a Winternitz scheme. The script path also lets the holder attach a timelock, a multisig threshold, or a covenant restriction without touching the internal key.

The trade off is cost. A script path spend is larger on chain than a key path spend. It reveals a Merkle branch and a script. The privacy win of Taproot is partly lost. The security win, against a quantum adversary, is that the internal key is never the spend authority, and the broadcast material is the script branch rather than a raw key.

This is the shape of the late 2026 discussion. The key path is the efficient path. The script path is the path a holder takes when the threat model includes future quantum recovery of broadcast keys. Both are valid Taproot spends. They are not equivalent under a quantum threat model.

How BIP 360 interacts with already broadcast keys

BIP 360 and the surrounding proposals aim to introduce a new output type that commits a post-quantum public key at creation time. For new funds, the box is built with a key the quantum adversary cannot run Shor against. For old funds in legacy types, the proposal is a migration window, with a deadline after which the consensus rules refuse to spend vulnerable output types. The economic argument is that the migration window is the runway, and quantum progress is the clock on the runway.

None of this changes the status of a key that was already revealed in a key path spend. The output, once spent, is consumed. The key is on chain. The only way to neutralise the threat against that key is for the holder to have moved the funds to a new output before the quantum adversary can run Shor against the recorded key. If the funds were moved, the box is empty. The adversary can derive the private key, but the key no longer controls any UTXO. The funds are in a new box with a new key.

That is the operational loop the quantum shield is trying to close. The key is exposed at the moment of the key path spend. The funds need to be in a new box, with a key the adversary cannot derive, before the quantum adversary can derive the old one. The race is between the holder's next transaction and the adversary's future hardware.

Practical custody notes for late 2026

Three rules follow. First, for any Taproot output holding material value, decide in advance whether the spend will be a key path spend or a script path spend. Do not let the wallet pick by default. Second, if a key path spend is used, treat the revealed key as compromised from the moment of confirmation. The funds should not return to the same address type. Third, do not paste a seed into a watch only field under any circumstance, including for a migration tool. A watch only field takes only an xpub or an address. Anything else is a phishing surface.

The chain does not forget a key path spend. The migration proposals do not erase it. The custody loop is to recognise that the reveal happened, move the funds once, and stop using the revealed key as a future spend authority. The box is still the box. The key that opened it is on chain, and a future adversary may hold a copy of the chain.

Never paste a seed into a watch only field.