Statechain Entity (SE)

What Is a Statechain Entity?

A statechain entity is the facilitating server in the statechain protocol, a system for transferring Bitcoin UTXO ownership off-chain without broadcasting transactions to the blockchain. First proposed by Ruben Somsen at Scaling Bitcoin 2018 in Tokyo, statechains work by transferring control of private key shares rather than moving coins on-chain.

The SE holds one share of the private key that controls a Bitcoin UTXO, while the current owner holds the other share. Together, these two shares can produce a valid signature to spend the coins. Individually, neither party can do anything: the SE cannot steal funds, and the user cannot transact off-chain without the SE's cooperation. This 2-of-2 arrangement is what makes statechains non-custodial under normal operation.

The SE's primary responsibilities are straightforward: co-sign transfers only with the current legitimate owner, perform key resharing when ownership changes, and delete old key shares after each transfer. What makes this role unique compared to other Bitcoin infrastructure is that the SE facilitates value transfer without ever having full custody of the funds it helps move.

How It Works

The statechain entity participates in three critical operations: key generation when a user deposits into a statechain, key resharing when ownership transfers, and key deletion after each transfer completes. Each operation relies on collaborative cryptography between the SE and the current user.

Key Generation (Deposit)

When a user wants to deposit Bitcoin into a statechain, they perform a collaborative key generation with the SE:

1. The user and SE each generate their own key share independently
2. They combine their public key shares to produce a shared public key (a standard Bitcoin address) without either party learning the full private key
3. The SE co-signs a backup transaction with a timelock (using nLockTime) that lets the user recover funds on-chain if the SE disappears
4. The user deposits Bitcoin to the shared address

At this point, the UTXO sits on-chain at an address that looks like any other single-key Taproot address. No observer can tell it is controlled by a 2-of-2 key arrangement.

Transfer Process

Transferring statechain ownership is what makes the SE essential. When Alice wants to send her statechain coin to Bob:

1. Alice signals to the SE that she wants to transfer ownership to Bob
2. The SE and Bob perform a key resharing operation: they generate new key shares that correspond to the same aggregate public key
3. A new backup transaction is created for Bob with a shorter timelock than Alice's, ensuring Bob's exit transaction takes priority on-chain
4. The SE deletes the old key share it held that corresponded to Alice
5. Alice's key share becomes useless because the SE's matching share no longer exists

# Simplified statechain transfer flow
# The on-chain UTXO never moves

Deposit:   User_A + SE  →  shared_pubkey (on-chain UTXO)
Transfer:  SE reshares with User_B, deletes old share
           User_A's key share is now orphaned
Result:    User_B + SE  →  same shared_pubkey (same UTXO)

The on-chain UTXO never moves. From the blockchain's perspective, nothing happened. But off-chain, ownership has changed hands. The entire history of previous states is passed to each new owner so they can verify that timelocks have been properly decremented at each step.

Key Deletion

Key deletion is the most critical and most controversial aspect of the SE's role. After each transfer, the SE must destroy its old key share to prevent collusion with previous owners. If the SE retains an old share, it could theoretically work with a previous owner to produce a valid signature and steal the current owner's coins.

The fundamental challenge: key deletion cannot be cryptographically proven. No algorithm exists that lets the SE prove to the world that data has been erased from its memory. Early implementations like Mercury attempted to enforce deletion through Hardware Security Modules (HSMs) that make key extraction physically difficult, though this shifts trust to hardware rather than eliminating it.

FROST and the Distributed Statechain Entity

The unprovability of key deletion is the single biggest limitation of statechains with a solo SE. FROST (Flexible Round-Optimized Schnorr Threshold signatures) addresses this by splitting the SE's key share across multiple independent operators using threshold cryptography.

Instead of one server holding the SE's entire key share, FROST distributes it across n operators where any t can collaborate to produce the SE's portion of a signature. This transforms the trust model from "trust one server" to "trust that at least one operator is honest."

The key properties FROST provides for statechains:

• Distributed key generation: operators collectively generate the SE's key share without any single operator ever knowing the complete share
• Two-round signing: operators produce partial signatures that combine into a single valid Schnorr signature, indistinguishable on-chain from a regular single-key spend
• Share refresh: new key shares can be generated for the same underlying group key without on-chain transactions, making old compromised shares worthless
• Fault tolerance: the system continues operating even if some operators go offline, as long as the threshold is met

For a deeper look at how FROST signing works at the protocol level, see the FROST threshold signatures deep dive.

SE vs. Other Trust Models

The statechain entity occupies a middle ground between fully trustless systems and fully custodial ones. Understanding where it sits relative to other Bitcoin off-chain approaches clarifies its tradeoffs.

Lightning Channel Counterparty

In the Lightning Network, two parties share a payment channel with a 2-of-2 multisig arrangement. The critical difference: Lightning is fully trustless. If your channel counterparty tries to cheat by broadcasting an old state, the justice transaction mechanism lets you claim all channel funds as a penalty.

No equivalent punishment mechanism exists for a misbehaving SE. If the SE colludes with a previous owner, the current owner's only protection is the backup transaction timelock. However, statechains offer something Lightning cannot: transferring ownership of entire UTXOs without creating new on-chain transactions and without the liquidity constraints of payment channels. For a broader comparison, see Lightning vs. Spark.

Fedimint Federation

A Fedimint federation operates with a t-of-n threshold of guardians who collectively hold custody of deposited Bitcoin. Users receive ecash tokens in exchange. The federation is fully custodial: if a majority of guardians collude, they can steal all deposited funds.

The SE model has a meaningful advantage: users always retain a unilateral exit path through backup transactions. In Fedimint, users have no on-chain recourse if the federation refuses to redeem their ecash. As Bitcoin Optech notes, statechains are "less trusted than federated sidechains" because users always retain the ability to spend on-chain without SE permission.

Spark's Approach

Spark, a Bitcoin Layer 2 built on statechain technology, distributes the statechain entity role across multiple independent operators called Spark Operators (SOs). These operators collectively hold one key share using FROST threshold signatures, so no single operator possesses the complete key material needed to co-sign with a user.

This architecture produces a 1-of-n trust model: as long as at least one operator behaves honestly and deletes old key shares when required, user funds remain secure. At launch, Spark operates with two operators (Lightspark and Flashnet), with plans to expand across diverse jurisdictions.

Spark also introduces several innovations beyond the traditional SE model:

• Leaf architecture: unlike traditional statechains that transfer entire UTXOs, Spark uses "leaves" as off-chain partial balance representations within tree structures, enabling arbitrary payment amounts
• Forward security: once a transfer completes and old key shares are destroyed, even a later compromise of all operators cannot reverse finalized transfers
• Lightning compatibility: Spark supports atomic swaps with the Lightning Network, bridging the two off-chain systems
• Unilateral exit: users receive pre-signed exit transactions allowing withdrawal to the Bitcoin base layer at any time without operator cooperation

The Spark documentation defines its SE as "the group of operators that run a Spark, responsible for performing the operations necessary for signing and forgetting past keys." For technical details, see the Spark core concepts documentation.

Use Cases

Off-Chain Bitcoin Transfers

The primary use case for the SE is facilitating off-chain Bitcoin transfers. Users can send entire UTXOs to new owners without on-chain fees or confirmation delays. Each transfer is instant from the participants' perspective, limited only by the speed of the key resharing protocol. This makes statechains particularly efficient for transferring large, fixed-denomination amounts.

Privacy-Preserving Transactions

Because statechain transfers happen entirely off-chain, they leave no trace on the blockchain. The on-chain UTXO appears untouched from deposit to final withdrawal. Implementations like Mercury Layer take this further by blinding the SE: the server never learns the transaction IDs, public keys, or amounts involved in transfers, providing privacy even from the entity facilitating them.

Atomic Swaps Between Layers

The SE can participate in atomic swaps between statechains and other systems. Mercury Layer's Lightning Latch protocol enables trustless exchanges between statechain coins and Lightning payments, using hash-locked coordination so both sides complete or neither does.

Risks and Considerations

Collusion Risk

The most significant risk is SE collusion with a previous owner. If the SE retains an old key share instead of deleting it, the SE and that previous owner together hold enough key material to spend the UTXO. As Somsen noted, the SE would need to "find prior users willing to collude for every UTXO," making large-scale theft difficult but not impossible. Federation via FROST mitigates this: all operators would need to retain their old shares and agree to collude.

Unprovable Deletion

Key deletion is the protocol's central trust assumption, and it cannot be verified cryptographically. Users must trust the SE's infrastructure, operational practices, and incentive alignment. HSMs can make key extraction physically harder, and distributing the SE across multiple operators reduces the risk, but neither approach eliminates the fundamental limitation.

Liveness Dependency

If the SE goes offline, no off-chain transfers can occur. Users retain their funds (they can always broadcast the backup transaction after the timelock expires), but the statechain becomes non-functional until the SE returns. In Spark's multi-operator model, the system remains available as long as the FROST threshold of operators is online.

Timelock Limitations

Each transfer decrements the backup transaction's timelock, giving newer owners shorter exit windows. This limits the number of transfers a statechain coin can undergo before it must be settled on-chain and re-deposited. A coin that has been transferred many times gives its current owner a very short window to exit, which may be insufficient if the Bitcoin network is congested.

Censorship

The SE can refuse to cooperate on specific transfers, effectively censoring certain users or transactions. While users can always exit on-chain via their backup transaction, they cannot force the SE to process off-chain transfers. Distributing the SE across multiple independent operators in different jurisdictions reduces this risk.

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.