Skip to content
Blockchain LabTHE VENTURE STUDIO

LibraryInteroperability2017Design paperCorpus record

Sprites and State Channels

Sprites. Andrew Miller, Iddo Bentov, Sandeep Bakshi, Ranjit Kumaresan and Patrick McCorry.

State channels whose disputes do not have to hop one channel at a time. A global preimage manager lets a payment resolve in constant time on-chain. Lightning did not adopt this design as its production path.

Sprites are state channels that settle a dispute in constant time by publishing the preimage once, in a shared contract, instead of hopping the timeout from channel to channel as Lightning-style hash locks do.

The five-minute read

The cascade is the problem

On a multi-hop hash-locked route, each hop's timeout must be longer than the next, so a dispute at the end has time to walk back to the start. The route's length becomes waiting time and locked capital.

One preimage manager

Sprites put the preimage in a contract every channel can read. A dispute does not re-prove the payment at every hop. The on-chain work does not grow with the route.

Channels still need deposits

The paper does not create liquidity. It changes the dispute. Someone must still have locked value in each channel before any payment can be forwarded.

Lightning did not become Sprites

Production Lightning kept HTLCs and their staggered timeouts. Sprites are the alternative design, not a description of the Lightning specification.

One action, walked through

  1. Parties open a channel by locking funds in a contract and exchanging signed states off-chain.
  2. A multi-hop payment is a set of conditional updates, one per channel, tied to the same preimage.
  3. If everyone cooperates, the preimage moves off-chain and every hop updates to the new state.
  4. If someone stalls, any party can publish the preimage once to the manager contract.
  5. Each channel's dispute uses that published preimage and resolves without waiting for the neighbour's dispute to finish first.

The argument, unpacked

Constant time is an on-chain measure

The paper means the number of dispute rounds does not grow with the number of hops. Users can still wait for confirmations, and the channel can still be griefed. Constant is not instant, and it is not free.

A shared contract assumes a shared ledger

The manager works because every channel can read it. Two channels on two chains do not have that manager unless a third construction, which the paper is not, carries the preimage across. Cross-chain sprites are a different problem.

What has to be true

  • Channels live where the preimage manager is visible.
  • Parties monitor the chain or hire someone who does. A missed dispute can finalise an old state.
  • Deposits cover the in-flight payment. The dispute trick does not extend credit.
  • The on-chain contract matches the off-chain state machine. A mismatch decides disputes against the honest party.

What happened after the paper

Lightning standardised a different hash-lock construction and accepted staggered timeouts, then worked on them with other tools. Sprites remain the citation for constant-round channel disputes. A network that claims Lightning-compatible payments has not implemented this paper merely by having channels.

What to check before you use the idea

  • Does dispute time grow with the number of hops?
  • Where is the preimage published, and can every channel see it?
  • Who watches the chain for a dishonest close?
  • Are the channels on one ledger?

Terms

State channel
A contract that holds funds while the parties exchange signed updates off-chain and settle on-chain only in a dispute or at close.
Preimage manager
A shared contract that records one secret so every channel can resolve against it.

The problem the paper names

In a hash-locked payment network, a dispute or a timeout can cascade along the route. Each hop waits for the next. Sprites collapse that cascade into one on-chain object.

What the design proposes

  • Parties update signed state off-chain.
  • A contract records the preimage once, and every affected channel can read it.
  • Collateral and timeouts are still required. The paper does not delete them.

How the mechanism is specified

  • Constant-time disputes are about the number of on-chain rounds, not about instant user experience.
  • The manager is a common contract. That assumes the channels live where that contract can be seen.
  • Cross-chain sprites are harder, because there is no single contract both chains read.

What this page does not treat as proven

  • This is not the Lightning specification. Lightning's HTLC route is a different paper.
  • Channels still require capital locked in advance. Routing liquidity is not solved by the dispute trick.
  • An on-chain dispute reveals state that the channel was built to keep off the ledger.

Why a venture studio still reads it

Ask how many on-chain rounds a failed payment takes, and where the preimage is published. If the answer depends on the length of the route, it is not Sprites.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.