@BabylonLabs_io I keep coming back to how Babylon's slashing condition is written. Sign two conflicting blocks at the same height with your EOTS key, and the math itself exposes your private key. No committee reviews it, no vote decides it, the cryptography just fires.

What sits underneath that is more interesting than the mechanism itself. A market of third-party key managers now exists specifically to stop this from triggering, because the protocol has no way to separate an operator who cheated from one whose client software glitched. The "trustless, no committee" pitch is real at the protocol layer, but real-world safety now depends partly on whether a given finality provider bothered to adopt one of these vendors. That's a private business decision, not something written into the chain.

For anyone allocating BTC through a finality provider, that's a variable you can't currently check. Vendor adoption isn't disclosed, isn't standardized, and isn't part of any due-diligence checklist I've seen circulating.

Cryptographic purity was supposed to remove the need to trust anyone's judgment. Instead it just moved that judgment one layer down, into vendor selection nobody publishes.

A slashing condition with no committee still has a committee, it's just the vendor market deciding who gets covered.

The honest gap here is that I don't have adoption numbers either, so this is a structural observation, not a measured risk.
#baby $BABY $BLESS $HOME
Does your finality provider run EOTS key protection?