K
Kenneth Onyebuchi
Guest
Every serious bridge security writeup eventually lands on the same phrase: an honesty threshold, the number of validator keys an attacker needs before a bridge is theirs. It's a useful way to think about risk, and it borrows heavily from a real field: Byzantine fault tolerance. An honesty threshold and actual BFT consensus are not the same thing though, and the gap between them is exactly where bridges like Ronin and Wormhole got hurt.
A bridge that relies on a validator set is really running a k-of-n multisig. Collect signatures from k of the n validators, and the bridge treats the message as approved. Ronin's bridge required five signatures from its nine validators to authorize a withdrawal. Wormhole's Guardian network requires thirteen of its nineteen to produce a valid attestation. Both numbers are described in security writeups as an "honesty threshold", the count of validators an attacker has to compromise before the bridge is theirs.
Ronin's attacker didn't need anything sophisticated to hit that number. Four of the five compromised keys belonged to the same operator, Sky Mavis, and the fifth came from an old signing allowlist created for a traffic surge and never revoked. That's a key management failure. Nothing about it required defeating a consensus mechanism.
Classical BFT protocols solve a different, harder problem. The Byzantine Generals Problem asks how a group of nodes reaches agreement when some of them might be faulty or actively lying, and the honest nodes don't know in advance which ones. PBFT and its successors answer that with specific machinery. Nodes exchange messages across multiple rounds, detect when a leader is behaving inconsistently, trigger a view change to remove that leader, and keep making progress as long as fewer than a third of the nodes are faulty. The system does more than count signatures. It actively distinguishes honest behavior from faulty behavior while consensus is happening, and it recovers when something goes wrong.
A k-of-n multisig has none of that machinery. It doesn't distinguish an honest signer from a compromised one. It just counts. It has no view change, because there's no leader role to replace. It has no built-in way to detect that a signature came from a key an attacker now controls rather than the validator who was supposed to hold it. Wormhole came close to learning this the hard way when a researcher found that a genesis guardian key, one single key, had never been expired on Wormchain and could have bypassed the entire thirteen-of-nineteen quorum on its own. The team fixed it within 48 hours of discovery, but the key had been sitting there for years.
None of this means multisig bridges are poorly built. It means they're a different, simpler security primitive being described with language borrowed from a more rigorous one.
Closing that gap has two real paths, and bridge teams are already pursuing both. One is making the validator set behave more like an actual BFT protocol, adding automated slashing when a validator signs conflicting messages, rotating and expiring keys automatically instead of relying on someone to remember, and building in the kind of fault detection that catches a compromised signer before it reaches the threshold. The other path skips validator trust altogether. Light client and zero-knowledge verification replace the validator set with cryptographic proof that a state transition actually happened, removing the honesty threshold as a concept entirely rather than trying to harden it.
A few things follow from taking this distinction seriously.
Ask what kind of threshold you're actually looking at. A k-of-n multisig and a BFT-grade consensus system can both get described as having a security threshold, and treating them as equivalent risk profiles is exactly the mistake that cost Ronin six hundred million dollars.
Check whether keys expire automatically. Wormhole's near-miss and Ronin's actual loss both trace back to the same root cause: a credential that should have been revoked and wasn't. That's a process failure a proper BFT protocol's view-change mechanism is specifically designed to route around.
Prioritize your trust model over your throughput numbers. I've written before about the practical difference between a bridge and a cross-chain swap aggregator, but the underlying trust model determines your actual risk far more than the interface layered on top of it.
Bridge security language and Byzantine fault tolerance share a vocabulary: thresholds, quorums, and honest majorities, but a k-of-n multisig and a real BFT protocol are different primitives solving different problems. One counts signatures. The other actively defends against the exact failure mode that drained Ronin and nearly caught Wormhole. Knowing which one you're actually relying on is worth figuring out before your bridge becomes the next case study.
What Bridge Multisigs Actually Are
A bridge that relies on a validator set is really running a k-of-n multisig. Collect signatures from k of the n validators, and the bridge treats the message as approved. Ronin's bridge required five signatures from its nine validators to authorize a withdrawal. Wormhole's Guardian network requires thirteen of its nineteen to produce a valid attestation. Both numbers are described in security writeups as an "honesty threshold", the count of validators an attacker has to compromise before the bridge is theirs.
Ronin's attacker didn't need anything sophisticated to hit that number. Four of the five compromised keys belonged to the same operator, Sky Mavis, and the fifth came from an old signing allowlist created for a traffic surge and never revoked. That's a key management failure. Nothing about it required defeating a consensus mechanism.
What Real Byzantine Fault Tolerance Actually Requires
Classical BFT protocols solve a different, harder problem. The Byzantine Generals Problem asks how a group of nodes reaches agreement when some of them might be faulty or actively lying, and the honest nodes don't know in advance which ones. PBFT and its successors answer that with specific machinery. Nodes exchange messages across multiple rounds, detect when a leader is behaving inconsistently, trigger a view change to remove that leader, and keep making progress as long as fewer than a third of the nodes are faulty. The system does more than count signatures. It actively distinguishes honest behavior from faulty behavior while consensus is happening, and it recovers when something goes wrong.
Why a Multisig Isn't BFT, Even Though It Sounds Like One
A k-of-n multisig has none of that machinery. It doesn't distinguish an honest signer from a compromised one. It just counts. It has no view change, because there's no leader role to replace. It has no built-in way to detect that a signature came from a key an attacker now controls rather than the validator who was supposed to hold it. Wormhole came close to learning this the hard way when a researcher found that a genesis guardian key, one single key, had never been expired on Wormchain and could have bypassed the entire thirteen-of-nineteen quorum on its own. The team fixed it within 48 hours of discovery, but the key had been sitting there for years.
None of this means multisig bridges are poorly built. It means they're a different, simpler security primitive being described with language borrowed from a more rigorous one.
What Would Make a Bridge Actually BFT-Grade
Closing that gap has two real paths, and bridge teams are already pursuing both. One is making the validator set behave more like an actual BFT protocol, adding automated slashing when a validator signs conflicting messages, rotating and expiring keys automatically instead of relying on someone to remember, and building in the kind of fault detection that catches a compromised signer before it reaches the threshold. The other path skips validator trust altogether. Light client and zero-knowledge verification replace the validator set with cryptographic proof that a state transition actually happened, removing the honesty threshold as a concept entirely rather than trying to harden it.
What This Means for Anyone Evaluating a Bridge
A few things follow from taking this distinction seriously.
Ask what kind of threshold you're actually looking at. A k-of-n multisig and a BFT-grade consensus system can both get described as having a security threshold, and treating them as equivalent risk profiles is exactly the mistake that cost Ronin six hundred million dollars.
Check whether keys expire automatically. Wormhole's near-miss and Ronin's actual loss both trace back to the same root cause: a credential that should have been revoked and wasn't. That's a process failure a proper BFT protocol's view-change mechanism is specifically designed to route around.
Prioritize your trust model over your throughput numbers. I've written before about the practical difference between a bridge and a cross-chain swap aggregator, but the underlying trust model determines your actual risk far more than the interface layered on top of it.
Conclusion
Bridge security language and Byzantine fault tolerance share a vocabulary: thresholds, quorums, and honest majorities, but a k-of-n multisig and a real BFT protocol are different primitives solving different problems. One counts signatures. The other actively defends against the exact failure mode that drained Ronin and nearly caught Wormhole. Knowing which one you're actually relying on is worth figuring out before your bridge becomes the next case study.