Pre-Signed Transaction

What Is a Pre-Signed Transaction?

A pre-signed transaction is a Bitcoin transaction that has been constructed, signed with the appropriate digital signatures, and stored for later use. Unlike a normal transaction that is signed and immediately broadcast to the network, a pre-signed transaction separates these two steps. The signature is created in advance, and broadcasting happens later when certain conditions are met or a specific event occurs.

Once a transaction is signed, it is fully valid. Anyone who possesses the signed transaction can broadcast it to the Bitcoin network and have it included in a block. This property makes pre-signed transactions useful as guarantees: they prove that a specific spending path exists and can be executed at any time, without needing access to the original private keys.

Pre-signed transactions are foundational to nearly all Bitcoin Layer 2 and custody protocols. In the Lightning Network, both parties sign commitment transactions before funding a channel. In vault designs, recovery transactions are pre-signed before funds are deposited. The pattern is always the same: guarantee the exit before committing the funds.

How It Works

Creating a pre-signed transaction follows the same process as any Bitcoin transaction, with one key difference: the final step of broadcasting is deliberately skipped.

1. Construct the transaction by specifying which UTXOs to spend (inputs) and where the funds should go (outputs), including amounts and recipient addresses
2. Set any desired constraints such as an nLockTime value (absolute timelock) or nSequence values (relative timelock) that prevent the transaction from being mined before a certain block height or time
3. Sign the transaction with the required private keys, producing a valid digital signature over the transaction data
4. Store the signed transaction securely offline rather than broadcasting it to the network
5. When the appropriate conditions are met, broadcast the transaction to the Bitcoin network for inclusion in a block

SIGHASH Flags and Signature Scope

The SIGHASH flag attached to each signature determines which parts of the transaction the signature commits to. This is critical for pre-signed transactions because it controls what can and cannot be modified after signing:

Most pre-signed transactions use SIGHASH_ALL, which locks every input and output. This prevents any modification after signing, ensuring the transaction can only execute exactly as constructed. The proposed SIGHASH_ANYPREVOUT flag (BIP-118) would allow signatures that do not commit to specific input outpoints, enabling a single pre-signed transaction to be rebound to different UTXOs with matching scripts.

Role of SegWit

Segregated Witness was a critical upgrade for pre-signed transaction protocols. Before SegWit, a transaction's ID (txid) included the witness data (signatures), meaning a third party could modify the signature format without invalidating it, changing the txid. This transaction malleability broke any pre-signed transaction that referenced the original txid as an input. SegWit separates witness data from the txid calculation, making pre-signed transaction chains reliable.

Collaborative Pre-Signing with PSBTs

When multiple parties need to sign a transaction (such as in a multisig setup), the Partially Signed Bitcoin Transaction (PSBT) format defined in BIP-174 provides a standardized workflow. PSBT separates transaction construction from signing, enabling scenarios where an online watch-only wallet creates the transaction and an air-gapped device signs it.

The PSBT workflow involves six roles: a Creator initializes the transaction, an Updater adds UTXO data and derivation paths, one or more Signers produce partial signatures, a Combiner merges them, a Finalizer constructs the complete witness, and an Extractor produces the final broadcast-ready transaction. Each signer can work independently, making PSBTs ideal for coordinating pre-signed transactions across hardware wallets, distributed key holders, or geographically separated parties.

# Create a PSBT for a vault recovery transaction
bitcoin-cli createpsbt \
  '[{"txid":"abc123...","vout":0}]' \
  '[{"bc1q_recovery_address":0.5}]' \
  144  # nLockTime: 144 blocks (approx. 1 day)

# Each signer processes the PSBT independently
bitcoin-cli walletprocesspsbt "base64_psbt_string"

# Combine partial signatures from multiple signers
bitcoin-cli combinepsbt '["psbt_signer1","psbt_signer2"]'

# Finalize and extract the broadcast-ready transaction
bitcoin-cli finalizepsbt "combined_psbt"

# Store the extracted hex transaction offline
# Broadcast later: bitcoin-cli sendrawtransaction "hex"

Use Cases

Bitcoin Vaults

Bitcoin vaults use pre-signed transactions to enforce a two-step withdrawal process with a time-delayed clawback mechanism. The design, first prototyped by Bryan Bishop in 2020, works as follows:

1. Generate an ephemeral (one-time-use) private key and derive a vault address
2. Pre-sign an unvault transaction that moves funds to an intermediate address with a timelock delay (for example, 24 hours)
3. Pre-sign a clawback transaction that can sweep funds back to a secure recovery address if the unvault is unauthorized
4. Delete the ephemeral key, so that the pre-signed transactions become the only possible spending paths
5. Deposit funds into the vault address

The timelock delay creates a detection window. If a watchtower or the user notices an unauthorized unvault transaction, they can broadcast the clawback transaction to recover the funds before the timelock expires.

The proposed OP_VAULT (BIP-345), formally added to the BIPs repository in 2024, would implement vault logic at the consensus level using dedicated opcodes, eliminating the need for ephemeral key deletion. For a deeper look at vault designs, see our research on Bitcoin script vaults and Bitcoin covenants.

Inheritance Planning

Pre-signed transactions enable a "dead man's switch" approach to Bitcoin inheritance:

1. The holder creates a transaction sending funds to their heir's address with a future nLockTime (for example, one year from now)
2. The signed transaction is given to the heir or stored securely; it cannot be broadcast until the timelock expires
3. The holder periodically "refreshes" the arrangement by spending the UTXO to a new address and creating a new pre-signed transaction with a new future timelock
4. If the holder passes away and stops refreshing, the timelock eventually expires and the heir can broadcast the transaction

This approach has significant limitations: the fee is fixed at signing time (potentially inappropriate years later), the destination address is hardcoded, and any spending from the source address invalidates the pre-signed transaction. More robust solutions use miniscript to encode recovery paths with OP_CHECKSEQUENCEVERIFY directly in the script, avoiding UTXO invalidation entirely. For practical guidance, see our Bitcoin inheritance planning guide.

Lightning Watchtower Justice Transactions

In the Lightning Network, each channel state update produces commitment transactions pre-signed by both parties. When a state is superseded, the old commitment transaction is revoked by sharing its revocation secret. If a counterparty broadcasts a revoked state (attempting to steal funds), a justice transaction can claim the entire channel balance as a penalty.

Users can delegate this monitoring to watchtowers. For each revoked state, the honest party creates a pre-signed justice transaction and sends it (encrypted) to the watchtower. The watchtower monitors the blockchain for breach attempts, and if it detects one, it decrypts and broadcasts the corresponding justice transaction. This allows users to go offline safely, with their pre-signed penalty transactions standing guard. For more details, see our research on Lightning watchtowers.

Statechains

Statechains transfer entire UTXOs between parties off-chain using pre-signed backup transactions as a safety mechanism. A user and a statechain entity create a 2-of-2 multisig address, and before depositing, they pre-sign a backup transaction with a future timelock allowing the user to withdraw unilaterally if the operator disappears. Each successive transfer uses a shorter timelock, ensuring the most recent owner can always claim first. Mercury Layer, released in 2024, improved this design using blind Schnorr MuSig2 signing so the operator never learns any transaction details. For a deep dive, see our research on statechains as a Bitcoin scaling approach.

Risks and Considerations

UTXO Invalidation

A pre-signed transaction references specific UTXOs by their outpoint (txid:vout). If the referenced UTXO is spent by any other transaction, the pre-signed transaction becomes permanently invalid. This is the most fundamental risk:

• Any movement of funds from the source address invalidates all pre-signed transactions spending those UTXOs
• For inheritance schemes, every new deposit or withdrawal requires creating new pre-signed transactions
• For delete-the-key vaults, the vault cannot be "topped up" without creating an entirely new vault

Long-Term Storage

Pre-signed transactions intended for inheritance or vault recovery may need to remain valid for years. Storage media can fail, and losing the pre-signed transaction when the original keys have been deleted means losing access to funds permanently. The transaction fee set at signing time may also be wildly inappropriate when the transaction is finally broadcast. Too low and it may never confirm; too high and it wastes funds. Protocols like OP_VAULT address the fee problem by allowing fee rates to be set at broadcast time rather than at signing time.

Key Deletion Trust

Delete-the-key vault designs rely on the assumption that the ephemeral key was truly destroyed. If it was copied or not fully wiped, the entire security model collapses because someone could construct new transactions outside the pre-signed paths. Proving deletion is inherently difficult, though hardware security modules and secure enclaves can provide stronger guarantees.

Covenant Alternatives

Proposed Bitcoin consensus changes like OP_CHECKTEMPLATEVERIFY (BIP-119) and OP_VAULT (BIP-345) would achieve similar goals to pre-signed transactions but at the protocol level. CTV commits to a transaction template hash in Bitcoin Script itself, enforcing specific spending paths without requiring pre-signed transactions or key deletion. These proposals remain under discussion: a CTV miner activation signaling window opened in March 2026, and BIP-345 was added to the BIPs repository in 2024, but neither has activated on mainnet.

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.