#baby $BABY TBV dans l’écosystème, ce qui est le plus facile à ignorer est peut-être : liquidateurs et arbitragistes ne scrutent pas nécessairement le même lot de positions. Le dépôt officiel <a>Babylon</a> pour les aave-v4-bots a scindé l’indexeur Ponder, commun aux deux types de supervision, en deux modes : configurer ADAPTER_ADDRESS et SPOKE_ADDRESS pour n’écouter que les positions de liquidation ; configurer VAULT_SWAP_ADDRESS pour n’écouter que les Vault détenus dans le cadre de la garde. Les deux modes peuvent être activés simultanément, ou seulement l’un d’eux.
Cette règle est concrète pour les développeurs. Si vous ne configurez qu’une instance de VaultSwap, la supervision d’arbitrage semble correcte, mais elle ne fournira pas d’interface pour les positions de liquidation ; si, en mode liquidation, vous omettez un des adresses, la configuration échoue directement. Les outils n’ont pas d’état intermédiaire « à peu près fonctionnel » : de mauvaises variables d’environnement peuvent amener l’équipe à confondre l’absence de détection d’opportunités avec l’idée que « il n’y a pas d’opportunité on-chain ».
Je le vois comme le seuil minimal pour la coopération au sein de l’écosystème TBV : le code de supervision peut être réutilisé, tandis que la portée de l’information reste déterminée par le déployeur. Dans les scénarios sous pression, le côté liquidation a déjà capturé les positions, mais le côté arbitrage n’a pas synchronisé l’écoute du Vault détenu ; le retard retombe alors sur l’équipe opérationnelle et sur les participants du marché qui attendent d’en prendre le relais. Ce dépôt montre que l’outillage peut être réutilisé, mais ne prouve pas encore que l’écosystème dispose d’une couche d’information unifiée. @BabylonLabs_io devrait publier, après coup, la couverture et l’état de santé de chaque mode ; $BABY doit prendre en charge la croissance de l’écosystème : pour cela, il faut d’abord que « voir les opportunités » ne dépende plus d’une série d’adresses faciles à mal configurer.
Cette règle est concrète pour les développeurs. Si vous ne configurez qu’une instance de VaultSwap, la supervision d’arbitrage semble correcte, mais elle ne fournira pas d’interface pour les positions de liquidation ; si, en mode liquidation, vous omettez un des adresses, la configuration échoue directement. Les outils n’ont pas d’état intermédiaire « à peu près fonctionnel » : de mauvaises variables d’environnement peuvent amener l’équipe à confondre l’absence de détection d’opportunités avec l’idée que « il n’y a pas d’opportunité on-chain ».
Je le vois comme le seuil minimal pour la coopération au sein de l’écosystème TBV : le code de supervision peut être réutilisé, tandis que la portée de l’information reste déterminée par le déployeur. Dans les scénarios sous pression, le côté liquidation a déjà capturé les positions, mais le côté arbitrage n’a pas synchronisé l’écoute du Vault détenu ; le retard retombe alors sur l’équipe opérationnelle et sur les participants du marché qui attendent d’en prendre le relais. Ce dépôt montre que l’outillage peut être réutilisé, mais ne prouve pas encore que l’écosystème dispose d’une couche d’information unifiée. @BabylonLabs_io devrait publier, après coup, la couverture et l’état de santé de chaque mode ; $BABY doit prendre en charge la croissance de l’écosystème : pour cela, il faut d’abord que « voir les opportunités » ne dépende plus d’une série d’adresses faciles à mal configurer.
