$BABY #baby @BabylonLabs_io
Picked a finality provider based on their BTC delegation size and uptime history, the numbers every dashboard shows. Only later did I read what actually keeps that provider running day to day, and it isn't BTC at all.
Every finality provider needs a separate operation key funded with BABY, small amounts, used to pay gas for committing fresh randomness on a recurring schedule. Vote submissions get refunded automatically, Babylon's own operator docs confirm that directly. Other transactions on that same key, including the recurring randomness commits, require gas that doesn't come back. The docs describe it almost as an afterthought, fund it with a minimum amount, keep it running a long time, a single sentence next to the security machinery I actually went looking for.
Miss that refill and the provider isn't secretly compromised, their BTC delegation is still exactly as large and honest as it was yesterday. They just can't keep participating until someone notices an empty wallet and tops it up. A provider can be flawless on every metric I checked before delegating and still go dark over something as small as a gas key nobody remembered to refill.
Delegation dashboards show commission, delegation size, uptime history. None of them show whether a provider's operation key is sitting comfortably funded or running on fumes, because that number was never designed to be public in the first place.
I don't think this is a flaw in the design, keeping the operation key minimal and separate from a provider's real holdings is a reasonable security choice, not negligence. What it means for anyone delegating is smaller: the provider you picked for their BTC track record is also, quietly, in the business of remembering to buy gas.
$HEI

Did you know a finality provider’s operation key can run dry even while their BTC delegation looks perfectly healthy?