Statechains

What Are Statechains?

Statechains are a Bitcoin Layer 2 protocol that enables off-chain transfer of UTXO ownership without broadcasting transactions to the blockchain. Instead of moving coins on-chain, statechains transfer the private keys that control those coins. A semi-trusted intermediary called a statechain entity co-signs transactions and tracks ownership, but cannot unilaterally move or freeze the underlying Bitcoin.

The concept was first presented by Bitcoin developer Ruben Somsen at Scaling Bitcoin 2018 in Tokyo, with a detailed write-up published in June 2019. Somsen designed statechains to address Bitcoin's scalability limitations: by keeping transfers off-chain, statechains can process an unlimited number of ownership changes from a single on-chain funding transaction. For a broader comparison of Bitcoin scaling approaches, see the Layer 2 comparison research article.

How It Works

Statechains rely on three core mechanisms: a 2-of-2 multisig arrangement, transitory key transfer, and pre-signed backup transactions with decrementing timelocks.

Setting Up a Statechain

1. The user and the statechain entity each generate a key. Together, these form a 2-of-2 multisig address using Taproot.
2. Before depositing any Bitcoin, the user obtains a pre-signed backup transaction from the SE. This backup transaction is timelocked far into the future and allows the user to withdraw on-chain without SE cooperation.
3. The user deposits Bitcoin into the 2-of-2 multisig address. The UTXO is now on the statechain.

Transferring Ownership

When Alice wants to transfer her statechain UTXO to Bob, no on-chain transaction is needed. Instead:

1. Alice sends her private key (the "transitory key") to Bob through a secure channel.
2. Bob generates a new backup transaction with a shorter timelock than Alice's, and the SE co-signs it.
3. The SE updates its records to recognize Bob as the current owner and deletes its previous key share associated with Alice.
4. Alice can no longer spend the UTXO because the SE will only co-sign with Bob going forward.

This process happens instantly and costs nothing in transaction fees. The key rotation effectively transfers full control of the UTXO without touching the blockchain.

Decrementing Timelocks

Each transfer creates a new backup transaction with a shorter timelock than the previous owner's. This ensures the current owner can always claim funds on-chain before any previous owner:

# Timelock progression across transfers
Owner 1 (Alice):  backup tx with nLocktime = block 900,000
Owner 2 (Bob):    backup tx with nLocktime = block 899,000
Owner 3 (Carol):  backup tx with nLocktime = block 898,000

# Carol's backup becomes valid first, preventing
# Alice or Bob from claiming with older backups

This approach works without any Bitcoin consensus changes, but it limits the total number of transfers before the statechain must be settled on-chain. Once the timelock decrements to near the current block height, the UTXO must be redeemed.

The original statechain design proposed using eltoo (LN-Symmetry) instead, which would allow unlimited transfers by letting newer state updates overwrite older ones. However, eltoo requires the SIGHASH_ANYPREVOUT soft fork, which has not been activated on Bitcoin as of 2026.

Blind Signing

Mercury Layer, the primary statechain implementation, uses a blinded variant of Schnorr MuSig2 signing. The SE co-signs transactions without learning:

• The transaction IDs involved
• The public keys of the participants
• The final unblinded form of any signatures it generates
• Any details about backup or closure transactions

This privacy enhancement means the SE operates as a blind co-signer: it facilitates key rotation and signs when asked, but has no visibility into what it is signing or who is involved.

The Trust Model

Statechains occupy a middle ground between fully trustless protocols like the Lightning Network and custodial solutions. Somsen describes the model as "pro-actively non-custodial": the SE cannot steal funds as long as it behaves correctly.

The critical trust assumption is that the SE deletes old key shares after each transfer. If it retains a previous key share and colludes with a former owner, they could jointly sign a transaction to steal the current owner's funds. Several mitigations reduce this risk:

• The SE can be structured as a federation (for example, an 8-of-12 threshold), requiring a supermajority to collude
• Each UTXO has a different transitory key and different set of prior owners, so compromising one UTXO does not affect others
• The chain of signed transfer messages provides cryptographic evidence if the SE participates in theft
• Users always retain a pre-signed backup transaction for unilateral on-chain withdrawal, regardless of SE behavior

Use Cases

Zero-Fee Bitcoin Transfers

Statechains enable unlimited off-chain transfers of Bitcoin UTXOs without any transaction fees. For users transferring fixed amounts repeatedly, statechains eliminate the fee overhead entirely. This is particularly valuable during periods of high on-chain fee pressure, when even simple Bitcoin transactions can cost tens of dollars.

Lightning Channel Transfers

Entire Lightning channels can be transferred off-chain using statechains. Instead of closing a channel and opening a new one (which requires two on-chain transactions), the channel funding UTXO can be transferred via a statechain. This reduces the cost and time of Lightning liquidity management.

Atomic Swaps with Fixed Denominations

Statechains can facilitate atomic swaps between users holding UTXOs of different values. Two parties can exchange statechain UTXOs of different denominations, or swap statechain ownership for Lightning payments, creating bridges between Layer 2 protocols.

Privacy-Enhanced Transfers

Because statechain transfers happen entirely off-chain, they leave no trace in the blockchain. Combined with Mercury Layer's blind signing, even the statechain entity cannot link transfers to specific users or amounts. This provides stronger privacy than standard on-chain Bitcoin transactions, which are visible to anyone running a node.

Mercury Layer

Mercury Layer, developed by CommerceBlock, is the primary implementation of the statechain protocol. Released in January 2024 as a successor to the earlier Mercury Wallet (2021), it is delivered as a library and CLI tool for wallet integration rather than a standalone consumer wallet.

Mercury Layer introduces blind signing through blinded Schnorr MuSig2, making the server completely unaware of the Bitcoin transactions it helps sign. The server generates a private key share during setup and updates it via multiparty computation during each transfer, deleting the previous share. Clients are responsible for verifying the correctness of all prior backup transactions in the ownership chain.

# Mercury Layer statechain lifecycle
# 1. Deposit: create 2-of-2 Taproot address
#    User key + Server key share → aggregated public key
# 2. Transfer: rotate server key share to new owner
#    Server updates auth_pubkey, deletes old share
# 3. Withdraw: cooperative close or unilateral backup tx
#    On-chain settlement returns funds to current owner

How Spark Builds on Statechains

Spark extends the statechain model to address its primary limitation: fixed UTXO denominations. Where traditional statechains can only transfer entire UTXOs, Spark introduces a "leaves" architecture:

• Root: the on-chain UTXO locked in a multisig with permanently destroyed operator keys
• Branches: internal transactions connecting the root to individual leaves
• Leaves: terminal transactions owned by users, each with relative-timelock exit paths for self-custodial withdrawal

This tree structure enables arbitrary-amount transfers while maintaining the core statechain security model of key rotation and pre-signed backup transactions. Spark also replaces the single statechain entity with a distributed operator set using FROST threshold signatures, reducing the trust placed in any single party. For a deeper exploration, read the statechains scaling deep dive.

Statechains vs. Other Layer 2 Solutions

For more detail on how these approaches compare, see the Bitcoin second-layer scaling landscape and the sidechain and state channel glossary entries.

Risks and Considerations

Statechain Entity Collusion

The primary risk is SE collusion with a previous owner. If the SE retains old key shares instead of deleting them, it could cooperate with a former owner to sign a transaction stealing the current owner's funds. While federating the SE across multiple parties mitigates this, the trust assumption remains: users must believe the SE operates honestly.

Fixed Denomination Constraint

Traditional statechains transfer entire UTXOs. If you deposit 0.5 BTC into a statechain, you can only transfer exactly 0.5 BTC. You cannot split it into smaller amounts or combine multiple statechain UTXOs. This limits practical use cases, particularly for everyday payments. Protocols like Spark address this limitation with their leaves architecture.

Transfer Count Limits

With decrementing timelocks, each transfer reduces the remaining timelock window. After enough transfers, the timelock approaches the current block height and the UTXO must be settled on-chain. This creates an expiration deadline for each statechain UTXO, requiring periodic on-chain settlement.

Entity Availability

If the SE goes offline or loses its key, new transfers become impossible. Users can still withdraw on-chain using their pre-signed backup transaction, but they must wait for the timelock to expire. During high-value or time-sensitive operations, this delay could pose significant risk.

Limited Adoption

Despite the technical elegance of the protocol, pure statechain implementations like Mercury Layer have seen limited real-world adoption. The fixed denomination constraint and the semi-trusted model have made it difficult to compete with more flexible Layer 2 solutions. However, the core concepts have proven influential: Spark and other protocols build on statechain primitives to deliver more practical scaling solutions.

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.