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.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 4
- Records linked
- 3
Code
Source, repository, and what is actually hosted
- arXiv:1702.05812https://arxiv.org/abs/1702.05812
- The source URL is not a GitHub repository. No code remote is invented.
- Full text is not mirrored. Public availability is not a licence to copy the file onto this site.
- Add to a reading list
01 Claim ledger
What the paper is allowed to say
Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.
Claim 01 · Paper model
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.
Claim 02 · Paper model
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.
Claim 03 · Paper model
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.
Claim 04 · Paper model
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.
02 Three cuts
Observation, model, falsifier
A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.
01 The cascade is the problem
Observation
What the study says
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.
Model
What has to hold
Parties monitor the chain or hire someone who does. A missed dispute can finalise an old state.
Falsifier
What would retire it
Does dispute time grow with the number of hops?
02 One preimage manager
Observation
What the study says
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.
Model
What has to hold
The on-chain contract matches the off-chain state machine. A mismatch decides disputes against the honest party.
Falsifier
What would retire it
Where is the preimage published, and can every channel see it?
03 Channels still need deposits
Observation
What the study says
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.
Model
What has to hold
Deposits cover the in-flight payment. The dispute trick does not extend credit.
Falsifier
What would retire it
Does dispute time grow with the number of hops?
04 Lightning did not become Sprites
Observation
What the study says
Production Lightning kept HTLCs and their staggered timeouts. Sprites are the alternative design, not a description of the Lightning specification.
Model
What has to hold
The on-chain contract matches the off-chain state machine. A mismatch decides disputes against the honest party.
Falsifier
What would retire it
Are the channels on one ledger?
03 Sequence
One action, as an operating tape
- 01Parties open a channel by locking funds in a contract and exchanging signed states off-chain.
- 02A multi-hop payment is a set of conditional updates, one per channel, tied to the same preimage.
- 03If everyone cooperates, the preimage moves off-chain and every hop updates to the new state.
- 04If someone stalls, any party can publish the preimage once to the manager contract.
- 05Each channel's dispute uses that published preimage and resolves without waiting for the neighbour's dispute to finish first.
04 Load-bearing
The argument, and where a pitch drops it
Constant time is an on-chain measure
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
Channels still require capital locked in advance. Routing liquidity is not solved by the dispute trick.
A shared contract assumes a shared ledger
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
This is not the Lightning specification. Lightning's HTLC route is a different paper.
05 Register
What has to be true
Model · Not re-measured
Channels live where the preimage manager is visible.
Model · Not re-measured
Parties monitor the chain or hire someone who does. A missed dispute can finalise an old state.
Model · Not re-measured
Deposits cover the in-flight payment. The dispute trick does not extend credit.
Adversary · Not re-measured
The on-chain contract matches the off-chain state machine. A mismatch decides disputes against the honest party.
06 Divergence
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.
A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.
07 Pre-mortem
What to check before you use the idea
- 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.
08 Anatomy
The paper, in the order a builder needs
The problem it 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
Why the desk 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.
09 Lexicon
Terms, opened into the record
- 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.
10 Repository
Every linked record on this page
Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.
Concepts
Protocols
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.