Hier soir, j’ai passé dix minutes à regarder la section « Rewards en attente » dans mon portefeuille, puis je suis retourné au code source du module de distribution du Cosmos SDK. La chose que les gens comprennent le plus souvent mal, ce n’est pas quel Fournisseur de Finalité choisir — c’est le fait de supposer que le fait que « les récompenses sont déjà calculées » signifie « les fonds sont prêts à être utilisés. »
Dans BABY, les récompenses sont enregistrées sur la chaîne, bloc par bloc, mais il existe encore une étape de règlement par époque entre ce qui est affiché sur le papier et ce qui peut réellement être déplacé. La documentation officielle indique que les récompenses sont réglées et distribuées uniquement à la fin de chaque époque. Cet intervalle est d’environ 360 blocs, soit à peu près une heure.
Ainsi, lorsque vous appuyez sur « Claim », les fonds deviennent « Available ». Mais si vous voulez déléguer à nouveau, ils doivent encore entrer dans l’époque en cours et attendre le cycle d’exécution suivant. Concrètement, passer du moment où des récompenses sont générées à celui où elles se compensent à nouveau peut prendre au moins deux époques — environ deux heures ou plus.
Ce système par lots, combiné à une synchronisation de type Bitcoin, permet aussi de maintenir le retrait non délié autour de deux jours. Mais il crée également un « gap » de capitalisation. Le TRAP (APR) affiché dans l’interface est généralement basé sur un modèle idéalisé de réinvestissement instantané, tandis que les fonds réels passent du temps dans un état qui est généré mais qui n’est pas encore effectif.
Si vous réclamez manuellement et déléguez manuellement, vous perdez du temps à cause des retards de transactions, des frais et des coupures d’époque manquées. Si vous réclamez tout près de la fin d’une époque, vous risquez aussi d’être repoussé dans le lot suivant, ce qui allonge encore davantage l’attente.
Pour moi, la question clé est simple : l’interface affiche-t-elle clairement ces états, et « Claim » plus « Delegate » peut-il être géré de manière fluide ? Ce niveau de transparence compte davantage que d’avoir un joli chiffre d’APR.
#baby $BABY @BabylonLabs_io
Dans BABY, les récompenses sont enregistrées sur la chaîne, bloc par bloc, mais il existe encore une étape de règlement par époque entre ce qui est affiché sur le papier et ce qui peut réellement être déplacé. La documentation officielle indique que les récompenses sont réglées et distribuées uniquement à la fin de chaque époque. Cet intervalle est d’environ 360 blocs, soit à peu près une heure.
Ainsi, lorsque vous appuyez sur « Claim », les fonds deviennent « Available ». Mais si vous voulez déléguer à nouveau, ils doivent encore entrer dans l’époque en cours et attendre le cycle d’exécution suivant. Concrètement, passer du moment où des récompenses sont générées à celui où elles se compensent à nouveau peut prendre au moins deux époques — environ deux heures ou plus.
Ce système par lots, combiné à une synchronisation de type Bitcoin, permet aussi de maintenir le retrait non délié autour de deux jours. Mais il crée également un « gap » de capitalisation. Le TRAP (APR) affiché dans l’interface est généralement basé sur un modèle idéalisé de réinvestissement instantané, tandis que les fonds réels passent du temps dans un état qui est généré mais qui n’est pas encore effectif.
Si vous réclamez manuellement et déléguez manuellement, vous perdez du temps à cause des retards de transactions, des frais et des coupures d’époque manquées. Si vous réclamez tout près de la fin d’une époque, vous risquez aussi d’être repoussé dans le lot suivant, ce qui allonge encore davantage l’attente.
Pour moi, la question clé est simple : l’interface affiche-t-elle clairement ces états, et « Claim » plus « Delegate » peut-il être géré de manière fluide ? Ce niveau de transparence compte davantage que d’avoir un joli chiffre d’APR.
#baby $BABY @BabylonLabs_io