Je suis tombé dans des pièges en partageant un pool sur un pont inter-chaînes—on a liquidé une partie de ma position avec pour effet collatéral les opérations des autres. Ce n’était pas beaucoup d’argent, mais la frustration de “devoir payer pour les problèmes des autres” m’est restée en tête jusqu’à aujourd’hui.
Depuis, dès que je vois un schéma pour faire entrer du BTC dans DeFi via un pont, je commence par une question : est-ce que, dans le système, il y a quelque chose qui puisse verrouiller le risque sur “les autres”, sans qu’il ne me retombe dessus ?
En lisant la documentation de Babylon, j’ai découvert un élément appelé ApplicationRegistry. C’est un contrat sur Ethereum, conçu pour enregistrer les applications DeFi qui ont été approuvées par la gouvernance et qui peuvent recevoir des fonds de trésorerie. Pour qu’une nouvelle application s’y connecte, elle doit passer par un processus d’audit de gouvernance, et déployer son propre contrat d’adaptateur. À ce jour, seul l’adaptateur d’Aave v4 est enregistré. Impossible donc de s’y brancher à la légère.
Ma première réaction a été : Ah, une liste blanche, pour empêcher que des projets de mauvaise qualité n’entrent.
Mais lors d’une deuxième lecture, j’ai remarqué un détail que j’avais ignoré : ApplicationRegistry ne lie pas “l’application”, mais “le contrat d’adaptateur correspondant à l’application”. Une fois l’adaptateur enregistré, les règles sont figées—elles ne peuvent pas être modifiées à votre insu.
C’est là que j’ai compris : je croyais qu’il servait seulement à “contrôler qui peut entrer”, alors qu’en réalité il fait surtout “souder les règles”. Si Aave a un problème, cela n’affecte que l’adaptateur d’Aave ; si GoMining a un problème, cela n’affecte que l’adaptateur de GoMining. Votre trésorerie en BTC est découplée de l’application : les défaillances côté application ne se propagent pas à la couche d’actifs.
J’approuve la logique de conception. Mais le coût est aussi très clair : à chaque nouvelle application, il faut passer par la gouvernance. Le rythme d’expansion est donc nettement plus lent que les solutions où “tout le monde peut se connecter”.
Ce qui me laisse toutefois plus réservé, c’est l’efficacité du système d’admission en conditions d’envergure—quand des dizaines d’applications se mettent en file pour accéder, est-ce que le rythme de la gouvernance arrivera à tenir ? Pour l’instant, je n’ai pas vu assez de données d’essais en conditions réelles.
Il y a toutefois un point de vue qui a vraiment changé : auparavant, je trouvais “l’isolation des risques” trop abstraite, mais ApplicationRegistry m’a montré un chemin concret—transformer chaque application en une prise (insert) indépendante : si vous branchez mal, vous ne faites brûler que cette portion, pas toute la maison.
À votre avis, cette conception est “lente” ou “sûre” ?
$BABY @BabylonLabs_io #baby
Depuis, dès que je vois un schéma pour faire entrer du BTC dans DeFi via un pont, je commence par une question : est-ce que, dans le système, il y a quelque chose qui puisse verrouiller le risque sur “les autres”, sans qu’il ne me retombe dessus ?
En lisant la documentation de Babylon, j’ai découvert un élément appelé ApplicationRegistry. C’est un contrat sur Ethereum, conçu pour enregistrer les applications DeFi qui ont été approuvées par la gouvernance et qui peuvent recevoir des fonds de trésorerie. Pour qu’une nouvelle application s’y connecte, elle doit passer par un processus d’audit de gouvernance, et déployer son propre contrat d’adaptateur. À ce jour, seul l’adaptateur d’Aave v4 est enregistré. Impossible donc de s’y brancher à la légère.
Ma première réaction a été : Ah, une liste blanche, pour empêcher que des projets de mauvaise qualité n’entrent.
Mais lors d’une deuxième lecture, j’ai remarqué un détail que j’avais ignoré : ApplicationRegistry ne lie pas “l’application”, mais “le contrat d’adaptateur correspondant à l’application”. Une fois l’adaptateur enregistré, les règles sont figées—elles ne peuvent pas être modifiées à votre insu.
C’est là que j’ai compris : je croyais qu’il servait seulement à “contrôler qui peut entrer”, alors qu’en réalité il fait surtout “souder les règles”. Si Aave a un problème, cela n’affecte que l’adaptateur d’Aave ; si GoMining a un problème, cela n’affecte que l’adaptateur de GoMining. Votre trésorerie en BTC est découplée de l’application : les défaillances côté application ne se propagent pas à la couche d’actifs.
J’approuve la logique de conception. Mais le coût est aussi très clair : à chaque nouvelle application, il faut passer par la gouvernance. Le rythme d’expansion est donc nettement plus lent que les solutions où “tout le monde peut se connecter”.
Ce qui me laisse toutefois plus réservé, c’est l’efficacité du système d’admission en conditions d’envergure—quand des dizaines d’applications se mettent en file pour accéder, est-ce que le rythme de la gouvernance arrivera à tenir ? Pour l’instant, je n’ai pas vu assez de données d’essais en conditions réelles.
Il y a toutefois un point de vue qui a vraiment changé : auparavant, je trouvais “l’isolation des risques” trop abstraite, mais ApplicationRegistry m’a montré un chemin concret—transformer chaque application en une prise (insert) indépendante : si vous branchez mal, vous ne faites brûler que cette portion, pas toute la maison.
À votre avis, cette conception est “lente” ou “sûre” ?
$BABY @BabylonLabs_io #baby