Statechains

A statechain transfers ownership of a UTXO off-chain without moving funds on chain. Each transfer is signed by the current owner

• a Statechain Operator (SO).

Original concept: Ruben Somsen, 2018. The reference implementation is Mercury Layer, built by CommerceBlock and redesigned around blinded MuSig2 in January 2024; whether it is still running is unverified as of September 2026 (below).

Mechanism

A statechain UTXO is locked in 2-of-2 multisig with:

• The current owner.
• The Statechain Operator.

In Somsen's 2018 design the transfer is unblinded: A reveals its key share to recipient B, the SO signs a transfer message naming B as the new owner, and once B confirms receipt the SO will no longer sign for A. Mercury Layer replaces that with a blinded key update (per its protocol spec; repo last updated January 2025, read September 2026):

1. Owner A sends B, encrypted, the chain of signed backup txs plus a blinded transfer value t1 = o1 + x1, where x1 is a random the SO supplied. B never learns A's raw share o1.
2. B validates that chain client-side, then sends the SO t2 = t1 - o2.
3. The SO updates its own share to s2 = s1 + t2 - x1 and deletes s1. The aggregate key P is unchanged.
4. The SO publishes its new public key share and the number of times it has signed for that statechain. It does not publish a transfer log: it is blind to what it signed.

Result: UTXO ownership has moved from A to B without on-chain tx.

Security model

• Trust the SO not to collude with prior owners.
• Worst case: SO + A collude to spend the UTXO, defrauding B.
• Mitigation (Mercury Layer): the SO publishes only its own public key share and a count of how many times it has signed for that statechain. The receiver checks that count against the number of backup txs the sender handed over and re-verifies every signature and timelock decrement itself. Equivocation is caught by the receiver before accepting, not by auditors reading a public log — and the check is worthless if a receiver skips it.

Mercury Layer

Built by CommerceBlock. Provenance is murky as of September 2026: commerceblock/mercurylayer — still the only GitHub link on mercurylayer.com — 404s, as does the commerceblock org. A copy of the tree survives at mercury-layer/mercurylayer, but that is a fork (of the likewise-404ing 22388o/mercurylayer) with no stars and no push since January 2025; treat mercurylayer.com as the source of record.

Liveness is unconfirmed too. The project does publish operator endpoints: mercurylayer.com's "Status" button points at https://api.mercurylayer.com, and docs.mercurylayer.com documents a signet key server at http://test.mercurylayer.com:8500 (statechain_entity = "https://test.mercurylayer.com"). Both hosts still resolve in DNS — 192.248.157.233 and 45.76.136.11 — but answer nothing on any port tried (443, 80, 8500), while a control fetch of mutinynet.com, the electrum server those same docs configure, returns 200. mercurywallet.com, the earlier Mercury client's domain, no longer resolves at all (DNS SERVFAIL). All checked 16 September 2026. Do not tell a reader Mercury is running; tell them to reach an operator themselves first.

The implementation:

• Open source (GPL-3.0, per the repo README).
• Blinded: since the January 2024 redesign the SO co-signs via blinded MuSig2 and learns nothing about what it signs — not the TXID, not the aggregate public key, not the final signature. It cannot tell a cooperative withdrawal from an onward transfer.
• SO runs a server (key shares held in an Intel SGX enclave), users a client.
• Atomic swaps between statechains supported.
• Liquidity offered for trading without on-chain settlement.

Compared to Spark / Ark

Spark and Ark are statechain-derived but with stronger security (threshold operators, no single point of failure for SO).

Use cases

• Off-chain instant settlement between participants.
• Atomic swaps across statechains (e.g., BTC ↔ LBTC).
• DEX-like UTXO trading.

Limitations

• 1-of-N trust on SO.
• Single SO availability = single point of failure.
• Not as scalable as Lightning for high-frequency micropayments.

Covenant proposals that affect statechains

BIP448 "Taproot-native (Re)bindable Transactions" (Draft; BIP number assigned 2026-03-11; Sanders, Poinsot, Roose) bundles three tapscript opcodes: OP_TEMPLATEHASH (BIP446, redefines OP_SUCCESS206), OP_CHECKSIGFROMSTACK (BIP348, OP_SUCCESS204) and OP_INTERNALKEY (BIP349, OP_SUCCESS203). Its motivation section names this topic directly: the rebindable signatures the bundle enables make LN-Symmetry ("Eltoo") possible, and that construction's simplicity "can substantially improve statechains". Activation is "left to be determined at a later date" (BIP text, read September 2026).

What it would change here: a rebindable statechain replaces the decrementing-timelock backup chain with Eltoo-style state replacement. That removes the bounded-exit problem but adds a watchtower requirement — the prototype below warns that if a prior owner publishes an old state, "you or a delegated watcher have 144 blocks to broadcast the newer saved state".

A proof of concept exists, on test networks only. The rebindable_statechains branch of stutxo/mercurylayer (a fork of the Mercury tree, last pushed September 2026) funds each statechain to a Taproot output with internal key P and the single leaf OP_TEMPLATEHASH OP_INTERNALKEY OP_CHECKSIGFROMSTACK, against a pinned Bitcoin Inquisition revision; a browser wallet demo runs on Mutinynet at bip448.cash and labels itself "a Mutinynet research prototype ... not a production wallet". BIP448 is not active on mainnet as of September 2026.

See also

• spark/SKILL.md
• ark/SKILL.md
• ../../cryptography/musig2/SKILL.md
• ../../protocol/proposals/SKILL.md