At 2 a.m., Lao Chen tossed over a link: “Babylon—use Bitcoin to provide security for the PoS chain as its guard. Take a look.”
I opened the document and stared at “Bitcoin-secured PoS” for a long time. “Babylon enables native bitcoin staking directly on the Bitcoin blockchain without intermediaries.” Using Bitcoin’s economic security as an external defense layer so the PoS chain can share Bitcoin’s finality—that idea really is beautiful. Anyone who has written a consensus protocol has to admit that this is the most aggressive security attempt in the space right now.
But as I followed the light client design deeper, the hair on my neck started to stand up.
The Babylon chain only runs BTC light nodes; it doesn’t perform an incomplete full sync of the entire Bitcoin ledger—it relies solely on block headers and UTXO script verification. Zellic’s audit report explicitly points out: if the Babylon network panics and crashes, after restarting, the btclightclient will still treat the pre-crash height as the latest state. During this window, a malicious mining pool can submit forked block headers first; the light client will temporarily treat the fork as the main chain. Then staking transactions may be confirmed on the wrong fork. And when the Bitcoin network has orphan blocks, reorganizations, or deep block rollbacks, the light client has no way to recognize it.
What makes my hair stand up even more is EOTS. This is Babylon’s core innovation: an extractable one-time signature, used for cross-chain slashing proofs—“if an FP signs two different blocks at the same height, the private key is exposed, leading to automatic slashing.” It sounds great, but Zellic’s audit found that in EOTS manager’s GenerateRandomness function, when calling SetByteSlice, the return value isn’t checked. When the randomness overflows the Secp256k1 group order, the nonce becomes non-uniformly distributed. Although the probability is low, once an overflow sample occurs, the EOTS private key can be recovered by combining it with the Hidden Number Problem algorithm. Even more devastating is GHSA-7mm3-vfg8-7rg6: the x/finality module lacks domain separation, allowing an attacker to replay a PoP signature as MsgCommitPubRandList, injecting invalid PubRand commitments.
Using Bitcoin finality as the moat, yet the light client can’t see Bitcoin forks. Using custom cryptography for slashing, and EOTS’s randomness generation doesn’t even check for overflow. Do you trust Bitcoin’s chain—or do you trust this code?
#baby $BABY @BabylonLabs_io
I opened the document and stared at “Bitcoin-secured PoS” for a long time. “Babylon enables native bitcoin staking directly on the Bitcoin blockchain without intermediaries.” Using Bitcoin’s economic security as an external defense layer so the PoS chain can share Bitcoin’s finality—that idea really is beautiful. Anyone who has written a consensus protocol has to admit that this is the most aggressive security attempt in the space right now.
But as I followed the light client design deeper, the hair on my neck started to stand up.
The Babylon chain only runs BTC light nodes; it doesn’t perform an incomplete full sync of the entire Bitcoin ledger—it relies solely on block headers and UTXO script verification. Zellic’s audit report explicitly points out: if the Babylon network panics and crashes, after restarting, the btclightclient will still treat the pre-crash height as the latest state. During this window, a malicious mining pool can submit forked block headers first; the light client will temporarily treat the fork as the main chain. Then staking transactions may be confirmed on the wrong fork. And when the Bitcoin network has orphan blocks, reorganizations, or deep block rollbacks, the light client has no way to recognize it.
What makes my hair stand up even more is EOTS. This is Babylon’s core innovation: an extractable one-time signature, used for cross-chain slashing proofs—“if an FP signs two different blocks at the same height, the private key is exposed, leading to automatic slashing.” It sounds great, but Zellic’s audit found that in EOTS manager’s GenerateRandomness function, when calling SetByteSlice, the return value isn’t checked. When the randomness overflows the Secp256k1 group order, the nonce becomes non-uniformly distributed. Although the probability is low, once an overflow sample occurs, the EOTS private key can be recovered by combining it with the Hidden Number Problem algorithm. Even more devastating is GHSA-7mm3-vfg8-7rg6: the x/finality module lacks domain separation, allowing an attacker to replay a PoP signature as MsgCommitPubRandList, injecting invalid PubRand commitments.
Using Bitcoin finality as the moat, yet the light client can’t see Bitcoin forks. Using custom cryptography for slashing, and EOTS’s randomness generation doesn’t even check for overflow. Do you trust Bitcoin’s chain—or do you trust this code?
#baby $BABY @BabylonLabs_io