Pre-Signed Exit Transaction

What Is a Pre-Signed Exit Transaction?

A pre-signed exit transaction is a valid Bitcoin transaction that has been signed in advance and held by the user, ready to be broadcast to the Bitcoin network at any time. It spends from a shared or locked output (such as a multisig or a funding transaction) and pays the user's funds directly to an address they control on the base layer. The transaction exists as a fully signed, ready-to-broadcast safeguard: the user's escape hatch from the off-chain protocol.

The critical property is timing. The exit transaction must be signed before or at the moment the user commits funds to the off-chain system. If a user deposits first and only later requests an exit path, they are trusting the counterparty to provide one. By requiring the exit to be pre-signed, the protocol eliminates that trust assumption entirely. As Spark's protocol documentation describes it: before you deposit funds, you work with the operators to create a pre-signed transaction that exits funds to the Bitcoin L1.

This pattern is fundamental to every off-chain Bitcoin protocol that claims to preserve self-custody. Without a pre-signed exit, the system is custodial by definition: the user cannot independently recover their funds.

How It Works

The mechanics vary by protocol, but the core pattern is consistent across all off-chain Bitcoin systems:

1. Two or more parties create a funding output (typically a multisig or a shared UTXO)
2. Before the funding transaction is broadcast, all parties sign an exit transaction that spends from that output back to the user's address
3. The user stores the signed exit transaction locally
4. If the counterparty or operator becomes uncooperative, the user broadcasts the exit transaction to the Bitcoin network
5. After a timelock period, the user's funds are confirmed on-chain

The timelock is a deliberate design choice. It gives the counterparty time to respond or dispute the exit, preventing scenarios where a user broadcasts an outdated state. The delay period varies: Lightning typically uses 144 blocks (approximately one day), while other protocols may use longer windows.

Why Sign Before Depositing?

Consider the alternative: a user deposits funds into a 2-of-2 multisig and then asks the counterparty to sign an exit transaction. If the counterparty refuses, the user's funds are trapped. The counterparty could demand a fee, delay indefinitely, or simply disappear.

By requiring the exit transaction to be signed first, the protocol reverses the leverage. The user holds a signed transaction that works unconditionally. The counterparty cannot hold funds hostage because the user never committed funds without already possessing the signed exit path. This is the same principle behind Lightning's channel opening sequence: the commitment transaction is signed before the funding transaction is broadcast to the Bitcoin network.

Simplified Transaction Structure

A basic pre-signed exit transaction follows this pattern:

Input:
  txid: <funding_tx_hash>
  vout: 0
  scriptSig: <user_sig> <operator_sig>  // Both signatures collected at setup

Output:
  value: <user_balance - fee>
  scriptPubKey: OP_IF
                  <revocation_pubkey> OP_CHECKSIG
                OP_ELSE
                  <to_self_delay> OP_CSV OP_DROP
                  <user_pubkey> OP_CHECKSIG
                OP_ENDIF

The output uses OP_CHECKSEQUENCEVERIFY (CSV) to enforce a relative timelock. After broadcasting, the user must wait for the specified number of blocks before spending the output. The revocation branch allows the counterparty to claim the funds if the exit transaction represents an outdated state.

Pre-Signed Exits Across Protocols

Lightning Network: Commitment Transactions

In Lightning channels, the pre-signed exit is the commitment transaction. Each channel update produces a new pair of commitment transactions: one for each party. Either side can broadcast their version to close the channel unilaterally (a force close).

Lightning's commitment transactions have an asymmetric structure. The broadcaster's own output is locked behind a timelock (the to_self_delay, typically 144 blocks), while the counterparty's output is immediately spendable. This asymmetry enables the penalty mechanism: if a party broadcasts a revoked commitment, the counterparty (or their watchtower) can use the revocation key to claim the entire channel balance as a justice transaction.

Spark: vTXO Exit Paths

Spark structures its off-chain state as a tree, with a root on-chain UTXO branching into internal nodes and leaf vTXOs. When a user receives funds on Spark, they also receive pre-signed Bitcoin transactions that allow withdrawal to the base layer without operator cooperation.

A unilateral exit on Spark involves broadcasting the pre-signed branch transactions from the tree root down to the user's specific leaf. This typically requires two on-chain transactions: a branch transaction and an exit transaction. The exit transaction carries a relative timelock, so the user waits for confirmation before their funds become spendable. A cooperative exit, by contrast, requires only a single on-chain transaction and no waiting period.

Ark: Shared UTXO Trees

The Ark protocol uses a similar tree structure but with a different exit cost profile. Users can publish their branch of pre-signed transactions from the shared UTXO root down to their specific leaf vTXO. For larger trees, this means one on-chain transaction per tree level, making unilateral exits more expensive than in Spark.

Ark also uses connector outputs to enforce atomicity during round transitions. These connectors ensure that forfeit transactions (which invalidate old vTXOs) are only valid if the new round transaction is confirmed on-chain, preventing double-spending during state updates.

Use Cases

Self-Custody Guarantee

The primary use case is preserving self-custody in off-chain systems. Without pre-signed exits, any off-chain protocol that holds user funds would be functionally custodial. The pre-signed exit transaction is what makes it possible to move funds off-chain for speed and cost savings while retaining the ability to settle back to Bitcoin's base layer unilaterally.

Operator Failure Recovery

If an operator, service provider, or channel partner goes offline permanently, pre-signed exit transactions let users recover funds without any cooperation. This is critical for long-lived protocols like Lightning channels or Spark's statechain model, where operator downtime could otherwise strand user funds indefinitely.

Dispute Resolution

Pre-signed exits serve as the enforcement layer for dispute resolution. In Lightning, if a counterparty broadcasts an outdated state, the honest party uses the revocation key to claim the full channel balance via a penalty transaction. The timelock window on the exit transaction gives the honest party (or their watchtower) time to detect and respond to cheating attempts.

Protocol Migration

When protocols upgrade or become deprecated, pre-signed exit transactions ensure users can always return to the base layer. Even if a protocol ceases operation entirely, users holding valid pre-signed exits can broadcast them to recover funds.

Risks and Considerations

Fee Estimation at Signing Time

A pre-signed exit transaction locks in its fee rate at the time of signing. If the Bitcoin fee market spikes between signing and broadcast, the transaction may be too cheap to confirm promptly. If the fee market drops, the user overpays.

Modern protocols address this with mechanisms like anchor outputs, which allow the broadcaster to attach additional fees via child-pays-for-parent (CPFP) at broadcast time. Lightning adopted anchor outputs specifically to solve this fee estimation problem for commitment transactions.

State Invalidation Complexity

When the off-chain state updates (new payments, balance changes), old pre-signed exit transactions must be invalidated. In Lightning, this happens through revocation key exchange: each state update reveals the secret for the previous state, enabling penalties for broadcasting old transactions. Failing to properly invalidate old states creates the risk of a penalty against the user.

On-Chain Cost of Unilateral Exits

Broadcasting a pre-signed exit transaction requires paying on-chain fees. For tree-based protocols like Ark, where exit involves multiple sequential transactions (one per tree level), costs can be substantial. A tree with 1,024 vTXOs may require approximately 10 sequential on-chain transactions for a full unilateral exit. Spark's design reduces this to typically two transactions.

Timelock Trade-offs

Longer timelocks give counterparties and watchtowers more time to detect and respond to fraud, increasing security. But they also mean users must wait longer to access funds during a unilateral exit. Lightning typically uses a to_self_delay of 144 blocks (approximately one day), while other protocols may impose longer delays. Choosing the right timelock length involves balancing security against liquidity.

Storage and Backup Requirements

Users must securely store their pre-signed exit transactions. Losing them means losing the ability to exit unilaterally. This is analogous to losing a seed phrase: the funds may still exist in the protocol, but the user cannot independently recover them. Robust backup strategies are essential, particularly for protocols where exit transactions update frequently (like Lightning, where every channel update produces new commitment transactions).

Pre-Signed Exits and Protocol Trust Models

The presence and strength of pre-signed exit transactions is one of the most important criteria for evaluating off-chain protocols. A protocol that gives users a pre-signed exit before accepting deposits offers a fundamentally different trust model than one that requires operator cooperation to withdraw. For a deeper comparison of how different Bitcoin Layer 2 systems handle exits, see the Bitcoin L2 Trust Model Comparison and the Spark UX advantage analysis.

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.