Last night, Old Zhao and Monkey came to my place to drink, and when we got to Babylon Genesis, both of them slammed the table and told me to go read the whitepaper. This noon, I stared at the “dual-quorum staking” design for a long time.
“100 CometBFT validators running CometBFT consensus, together with 60 Bitcoin-staked Finality Providers adding Bitcoin-finality signatures.” The idea of using Bitcoin’s economic security to provide an external defensive layer for a PoS chain is indeed beautiful. Anyone who has written a distributed system has to admit that this is the most aggressive security attempt out there right now.
But as I break down the power structure downward from the consensus layer, the hair on my neck starts to stand up.
Finality Providers’ voting power is directly tied to the amount of delegated BTC they stake. There is no cap on BTC staking. Big whales could concentrate and hoard large quantities of BTC delegated to a single Provider. If one entity monopolizes voting power, it can carry out block censorship and malicious rollbacks.
What worries me even more is the epoch-switching vulnerability. Babylon rotates validators by epoch. A GitHub security advisory, GHSA-rj53-j6jw-7f7g, disclosed that if you send a message that modifies the validator set at an epoch boundary, the entire chain will halt. Developers found that the protocol dereferences a null pointer when the block hash is missing, triggering a panic. A malicious validator can intentionally omit the hash field in the BLS vote extension; when multiple validators exploit it at the same time, it causes a crash and slows down block production. The vulnerability was marked “High severity,” and as of the time of disclosure, the official side had not publicly responded.
CometBFT said “I agree,” Finality Providers said “I’ve signed too,” but at the instant the epoch switches, the entire chain stops. You’re betting this vulnerability won’t be exploited?
The above is only my personal view and does not constitute investment advice. Do you have different opinions? Feel free to discuss in the comments.
#baby $BABY @BabylonLabs_io
“100 CometBFT validators running CometBFT consensus, together with 60 Bitcoin-staked Finality Providers adding Bitcoin-finality signatures.” The idea of using Bitcoin’s economic security to provide an external defensive layer for a PoS chain is indeed beautiful. Anyone who has written a distributed system has to admit that this is the most aggressive security attempt out there right now.
But as I break down the power structure downward from the consensus layer, the hair on my neck starts to stand up.
Finality Providers’ voting power is directly tied to the amount of delegated BTC they stake. There is no cap on BTC staking. Big whales could concentrate and hoard large quantities of BTC delegated to a single Provider. If one entity monopolizes voting power, it can carry out block censorship and malicious rollbacks.
What worries me even more is the epoch-switching vulnerability. Babylon rotates validators by epoch. A GitHub security advisory, GHSA-rj53-j6jw-7f7g, disclosed that if you send a message that modifies the validator set at an epoch boundary, the entire chain will halt. Developers found that the protocol dereferences a null pointer when the block hash is missing, triggering a panic. A malicious validator can intentionally omit the hash field in the BLS vote extension; when multiple validators exploit it at the same time, it causes a crash and slows down block production. The vulnerability was marked “High severity,” and as of the time of disclosure, the official side had not publicly responded.
CometBFT said “I agree,” Finality Providers said “I’ve signed too,” but at the instant the epoch switches, the entire chain stops. You’re betting this vulnerability won’t be exploited?
The above is only my personal view and does not constitute investment advice. Do you have different opinions? Feel free to discuss in the comments.
#baby $BABY @BabylonLabs_io