LibraryConsensus2016Design paperCorpus record
SPECTRE: A Fast and Scalable Cryptocurrency Protocol
SPECTRE. Yonatan Sompolinsky, Yoad Lewenberg and Aviv Zohar.
Blocks form a DAG and vote pairwise on which of two blocks came first. In the common case that vote settles quickly. The paper does not promise a total order of every pair, which is why it is a poor fit for general contracts.
SPECTRE lets blocks vote, pairwise, on which of two blocks happened first. Payments that do not conflict can confirm quickly. Pairs that stay contentious are not forced into a total order.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 4
- Records linked
- 3
Code
Source, repository, and what is actually hosted
- ePrint 2016/1159https://eprint.iacr.org/2016/1159
- 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 DAG is a ballot
Every new block is a vote on earlier conflicts, according to which block it saw first in its history. Votes are recursive, so a block's ballot depends on the ballots that follow it.
Claim 02 · Paper model
Robustness is the margin
A payment is accepted when every block that conflicts with it loses the vote by a margin the paper treats as stable. A thin margin is not a confirmation.
Claim 03 · Paper model
No total order, on purpose
Two honest transactions that do not conflict do not need to be serialised. That is the throughput. It is also why a virtual machine that needs one global sequence cannot live here without extra rules.
Claim 04 · Paper model
PHANTOM is the reply
The same research line later imposed a linear order and paid for it with a different parameter. Citing SPECTRE for a smart-contract chain mixes the two papers.
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 DAG is a ballot
Observation
What the study says
Every new block is a vote on earlier conflicts, according to which block it saw first in its history. Votes are recursive, so a block's ballot depends on the ballots that follow it.
Model
What has to hold
Conflicts are detectable. A ledger that cannot say when two transactions fight cannot run the vote.
Falsifier
What would retire it
Does the system require a total order of all transactions?
02 Robustness is the margin
Observation
What the study says
A payment is accepted when every block that conflicts with it loses the vote by a margin the paper treats as stable. A thin margin is not a confirmation.
Model
What has to hold
Conflicts are detectable. A ledger that cannot say when two transactions fight cannot run the vote.
Falsifier
What would retire it
What margin does a merchant demand before treating a payment as accepted?
03 No total order, on purpose
Observation
What the study says
Two honest transactions that do not conflict do not need to be serialised. That is the throughput. It is also why a virtual machine that needs one global sequence cannot live here without extra rules.
Model
What has to hold
Conflicts are detectable. A ledger that cannot say when two transactions fight cannot run the vote.
Falsifier
What would retire it
Does the system require a total order of all transactions?
04 PHANTOM is the reply
Observation
What the study says
The same research line later imposed a linear order and paid for it with a different parameter. Citing SPECTRE for a smart-contract chain mixes the two papers.
Model
What has to hold
The network delivers the DAG. A vote cannot count a block nobody saw.
Falsifier
What would retire it
Is the implementation SPECTRE, or a later linearisation?
03 Sequence
One action, as an operating tape
- 01Users publish transactions. Miners publish blocks that reference every tip they have seen.
- 02To compare two blocks, the protocol tallies how the rest of the DAG votes.
- 03A merchant accepts a transaction when its block beats all conflicting blocks in that tally.
- 04If a later attack narrows the margin, acceptance is withdrawn. The paper is explicit that confirmation is not a one-way door in every case.
- 05Non-conflicting transactions do not wait for each other.
04 Load-bearing
The argument, and where a pitch drops it
Payments and programs want different objects
The cut
A payment needs to beat its own double-spend. A program needs every call ordered against every other call. SPECTRE is built for the first. Using it for the second requires a layer the paper does not provide.
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
Do not cite SPECTRE as a scheduler for an account-based virtual machine.
Speed is conditional
The cut
The fast case is an honest majority and a visible DAG. A withheld competing block is exactly the case the vote has to survive. The paper does not say every transaction confirms in a second.
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
The paper is not a deployed network and not PHANTOM's linear order.
05 Register
What has to be true
Adversary · Not re-measured
Honest miners publish blocks that reference the honest DAG, not a private fork.
Model · Not re-measured
Conflicts are detectable. A ledger that cannot say when two transactions fight cannot run the vote.
Stake and threshold · Not re-measured
Merchants choose a risk threshold. The protocol does not ship one true number of confirmations.
Network · Not re-measured
The network delivers the DAG. A vote cannot count a block nobody saw.
06 Divergence
What happened after the paper
SPECTRE remained a research protocol. PHANTOM/GHOSTDAG took the DAG idea toward a linear order used later by Kaspa's line. Production smart-contract chains did not adopt pairwise voting. The paper is still the clean statement of what you give up when you refuse a total order.
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
Longest-chain confirmation waits because a fast block rate creates forks. SPECTRE treats the DAG as a vote. Honest blocks vote for the block they saw first, recursively.
What the design proposes
- Publish blocks that reference all known tips.
- Between two conflicting blocks, the rest of the DAG votes.
- Accept a payment when its block beats the competitors by a robust margin.
How the mechanism is specified
- The vote is recursive: a block's vote depends on the votes of blocks that follow it.
- Some pairs can remain unordered if the vote is too close. Payments that conflict wait. Payments that do not conflict need not be serialised against each other.
- That last property is the throughput claim and the smart-contract limitation.
What this page does not treat as proven
- Do not cite SPECTRE as a scheduler for an account-based virtual machine.
- The paper is not a deployed network and not PHANTOM's linear order.
- Fast confirmation in the common case is not a proof that a determined attacker cannot stall a particular pair.
Why the desk still reads it
If the product needs one global order of every transaction, this is the wrong paper. If it needs to accept payments that do not conflict, the pairwise vote is the idea to test.
09 Lexicon
Terms, opened into the record
- Pairwise vote
- A tally, over the DAG, of which of two blocks the other blocks consider earlier.
- Robust acceptance
- A lead in that vote large enough that the paper treats a reversal as an attack, not as ordinary delay.
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
Papers
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.