Hier, j’ai vu un fil de discussion saluant Babylon : « le plus sûr, car aucun bridge n’est nécessaire, aucun wrap non plus ». En dessous, il y avait un court commentaire : « Sûr sur le plan de la custody seulement, mais ça ne dit rien sur la gouvernance. »
Cette phrase m’a fait m’arrêter et relire plus attentivement.
Le marketing de @BabylonLabs_io met l’accent sur un axe : le BTC ne quitte pas sa chaîne d’origine, on ne confie pas quelqu’un pour le détenir à votre place, pas de risque de bridge. C’est vrai, et c’est un vrai point fort.
Mais « la sécurité » a plusieurs couches. Ce n’est pas seulement l’absence de perte d’actifs. Il y a aussi la sécurité au niveau des droits : votre actif est-il utilisé pour des objectifs avec lesquels vous n’êtes pas d’accord ?
Le BTC mis en stake via Babylon reste bien sur la chaîne Bitcoin, c’est exact. Mais la façon dont ces BTC sont répartis pour sécuriser quel BSN, les paramètres de slashing, etc. — tout cela est décidé par des personnes qui ne détiennent pas ces BTC. Vous conservez l’actif, mais vous ne conservez pas le pouvoir de décision sur la manière dont votre actif « va travailler ».
Appelons cela un risque de délégation non symétrique : on prête un actif, l’emprunteur décide de son utilisation, et moi je ne reçois que le résultat.
Autocritique : par rapport à déposer du BTC sur une plateforme centralisée — où l’on perd à la fois la propriété et le pouvoir de décision — le modèle Babylon reste une avancée claire, car l’une des deux problématiques (la propriété) est déjà résolue. Chercher à résoudre l’autre moitié (la décision) dès maintenant pourrait être une attente un peu trop rapide pour une infrastructure encore jeune.
La frontière entre « autonomie sur l’actif » et « autonomie sur la décision » est quelque chose que peu d’analyses distinguent vraiment, en séparant clairement $BABY .
Je suis en train de voir si cette frontière peut être réduite dans les mises à jour à venir, ou si Babylon considère que ce sont deux problèmes à résoudre selon deux feuilles de route différentes.
#baby $DEXE
Cette phrase m’a fait m’arrêter et relire plus attentivement.
Le marketing de @BabylonLabs_io met l’accent sur un axe : le BTC ne quitte pas sa chaîne d’origine, on ne confie pas quelqu’un pour le détenir à votre place, pas de risque de bridge. C’est vrai, et c’est un vrai point fort.
Mais « la sécurité » a plusieurs couches. Ce n’est pas seulement l’absence de perte d’actifs. Il y a aussi la sécurité au niveau des droits : votre actif est-il utilisé pour des objectifs avec lesquels vous n’êtes pas d’accord ?
Le BTC mis en stake via Babylon reste bien sur la chaîne Bitcoin, c’est exact. Mais la façon dont ces BTC sont répartis pour sécuriser quel BSN, les paramètres de slashing, etc. — tout cela est décidé par des personnes qui ne détiennent pas ces BTC. Vous conservez l’actif, mais vous ne conservez pas le pouvoir de décision sur la manière dont votre actif « va travailler ».
Appelons cela un risque de délégation non symétrique : on prête un actif, l’emprunteur décide de son utilisation, et moi je ne reçois que le résultat.
Autocritique : par rapport à déposer du BTC sur une plateforme centralisée — où l’on perd à la fois la propriété et le pouvoir de décision — le modèle Babylon reste une avancée claire, car l’une des deux problématiques (la propriété) est déjà résolue. Chercher à résoudre l’autre moitié (la décision) dès maintenant pourrait être une attente un peu trop rapide pour une infrastructure encore jeune.
La frontière entre « autonomie sur l’actif » et « autonomie sur la décision » est quelque chose que peu d’analyses distinguent vraiment, en séparant clairement $BABY .
Je suis en train de voir si cette frontière peut être réduite dans les mises à jour à venir, ou si Babylon considère que ce sont deux problèmes à résoudre selon deux feuilles de route différentes.
#baby $DEXE
