Bitcoin Statechains Explained

The construction begins with a single on-chain output that is controlled by a key which is split between the owner and a statechain entity. Neither party holds the whole key, so neither can spend the output alone. The output stays where it is; what changes over time is who the owner is and what share of the key they hold.

To transfer ownership, the current owner and the entity cooperate to produce a new key share for the incoming owner and to re-sign the output so that it is controlled by the new owner together with the entity. The outgoing owner's share is supposed to be deleted. If the deletion actually happens, the outgoing owner can no longer participate in a spend, and the incoming owner holds the only share that matters. The transfer is complete without any on-chain transaction, which is the source of the design's efficiency claim: an arbitrary number of ownership changes can occur against a single output.

The output is eventually spent on-chain, either by the current owner cooperating with the entity or, if the entity is unresponsive, by the owner after a timelock expires. The timelock is the escape hatch: it guarantees that a cooperative entity cannot freeze the funds permanently, because the owner can always wait and then spend unilaterally. The design's own documentation describes the key sharing, the re-signing procedure and the timelock path in more detail than is possible here.

Everything above depends on the outgoing owner genuinely destroying their key share. If they keep a copy, they retain the ability to cooperate with the entity — or to collude with it — and spend an output they no longer own. The design cannot enforce deletion, because deletion happens inside a party's own software and on their own hardware. It is an assumption about behaviour, not a property the protocol can verify.

This is the sharpest difference between statechains and a construction like Lightning. A Lightning channel's security argument rests on penalties that are enforced by the blockchain: a party that broadcasts an outdated state can be punished by a revocation transaction that takes their funds. A statechain's security argument rests on a party choosing to forget something. The first is verifiable by anyone reading the chain; the second is not verifiable by anyone.

The design's response is that the assumption is reasonable in practice for a cooperative entity with a reputation to protect, and that the timelock limits the damage an unresponsive entity can do. That may be a fair judgement, but it is a judgement about incentives rather than a cryptographic guarantee, and a reader evaluating the proposal should weigh it as such. The proposal's own discussion acknowledges the assumption rather than hiding it.

The efficiency case is genuine. Because ownership changes do not touch the chain, a statechain can move an output many times for the cost of one on-chain transaction, and the transfers are not visible to anyone watching the chain. That is a meaningful improvement over an on-chain transfer for the specific case of moving ownership without changing the underlying output, and it is why the proposal has continued to attract attention.

The costs are equally real. The entity is a liveness dependency: if it disappears, the owner must wait out the timelock before spending, and during that wait the funds are not usable. The entity also learns the history of ownership, because it participates in every transfer, which is a privacy cost that an on-chain transfer does not have. And the key-deletion assumption means the security model is weaker than a construction whose penalties are enforced on-chain.

There are also questions the proposal does not fully settle. What happens if the entity and a former owner collude is the obvious one, and the answer depends on the deletion assumption holding. How the entity is compensated, and whether that compensation creates an incentive to behave badly, is another. These are the questions a reader should carry away from any description of statechains: the design is interesting precisely because its trade-offs are explicit, and it should be evaluated on those trade-offs rather than on the efficiency claim alone.