I went through Babylon’s shared staking process again, and the most uncomfortable part is this: many key conditions only become apparent to users if they don’t receive rewards.
Officially, the process is summarized in two steps: you delegate BTC to a Finality Provider, and then BABY delegates to validators. But in real operation, BTC must move from PENDING through VERIFIED and finally into ACTIVE. Only when it’s in the ACTIVE state counts as receiving rewards. Also, BTC and BABY must use the same BABY address—if the addresses don’t match, the shared-staking rewards go to zero. To maximize reward efficiency, you also need to remember that about 1 BTC corresponds to 20,000 BABY.
The problem is that ordinary users who see “Submitted” or “Verified” will easily assume everything is already done. As for which step it’s stuck on, why there are no rewards, whether the selected Finality Provider is still active, and whether the two addresses actually match—these should be clearly stated on the page. The UI shouldn’t force users to dig through documentation and guess.
Now the Babylon dashboard shows about 51,342 BTC staked, and among 132 Finality Providers, only 36 are active. The annualized BTC rate ranges from 0.04% to 0.70%. The scale is already there, yet users on the client side are still troubleshooting on their own.
The exit process also isn’t as effortless as it looks. The official BTC unstaking documentation states the minimum waiting time is 301 Bitcoin blocks. Troubleshooting CLI issues may also involve gas parameters, RPC, and GRPC configuration—if that doesn’t solve it, you’re told to ask for help on Discord.
My doubts about @BabylonLabs_io are very straightforward: protocol complexity is understandable, but a product shouldn’t just pass that complexity unchanged to the user.
What really needs to be added is state explanations, error localization, and a clear handling path. Otherwise, so-called “self-custody” can easily turn into this: all the questions people can’t understand become the user’s responsibility.
#baby $BABY @BabylonLabs_io
Officially, the process is summarized in two steps: you delegate BTC to a Finality Provider, and then BABY delegates to validators. But in real operation, BTC must move from PENDING through VERIFIED and finally into ACTIVE. Only when it’s in the ACTIVE state counts as receiving rewards. Also, BTC and BABY must use the same BABY address—if the addresses don’t match, the shared-staking rewards go to zero. To maximize reward efficiency, you also need to remember that about 1 BTC corresponds to 20,000 BABY.
The problem is that ordinary users who see “Submitted” or “Verified” will easily assume everything is already done. As for which step it’s stuck on, why there are no rewards, whether the selected Finality Provider is still active, and whether the two addresses actually match—these should be clearly stated on the page. The UI shouldn’t force users to dig through documentation and guess.
Now the Babylon dashboard shows about 51,342 BTC staked, and among 132 Finality Providers, only 36 are active. The annualized BTC rate ranges from 0.04% to 0.70%. The scale is already there, yet users on the client side are still troubleshooting on their own.
The exit process also isn’t as effortless as it looks. The official BTC unstaking documentation states the minimum waiting time is 301 Bitcoin blocks. Troubleshooting CLI issues may also involve gas parameters, RPC, and GRPC configuration—if that doesn’t solve it, you’re told to ask for help on Discord.
My doubts about @BabylonLabs_io are very straightforward: protocol complexity is understandable, but a product shouldn’t just pass that complexity unchanged to the user.
What really needs to be added is state explanations, error localization, and a clear handling path. Otherwise, so-called “self-custody” can easily turn into this: all the questions people can’t understand become the user’s responsibility.
#baby $BABY @BabylonLabs_io