Statechain Backup

What Is a Statechain Backup?

A statechain backup is a pre-signed Bitcoin transaction that serves as a safety net for users of statechains. It allows the current owner of a statechain coin to move their funds back to the Bitcoin base layer without any cooperation from the statechain entity. This recovery path exists because statechains rely on an operator to co-sign transfers: if that operator disappears, users need a guaranteed way to reclaim their Bitcoin.

The backup transaction is created at the time of each statechain transfer. The outgoing owner and the statechain entity cooperatively sign a transaction that pays to the new owner's address, locked with an nLockTime value that prevents it from being broadcast until a specific block height. This transaction sits dormant unless needed: the new owner stores it locally and only broadcasts it if the statechain entity stops responding.

Think of it as an insurance policy. Under normal conditions, you never use it because statechain transfers happen instantly off-chain. But if the operator shuts down, you can file the claim: broadcast your backup transaction and wait for the timelock to expire, then your funds arrive in your on-chain wallet.

How It Works

The backup mechanism relies on two core Bitcoin features: pre-signed transactions and timelocks. Together, they create a system where the most recent owner always has priority over previous owners when exiting to the base layer.

Backup Creation During Transfer

When a statechain coin is transferred from one owner to the next, the following steps occur:

1. The current owner and the statechain entity cooperatively sign a new backup transaction that pays to the incoming owner's Bitcoin address
2. This backup transaction includes an nLockTime set to a specific future block height
3. The incoming owner receives and stores this signed backup transaction
4. The statechain entity updates its records to reflect the new ownership
5. The previous owner's key share is deleted by the entity to prevent double-spending

The backup transaction is never broadcast during normal operation. It exists purely as a fallback. The incoming owner keeps it alongside the key material needed to spend the statechain coin in future off-chain transfers.

Decrementing Timelocks

The critical design element is how timelocks change with each transfer. Each successive backup transaction uses a shorter nLockTime than the previous one. This means the most recent owner's backup becomes valid on-chain before any earlier owner's backup.

# Statechain coin created at block 900,000
# Owner 1 (Alice): backup nLockTime = 900,000 + 1,000 = block 901,000
# Owner 2 (Bob):   backup nLockTime = block 900,800
# Owner 3 (Carol): backup nLockTime = block 900,600

# If everyone broadcasts at the same time:
# Carol's tx is valid first (block 900,600)
# Bob's tx is valid second (block 900,800) — but UTXO already spent
# Alice's tx is valid last (block 901,000) — but UTXO already spent

This decrementing pattern means that even if a previous owner retains their old backup transaction, the current owner will always beat them to the on-chain exit. The previous owner's transaction references the same UTXO, so once the current owner spends it, all older backups become invalid.

Why Not Eltoo?

The original statechain proposal envisioned using eltoo (LN-Symmetry) style updates, where a newer transaction could simply override any older one without decrementing timelocks. This would remove the transfer limit imposed by the timelock countdown. However, eltoo requires the SIGHASH_ANYPREVOUT opcode, which has not been activated on Bitcoin. The decrementing nLockTime approach works today without any soft fork.

Comparison with Lightning Force Close

Statechain backups serve a similar purpose to Lightning's force close mechanism: both allow users to exit an off-chain protocol and settle on the Bitcoin base layer without counterparty cooperation. However, the two differ in important ways:

A key difference is the penalty model. Lightning uses a punitive approach: if a counterparty broadcasts a revoked state, the other party can claim all channel funds via a justice transaction. Statechains rely on ordering: the current owner simply exits first because their timelock expires sooner. There is no penalty for attempting to broadcast an old backup, though the attempt will fail because the UTXO will already be spent.

Spark's Approach to Backup and Recovery

Spark builds on the statechain model and uses pre-signed exit transactions to ensure users can always reach the Bitcoin base layer. Each owner of a virtual UTXO (vUTXO) receives the signed exit data needed to reconstruct their on-chain claim. In Spark's architecture, exits traverse a tree of transactions, where each leaf represents a vUTXO that can be independently settled on-chain.

Recovery requires the user to have saved their recovery bundle while the Spark operators were still reachable. This bundle contains the pre-signed transactions and key material needed to build the exit path. Wallet applications built on Spark are expected to persist this data automatically, but users should verify that their wallet stores recovery data and understand how to use it.

For a deeper look at how Spark handles operator trust and exit guarantees, see the research article on statechains as a Bitcoin scaling solution.

Use Cases

Operator Shutdown

The primary use case is protecting against statechain entity failure. If the operator goes offline permanently (due to business closure, infrastructure failure, or regulatory action), every current coin owner can independently broadcast their backup transaction and recover funds after the timelock expires. No coordination between users is required.

Dispute Resolution

If a user suspects the statechain entity is behaving dishonestly (for example, refusing to co-sign transfers or selectively censoring users), the backup transaction provides an unconditional exit. The user does not need the entity's permission or cooperation to leave.

Scheduled On-Chain Settlement

Some users may choose to periodically settle their statechain coins on-chain as a form of consolidation or risk management. Rather than relying on the statechain entity indefinitely, they can broadcast their backup transaction during a period of low fee market activity to minimize on-chain costs.

Risks and Considerations

Transfer Limit

Because each transfer decrements the timelock, a statechain coin has a finite number of transfers before the timelock reaches the current block height. At that point, the coin must be settled on-chain and a new statechain coin created. The size of the decrement determines this limit: larger decrements mean fewer possible transfers but more time between each owner's exit window.

Monitoring Requirement

Although the decrementing timelock gives the current owner priority, they should still monitor the blockchain for broadcasts of older backup transactions. If a previous owner attempts to broadcast an expired backup close to when the current owner's backup becomes valid, the current owner needs to respond promptly by broadcasting their own transaction. This is similar to the watchtower concept in Lightning, where monitoring services watch for revoked states on behalf of users.

On-Chain Fee Exposure

Backup transactions are signed at transfer time with a specific fee rate. If on-chain fees have risen significantly by the time the backup needs to be broadcast, the pre-signed transaction may take a long time to confirm or may not confirm at all. Some implementations address this by using anchor outputs or CPFP to allow fee bumping at broadcast time.

Recovery Data Custody

The backup transaction is only useful if the owner has retained it. Losing the backup data (through device loss, failed backups, or data corruption) means losing the ability to unilaterally exit. Users must treat their statechain backup data with the same care as their seed phrase: stored securely, backed up in multiple locations, and never shared.

Timelock Trade-offs

Shorter timelocks mean faster recovery but fewer possible off-chain transfers before the coin must be settled. Longer timelocks allow more transfers but mean users must wait longer to recover funds in an emergency. Protocol designers must balance these competing concerns based on expected usage patterns.

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.