LibraryConsensus2019Design paperCorpus record
Harmony Technical Whitepaper
Harmony. Stephen Tse and the Harmony team.
A sharded proof-of-stake design that combines a BFT-style consensus inside shards with a randomness scheme for assigning validators, aimed at keeping a single shard from being captured.
Harmony combines staking, random sharding, and a fast Byzantine protocol inside each shard, and it tries to finish cross-shard messages in the same epoch rather than leaving them as an IOU.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 4
- Records linked
- 8
Code
Source, repository, and what is actually hosted
- harmony.one white paperhttps://harmony.one/whitepaper.pdf
- 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
It is explicit about standing on earlier papers
The text borrows Omniledger's sharding shape, RapidChain's ideas, and a responsive Byzantine protocol for the inside of a shard. The useful reading is what it claims to improve: randomness, cross-shard latency, and a proof-of-stake membership.
Claim 02 · Paper model
Randomness is a protocol object
A distributed randomness generation scheme assigns validators to shards. The paper treats a biasable assignment as a security failure, which is the correct instinct.
Claim 03 · Paper model
FBFT is pipelined voting
Inside a shard, a leader proposes and validators sign. Signature aggregation is how the paper keeps a large shard's votes small on the wire.
Claim 04 · Paper model
Cross-shard receipts are supposed to be synchronous
The paper does not want a message to another shard to wait for an unbounded lock. It specifies a path that aims to settle across shards within an epoch.
Claim 05 · Paper model
Resharding is when the design is most fragile
Moving validators between shards, and moving the state they must know, is the expensive part. An epoch that is safe only between reshardings has hidden the hard problem.
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 It is explicit about standing on earlier papers
Observation
What the study says
The text borrows Omniledger's sharding shape, RapidChain's ideas, and a responsive Byzantine protocol for the inside of a shard. The useful reading is what it claims to improve: randomness, cross-shard latency, and a proof-of-stake membership.
Model
What has to hold
Each shard has enough stake that the Byzantine threshold inside it still holds after the random cut.
Falsifier
What would retire it
Does a cross-shard transfer settle in the epoch the paper promises, or in a queue?
02 Randomness is a protocol object
Observation
What the study says
A distributed randomness generation scheme assigns validators to shards. The paper treats a biasable assignment as a security failure, which is the correct instinct.
Model
What has to hold
Distributed randomness is unbiased and available at the epoch boundary.
Falsifier
What would retire it
Does a cross-shard transfer settle in the epoch the paper promises, or in a queue?
03 FBFT is pipelined voting
Observation
What the study says
Inside a shard, a leader proposes and validators sign. Signature aggregation is how the paper keeps a large shard's votes small on the wire.
Model
What has to hold
Each shard has enough stake that the Byzantine threshold inside it still holds after the random cut.
Falsifier
What would retire it
Does a cross-shard transfer settle in the epoch the paper promises, or in a queue?
04 Cross-shard receipts are supposed to be synchronous
Observation
What the study says
The paper does not want a message to another shard to wait for an unbounded lock. It specifies a path that aims to settle across shards within an epoch.
Model
What has to hold
Receipts between shards are data-available. A header that points at a missing receipt is not a settlement.
Falsifier
What would retire it
Does a cross-shard transfer settle in the epoch the paper promises, or in a queue?
05 Resharding is when the design is most fragile
Observation
What the study says
Moving validators between shards, and moving the state they must know, is the expensive part. An epoch that is safe only between reshardings has hidden the hard problem.
Model
What has to hold
Receipts between shards are data-available. A header that points at a missing receipt is not a settlement.
Falsifier
What would retire it
Does a cross-shard transfer settle in the epoch the paper promises, or in a queue?
03 Sequence
One action, as an operating tape
- 01Staked validators take part in a distributed randomness generation round.
- 02The output assigns them to shards for the epoch. A validator cannot cheaply reject the draw and redraw.
- 03A shard leader proposes a block. Validators sign, and the signatures are aggregated.
- 04A transaction that touches another shard emits a receipt that the destination shard is required to pick up under the paper's same-epoch rule.
- 05At the epoch boundary, the beacon layer commits the shard headers and the next assignment begins.
04 Load-bearing
The argument, and where a pitch drops it
Same-epoch cross-shard is the sentence to test
The cut
Many sharding papers are precise inside a shard and vague across shards. Harmony's text makes a stronger promise. An implementation that queues cross-shard receipts for later has kept the shard and dropped the sentence that made the paper different.
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 treat the white paper's target throughput as a measured result.
Aggregated signatures hide a liveness dependency
The cut
A tiny aggregate is only useful if the leader can collect the parts. A leader who censors a validator's signature fragment, or a network that loses them, stalls the fast path. The paper's latency math assumes collection works.
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 treat the white paper's target throughput as a measured result.
Stake plus randomness is two assumptions
The cut
Stake says who may speak. Randomness says where they sit. Compromise either one and a shard can be captured with far less than a third of the whole stake. Report both, or the security claim is incomplete.
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
Randomness that is biasable recreates the shard-capture problem the design set out to avoid.
05 Register
What has to be true
Cryptography · Not re-measured
Distributed randomness is unbiased and available at the epoch boundary.
Stake and threshold · Not re-measured
Each shard has enough stake that the Byzantine threshold inside it still holds after the random cut.
Data · Not re-measured
Receipts between shards are data-available. A header that points at a missing receipt is not a settlement.
Model · Not re-measured
Leaders can be replaced when they withhold an aggregate.
06 Divergence
What happened after the paper
Harmony's network launched from this design and later suffered a bridge-key compromise that had little to do with the sharding proof and everything to do with operational custody. That incident is a reminder about what the paper does not cover. It is not a review of FBFT.
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
If an adversary can predict which validators land in a shard, they can concentrate stake there. Harmony's paper is about the assignment problem as much as about the fast path inside a shard.
What the design proposes
- Validators stake and are randomly assigned. Resharding is part of the security argument.
- Consensus inside a shard is a BFT protocol on a small committee, not a global race.
- A beacon or randomness source is load-bearing. The paper has to say where the randomness comes from.
How the mechanism is specified
- Cross-shard messages are receipts, not free function calls. That constraint is the design.
- Effective proof-of-stake in the paper is a response to one-address dominance, not a general fairness theorem.
- Later network parameters are not frozen by the PDF.
What this page does not treat as proven
- Do not treat the white paper's target throughput as a measured result.
- Randomness that is biasable recreates the shard-capture problem the design set out to avoid.
- This page does not review Harmony's subsequent treasury or bridge incidents. Those are separate facts.
Why the desk still reads it
For a studio, the transferable question is: is shard membership unpredictable to the attacker who is about to join? If the answer is no, the rest of the diagram does not matter.
09 Lexicon
Terms, opened into the record
- Beacon layer
- The coordinating chain that commits shard headers, randomness, and membership.
- FBFT
- The paper's fast Byzantine agreement inside a shard, using aggregated signatures.
- Resharding
- Reassigning validators, and the state they serve, at an epoch boundary.
- Receipt
- The proof a destination shard needs before it acts on a message from another shard.
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.
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.