Cette fois-ci, en parcourant l’explorer de Babylon, ce qui m’a arrêté n’est pas le TVL ni le nouveau BSN intégré.
Ce qui m’a arrêté, c’est la façon dont la plupart des délégateurs choisissent un fournisseur de finalité.
La majorité choisit selon l’APY affiché — le plus élevé, donc on choisit le plus haut. Très peu descendent pour consulter l’historique d’uptime, ou pour vérifier s’ils ont déjà été slashés auparavant.
Cela crée une contradiction silencieuse : @BabylonLabs_io construit un système où, en théorie, toutes les informations sont transparentes on-chain, mais le comportement réel des utilisateurs ressemble exactement à choisir d’envoyer de l’argent en épargne — on regarde le taux d’intérêt, en ignorant le reste.
Point technique notable : la transparence on-chain ne vaut que si quelqu’un la lit réellement avant de décider. Si la plupart des capitaux partent vers l’APY sans être assortie d’une vérification de la validation des risques opérationnels, le marché valorise le fournisseur de finalité en fonction de la générosité des récompenses, plutôt que de la vraie qualité de la protection du réseau.
Auto-contre-argument : ce n’est peut-être pas une erreur des utilisateurs. Il n’existe aucun outil prêt à l’emploi qui consolide, de façon lisible, l’historique des slashing — pour savoir, il faut aller dans l’explorer, puis recouper soi-même les données brutes. Exiger d’un utilisateur “lambda” qu’il fasse tout cela avant chaque fois qu’il stake est une attente irréaliste pour la plupart.
$BABY et le mécanisme de récompense actuel n’ont pas encore de composante d’incitation distincte pour choisir un fournisseur de finalité sur la base de la qualité d’exploitation, plutôt que de se baser uniquement sur l’APY.
Je cherche à voir s’il existe un outil qui rend cela plus facile, ou si la transparence on-chain reste simplement une transparence pour ceux qui ont assez de patience pour aller la chercher.
#baby $DEXE
Ce qui m’a arrêté, c’est la façon dont la plupart des délégateurs choisissent un fournisseur de finalité.
La majorité choisit selon l’APY affiché — le plus élevé, donc on choisit le plus haut. Très peu descendent pour consulter l’historique d’uptime, ou pour vérifier s’ils ont déjà été slashés auparavant.
Cela crée une contradiction silencieuse : @BabylonLabs_io construit un système où, en théorie, toutes les informations sont transparentes on-chain, mais le comportement réel des utilisateurs ressemble exactement à choisir d’envoyer de l’argent en épargne — on regarde le taux d’intérêt, en ignorant le reste.
Point technique notable : la transparence on-chain ne vaut que si quelqu’un la lit réellement avant de décider. Si la plupart des capitaux partent vers l’APY sans être assortie d’une vérification de la validation des risques opérationnels, le marché valorise le fournisseur de finalité en fonction de la générosité des récompenses, plutôt que de la vraie qualité de la protection du réseau.
Auto-contre-argument : ce n’est peut-être pas une erreur des utilisateurs. Il n’existe aucun outil prêt à l’emploi qui consolide, de façon lisible, l’historique des slashing — pour savoir, il faut aller dans l’explorer, puis recouper soi-même les données brutes. Exiger d’un utilisateur “lambda” qu’il fasse tout cela avant chaque fois qu’il stake est une attente irréaliste pour la plupart.
$BABY et le mécanisme de récompense actuel n’ont pas encore de composante d’incitation distincte pour choisir un fournisseur de finalité sur la base de la qualité d’exploitation, plutôt que de se baser uniquement sur l’APY.
Je cherche à voir s’il existe un outil qui rend cela plus facile, ou si la transparence on-chain reste simplement une transparence pour ceux qui ont assez de patience pour aller la chercher.
#baby $DEXE
