Timechain Wiki

Statechains

8 min read

Statechains are an off-chain UTXO-transfer architecture that allows ownership of a specific Bitcoin UTXO to be transferred between parties without an on-chain transaction. The mechanism uses a coordinator (the "statechain entity") plus a signer-rotation protocol: each successive owner generates a key share, the entity participates in a 2-of-2 multisig with the current owner, and the UTXO stays in the same on-chain address while only the key shares rotate. The trust profile is bounded: the entity could in principle collude with a prior owner to broadcast an old commitment, but the current owner can broadcast their own commitment immediately to recover the funds. The architecture was proposed by Ruben Somsen in 2018 and implemented in production by CommerceBlock's Mercury Wallet (operational 2020–present), and statechain UTXOs can additionally support Lightning channels on top. Adoption has remained niche relative to Lightning, but the architecture occupies a distinctive Layer-2 position: off-chain UTXO ownership transfer with privacy properties Lightning and Liquid do not match.

Why this note matters

Statechains illustrate a fundamentally different Layer-2 architecture from channel networks (Lightning) and federated sidechains (Liquid). Where Lightning maintains state between two channel participants and Liquid maintains state on a separate chain, statechains transfer ownership of a single base-layer UTXO between many sequential owners without changing the on-chain transaction.

The architecture is conceptually clean and has specific privacy advantages — but has not achieved Lightning-scale deployment. Understanding why illuminates the broader Layer-2 design-space and the practical constraints (UX, liquidity, ecosystem support) that shape which architectures succeed beyond their design merits.

The construction

A statechain consists of a single base-layer UTXO, a statechain entity (the coordinator), and a sequence of owners. The UTXO is locked to a 2-of-2 multisig between the entity and the current owner. Ownership transfer proceeds:

  1. Initial setup. Alice deposits Bitcoin into a 2-of-2 multisig with the statechain entity. Alice generates a key share; the entity generates its key share; the combined public key controls the UTXO. Alice can spend the UTXO at any time by signing with her key share and obtaining the entity’s signature.
  2. Backup commitment. At setup, Alice and the entity construct a signed-but-unbroadcast “backup transaction” that returns the UTXO to Alice unilaterally if she chooses to exit the statechain. This backup is the safety net.
  3. Transfer to Bob. Alice wants to transfer ownership to Bob. Alice generates a transfer message: she signs over her statechain control to Bob, and the entity rotates its key share to be compatible with Bob’s new key. The on-chain UTXO does not change. Bob is now the current owner; Alice is no longer.
  4. Bob’s new backup commitment. Bob and the entity construct a new backup transaction that returns the UTXO to Bob if he chooses to exit.
  5. Backup-transaction generations. Each transfer produces a new backup; prior backups remain technically valid but are “stale” — the entity will sign against the most recent backup, not older ones.

The structural trust assumption. The statechain entity could in principle collude with a prior owner (say Alice, who is no longer the current owner) to broadcast Alice’s backup transaction. If Alice’s backup confirms before Bob can broadcast his own backup, Alice would receive the funds despite no longer being the legitimate owner.

The defense. Bob can broadcast his own backup transaction at any time. If Bob is online and watching, Bob’s broadcast supersedes Alice’s. If Bob is offline during a malicious-collusion event, Alice could win the race.

The race window. The mechanism’s safety depends on Bob being online during the relative-timelock window of the backup transactions (the design parameter; typical values are similar to Lightning’s to_self_delay). Statechains inherit a Lightning-like online-requirement that watchtowers (for statechains, a similar architecture) could potentially address.

The Mercury Wallet implementation

CommerceBlock’s Mercury Wallet is the production implementation of statechains. Mercury launched in 2020 and has remained operational. The Mercury statechain entity is operated by CommerceBlock as a single-operator (not federated) coordinator.

Mercury’s specific design choices:

  • Single-operator entity. Mercury Wallet’s statechain entity is CommerceBlock; there is no federation. The trust profile is “trust CommerceBlock as a single party plus the timelock-based backup mechanism.”
  • Fixed UTXO sizes. Mercury supports specific UTXO sizes (typically 0.01, 0.1, 1.0 BTC) rather than arbitrary sizes. The size restriction is for liquidity-and-mixing reasons.
  • Coin-swap as transfer. Mercury operations include atomic-coin-swap protocols that allow privacy-improving exchange of statechain UTXOs between users. Coin-swaps are a privacy-enhancing layer above the basic transfer protocol.
  • Lightning integration. Mercury statechain UTXOs can be used as funding for Lightning channels, producing layered statechain-and-Lightning constructions.

Mercury’s deployment is small. Total statechain UTXO supply is a few thousand BTC equivalent; many fewer users than Lightning. Its user base is privacy-focused and operationally-sophisticated.

Privacy properties

Statechain ownership transfer does not appear on the base-layer chain. From an outside observer’s perspective, the UTXO is a single multisig output controlled by a single owner; transfers between owners are invisible to chain analysis.

The privacy improvements over base-layer transfer:

  • No on-chain transaction during ownership transfer. Chain-analysis cannot directly trace ownership transfer between statechain users.
  • Coin-swap atomicity (when used) further obscures the linkage between input and output UTXOs in a privacy-enhancing way.
  • Address-reuse not required. The statechain UTXO’s base-layer address does not change over the statechain’s life, but this is the multisig address that controls the UTXO; it does not reveal owner identity directly.

The privacy limitations:

  • The statechain entity sees ownership transfers. The entity coordinates the transfer; the entity therefore knows who-transferred-to-whom. The entity is the privacy-trust bearer; if the entity is compromised or coerced, the transfer log is potentially exposed.
  • Out-of-band metadata. Statechain users typically need to communicate transfer information; the communication channel can leak metadata if not designed carefully.
  • The on-chain footprint exists. The original deposit transaction is on-chain and links the initial owner to the statechain UTXO. Subsequent transfers do not appear, but the initial entry does.

The privacy profile is meaningfully better than base-layer transactions for transfer-between-users but weaker than the cryptographic-anonymity of mixing protocols. The holder must trust the entity for transfer privacy.

Tradeoffs and design choices

Single-operator entity vs federated entity. Mercury’s single-operator design has UX advantages (faster transfers; simpler coordination) but inherits all the trust-concentration concerns of single-operator systems. A federated statechain entity (analogous to Liquid) would distribute trust but add coordination complexity. The Mercury choice prioritized deployability.

Online requirement for ownership safety. The backup-transaction mechanism requires the current owner to be online during the timelock window when a malicious prior owner might broadcast. This is structurally similar to Lightning’s online requirement. A statechain-watchtower architecture is conceivable but has not been deployed at scale.

Fixed UTXO sizes vs arbitrary sizes. Fixed sizes improve mixing-anonymity (all statechain UTXOs of a given size are interchangeable) but constrain flexibility. Arbitrary sizes are more flexible but less private. Mercury chose fixed sizes for the privacy-and-mixing benefit.

Entity-as-privacy-trust-bearer. The statechain entity knows the transfer history. Users who require entity-level privacy from the coordinator are not served by the statechain model.

Limited Lightning integration in practice. Statechain-Lightning constructions are technically possible but have not achieved deployment. The composition is operationally complex and inherits both online-requirements.

Substantive analytical critique of statechain trust models lives in Custody concentration risks (federation-vs-single-operator-vs-trust-minimized) and the broader Layer-2 design-space conversation.

Open questions for further development

  • Will statechains expand beyond Mercury’s deployment, or remain a niche architecture? The conceptual elegance is real; the deployment momentum has favored Lightning and (lately) ARK proposals.
  • Can statechain watchtowers achieve broad deployment? The protocol-level need is real but the ecosystem-level demand has been low.
  • How does statechain composition with Lightning evolve? Layered architectures are technically interesting; deployed adoption has been minimal.
  • What is the equilibrium between statechain entity centralization and trust-distribution? Mercury’s single-operator model has worked operationally; federated statechain entities have not been deployed at meaningful scale.
  • How do covenant-enabling soft forks (OP_CTV; CHECKSIGFROMSTACK) affect statechain designs? Covenant-light statechain constructions could meaningfully reduce trust requirements.

Canonical sources for this note

Foundational design

  • Ruben Somsen, “Statechains: Off-chain Transfer of UTXO Ownership” (2018) — original statechain proposal: blog.coinos.io and bitcoin-dev mailing list
  • CommerceBlock Mercury Wallet documentation: mercurywallet.com and github.com/commerceblock/mercury

Adjacent designs

  • Bryan Bishop, “Statechains and the Channel Factory” — adjacent off-chain construction
  • Various academic papers on coin-swap and Mercury-specific privacy improvements

Graph View

Backlinks