LibraryConsensus2016Design paperCorpus record
The Honey Badger of BFT Protocols
HoneyBadgerBFT. Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi and Dawn Song.
An asynchronous atomic broadcast. It does not wait for a timeout to make progress, and threshold encryption stops a leader from reading a batch and then dropping the transactions it dislikes.
HoneyBadgerBFT agrees on a batch of transactions with no timing assumption for progress. Threshold encryption hides the batch until it is chosen, so a replica cannot read a transaction and then vote it out.
The five-minute read
Asynchrony is the model
Messages can be delayed arbitrarily. A protocol that waits out a timeout and then blames a leader is not this one. HoneyBadger is built so a slow link does not look like an attack.
No leader to bribe
Every replica proposes a batch. A common subset is agreed. Silencing one replica drops its batch. It does not let that replica pick the whole order.
Encrypt, then agree, then decrypt
The agreement runs on ciphertext. After the set is fixed, a threshold of keys reveals the contents. Censorship by content would require predicting the plaintext.
The cost is rounds and cryptography
Reliable broadcast plus binary agreement is heavier than a HotStuff happy path. The paper treats that as the price of not having a clock.
One action, walked through
- Each replica takes a batch of pending transactions and threshold-encrypts it.
- Replicas run reliable broadcast so honest batches cannot be shown to only some peers.
- A binary agreement decides, for each batch, whether it is in this round's common set.
- Once the set is fixed, replicas produce decryption shares.
- The union of the decrypted batches is the delivered block, in a deterministic order.
The argument, unpacked
Censorship resistance here is specific
It is resistance to dropping a transaction because of what it says, inside a round. It is not resistance to a quorum that refuses to include a given replica at all, and it is not privacy against the public ledger after decryption.
Timeouts are the thing that was removed
If a design has a view-change timer as its liveness engine, it is in the partially synchronous family. HoneyBadger is the reference for the other choice, and for why that choice is expensive.
What has to be true
- Fewer than one third of replicas are Byzantine. Asynchrony does not relax that.
- Threshold encryption is correctly shared. A dealer who keeps the full key can read batches early.
- The network eventually delivers honest messages. Asynchronous means no bound, not no delivery.
- The application can tolerate the latency of several cryptographic rounds.
What happened after the paper
HoneyBadger remained a research and systems paper more than a public chain brand. Later asynchronous and DAG protocols cite it when they want progress without timeouts, then change the broadcast layer. A chain that advertises asynchronous BFT should be asked whether agreement sees plaintext.
What to check before you use the idea
- Does liveness depend on a timeout?
- Are transactions encrypted until the batch is chosen?
- Who holds the threshold key, and how is it dealt?
- What is the delivered order once plaintexts are known?
Terms
- Asynchronous
- No assumed bound on message delay. Progress must not depend on guessing one.
- Common subset
- A set of input batches that every honest replica agrees to deliver together.
The problem the paper names
Partially synchronous BFT can stall for the length of a timeout when the network is merely slow. HoneyBadger treats asynchrony as the normal case, and treats censorship of known contents as the attack.
What the design proposes
- A common subset of each replica's proposed batch, built from reliable broadcast and a binary agreement.
- Threshold encryption so the agreement runs on ciphertext.
- Decryption only after the set is chosen, so dropping a transaction means dropping a whole unknown batch.
How the mechanism is specified
- There is no single leader whose silence stops the protocol.
- The cost is several rounds of cryptography and a higher latency than a happy-path HotStuff commit.
- Asynchrony removes the timing assumption. It does not remove the need for two-thirds honesty.
What this page does not treat as proven
- This is not a proof-of-work chain and not a production client you can download under this name.
- Threshold keys are their own ceremony. Losing the dealer story loses the censorship claim.
- High latency can be the correct trade. It is still a trade.
Why a venture studio still reads it
Use it when a design claims to be asynchronous. Ask whether agreement sees plaintext, and what happens if one replica simply never sends.
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.