J’ai refait tout le processus de co-staking de Babylon, et ce qui m’a le plus mis mal à l’aise, c’est que : beaucoup de conditions clés, ce n’est qu’une fois que l’utilisateur n’a pas reçu de récompense qu’il les découvre.
Officiellement, le processus se résume en deux étapes : le BTC est délégué à un Finality Provider, puis BABY délègue à un validateur. Mais dans la pratique : le BTC doit passer de PENDING à VERIFIED, puis finalement devenir ACTIVE ; ce n’est qu’à l’état ACTIVE que la récompense est comptabilisée. En plus, BTC et BABY doivent utiliser la même adresse BABY ; si les adresses ne correspondent pas, la récompense de co-staking tombe directement à zéro. Pour maximiser l’efficacité des récompenses, il faut aussi se souvenir qu’environ 1 BTC correspond à 20 000 BABY.
Le problème, c’est que pour un utilisateur lambda, voir « soumis » ou « vérifié » donne facilement l’impression que tout est déjà terminé. Quant à l’étape où ça bloque, pourquoi il n’y a pas de récompense, si le Finality Provider choisi est encore actif, ou si les deux adresses correspondent réellement : la page devrait tout expliquer clairement, sans obliger l’utilisateur à fouiller la documentation et deviner.
À présent, le panneau Babylon affiche environ 51 342 BTC déjà mis en staking, et parmi 132 Finality Provider, seuls 36 sont à l’état actif. L’intervalle d’APR sur le BTC va de 0,04 % à 0,70 %. La taille est déjà là, mais côté utilisateurs on continue de devoir faire du débogage soi-même.
Le volet de sortie n’est pas aussi simple qu’en apparence. La documentation officielle sur le déstakings BTC indique un délai d’attente minimum de 301 blocs Bitcoin ; le dépannage via CLI peut aussi impliquer des paramètres de gas, ainsi que la configuration RPC et GRPC. Si ça ne se règle pas, il faut aller demander de l’aide sur Discord.
Je remets en cause très directement le point lié à @BabylonLabs_io : on peut comprendre que le protocole soit complexe, mais le produit ne peut pas renvoyer la complexité telle quelle à l’utilisateur.
Ce qui manque vraiment, ce sont l’explication des statuts, le repérage des erreurs et un parcours de traitement clair. Sinon, ce qu’on appelle « self-custody » risque de devenir — que tous les problèmes qu’on ne comprend pas soient finalement à la charge de l’utilisateur.
#baby $BABY @BabylonLabs_io
Officiellement, le processus se résume en deux étapes : le BTC est délégué à un Finality Provider, puis BABY délègue à un validateur. Mais dans la pratique : le BTC doit passer de PENDING à VERIFIED, puis finalement devenir ACTIVE ; ce n’est qu’à l’état ACTIVE que la récompense est comptabilisée. En plus, BTC et BABY doivent utiliser la même adresse BABY ; si les adresses ne correspondent pas, la récompense de co-staking tombe directement à zéro. Pour maximiser l’efficacité des récompenses, il faut aussi se souvenir qu’environ 1 BTC correspond à 20 000 BABY.
Le problème, c’est que pour un utilisateur lambda, voir « soumis » ou « vérifié » donne facilement l’impression que tout est déjà terminé. Quant à l’étape où ça bloque, pourquoi il n’y a pas de récompense, si le Finality Provider choisi est encore actif, ou si les deux adresses correspondent réellement : la page devrait tout expliquer clairement, sans obliger l’utilisateur à fouiller la documentation et deviner.
À présent, le panneau Babylon affiche environ 51 342 BTC déjà mis en staking, et parmi 132 Finality Provider, seuls 36 sont à l’état actif. L’intervalle d’APR sur le BTC va de 0,04 % à 0,70 %. La taille est déjà là, mais côté utilisateurs on continue de devoir faire du débogage soi-même.
Le volet de sortie n’est pas aussi simple qu’en apparence. La documentation officielle sur le déstakings BTC indique un délai d’attente minimum de 301 blocs Bitcoin ; le dépannage via CLI peut aussi impliquer des paramètres de gas, ainsi que la configuration RPC et GRPC. Si ça ne se règle pas, il faut aller demander de l’aide sur Discord.
Je remets en cause très directement le point lié à @BabylonLabs_io : on peut comprendre que le protocole soit complexe, mais le produit ne peut pas renvoyer la complexité telle quelle à l’utilisateur.
Ce qui manque vraiment, ce sont l’explication des statuts, le repérage des erreurs et un parcours de traitement clair. Sinon, ce qu’on appelle « self-custody » risque de devenir — que tous les problèmes qu’on ne comprend pas soient finalement à la charge de l’utilisateur.
#baby $BABY @BabylonLabs_io