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.
The five-minute read
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.
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.
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.
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.
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.
One action, walked through
- Staked validators take part in a distributed randomness generation round.
- The output assigns them to shards for the epoch. A validator cannot cheaply reject the draw and redraw.
- A shard leader proposes a block. Validators sign, and the signatures are aggregated.
- A transaction that touches another shard emits a receipt that the destination shard is required to pick up under the paper's same-epoch rule.
- At the epoch boundary, the beacon layer commits the shard headers and the next assignment begins.
The argument, unpacked
Same-epoch cross-shard is the sentence to test
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.
Aggregated signatures hide a liveness dependency
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.
Stake plus randomness is two assumptions
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.
What has to be true
- Distributed randomness is unbiased and available at the epoch boundary.
- Each shard has enough stake that the Byzantine threshold inside it still holds after the random cut.
- Receipts between shards are data-available. A header that points at a missing receipt is not a settlement.
- Leaders can be replaced when they withhold an aggregate.
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.
What to check before you use the idea
- Does a cross-shard transfer settle in the epoch the paper promises, or in a queue?
- How is the shard assignment random, and who can bias it?
- What stake share captures a single shard under the live parameters?
- Which keys, outside the consensus proof, can move assets if they are stolen?
Terms
- 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.
The problem the paper 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 a venture studio 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.
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.