Eric Choo

🎉 Officiellement dans le Top 100 de CreatorPad !

Un grand merci à tous ceux qui ont toujours lu mes articles, interagi et m'ont accompagné tout au long de ce parcours 🫶
Des partages simples sur le marché, l'état d'esprit jusqu'à ma perspective personnelle, je n'aurais jamais pensé recevoir un tel résultat.

15489 $PIXEL n'est pas seulement une récompense, mais aussi une motivation pour continuer à produire du contenu de qualité pour la communauté 🚀

Le chemin est encore long, je vais m'efforcer de maintenir le cap et d'aller encore plus loin 💛
Pour ceux qui construisent du contenu, restez persévérants, les opportunités sont toujours là pour ceux qui s'investissent vraiment.

#CreatorpadVN #BinanceSquare

Je ne pensais pas que cette fois-ci, j'aurais la chance d'atteindre le top 4 des CreatorPad VN sur Binance Square 🥹
La récompense de 0.12 $BNB n'est pas énorme, mais c'est un bon coup de boost pour continuer à écrire et partager davantage.

En fait, je trouve que Binance Square a encore beaucoup d'opportunités pour ceux qui aiment créer du contenu, faire des analyses ou simplement interagir chaque jour.
Allez, lancez-vous, qui sait, votre prochain post pourrait bien être dans le top 👀

Pour ceux qui veulent participer mais ne savent pas par où commencer, si vous avez besoin de conseils pour écrire des articles, construire de l'interaction ou chasser des événements, n'hésitez pas à me demander, je suis là pour vous aider à fond 🤝

Félicitations à tous ceux qui ont reçu des récompenses cette fois-ci 🫶

#binancep2pantoan @Binance Vietnam

La capture d’écran qui a failli me tromper

J’avais une fois un acheteur qui m’a envoyé une capture d’écran de paiement qui semblait irréprochable — le bon montant, la bonne banque, le bon horodatage. J’ai failli libérer la transaction. Puis je me suis souvenu de la seule règle que je m’étais promis de ne jamais enfreindre : ouvrir ma propre application bancaire, pas la leur. Rien ne s’était reflété. La capture d’écran était fausse.

Ce marché m’a appris plus que n’importe quel guide. Aujourd’hui, je vérifie le taux d’achèvement du partenaire et l’historique des commandes avant même d’accepter une transaction, pas seulement sa “médaille”. Je fais correspondre le nom de l’expéditeur aux détails de la commande à chaque fois. Et quand un acheteur m’a soudain demandé de « terminer ceci sur Zalo, c’est plus rapide » — c’était mon signal pour ralentir, pas pour accélérer. Une transaction légitime n’a jamais besoin de quitter la plateforme.

Je conserve toujours chaque identifiant de commande et le journal de discussion après la clôture, même pour des transactions qui semblaient totalement routinières. La seule fois où j’en ai eu besoin, le fait d’avoir tout sauvegardé a transformé un litige stressant en une résolution le jour même.

Faites confiance aux vérifications de la plateforme, pas à une capture d’écran.

#binancep2pantoan @Binance Vietnam

Les dix secondes que j’ai presque ratées

Mon premier échange P2P m’a semblé instantané. Le séquestre a verrouillé la crypto du vendeur avant que je paie un dong, le chat a enregistré chaque message, et un canal de litige était à une pression de doigt si quelque chose tournait mal. Tout cela n’existe pas hors plateforme — pas de séquestre, pas d’historique de chat, pas d’accès au support. Ce n’est pas une règle : c’est une suppression.

Je vérifie maintenant trois choses. Le partenaire : badge, taux de complétion, historique des commandes, pas seulement un nom. Le paiement : mon propre app bancaire qui confirme que les fonds sont arrivés, jamais une capture d’écran. La pression : libération précipitée, échange de compte en plein milieu de la transaction, une demande de « déplacer ceci vers Zalo » — l’un suffit comme raison de faire une pause, deux ensemble sont une raison de contester.

Je conserve les ID de commandes, les reçus et les transcriptions du chat après chaque échange. Je n’en ai jamais eu besoin — jusqu’au jour où j’en ai eu besoin.

La vraie question n’est pas de savoir si le P2P est sûr. C’est lequel de ces contrôles vous sauteriez quand vous êtes pressé.

#baby $BABY @BabylonLabs_io

Bien avant tout ça, j’avais écrit au sujet de personnes se dirigeant vers le fournisseur de finalité le plus haut, sans vérifier. Je n’avais en fait jamais vérifié moi-même les vrais chiffres de distribution : je travaillais seulement à partir d’une anecdote. Du coup, j’ai été vérifier la répartition réelle des mises entre les différents fournisseurs pour voir à quel point c’était réellement mauvais.

C’était pire d’un côté et mieux de l’autre que ce que je m’attendais.

Les tout premiers fournisseurs détiennent une part disproportionnée, et ça correspondait à ce que je supposais. Ce qui m’a surpris, c’est la rapidité avec laquelle la courbe de concentration s’aplatit après les quelques premiers : une longue traîne de fournisseurs plus petits, chacun détenant une mise significative, non triviale — pas l’image « tout le monde s’est entassé sur un seul nom » que suggérait l’anecdote du groupe de discussion. Le problème, ce n’est pas un fournisseur unique dominant ; c’est plutôt une couche supérieure modérément concentrée, posée au-dessus d’une traîne réellement longue que la plupart des délégateurs ne prennent jamais la peine de faire défiler pour voir.

Point technique : cette distinction compte pour comprendre ce que signifie vraiment « corriger » la situation. S’il y avait un seul fournisseur dominant, la solution serait évidente : casser cette concentration. Avec une courbe qui s’aplatit, le système est déjà plus décentralisé que ne le laisse penser une observation superficielle ; le vrai décalage se situe entre ce qui existe et ce que les délégateurs pensent exister, puisque presque tout le monde à qui j’en ai parlé le décrit comme plus concentré que ne le montrent les données.

Auto-critique : j’ai rédigé la première version à partir d’une seule anecdote et d’un sentiment général, pas en m’appuyant sur des chiffres réels, et j’aurais dû vérifier ça plus tôt au lieu de supposer que la version « pire scénario » était la plus exacte. Les données réelles changent l’histoire : pas vers « aucun problème », mais vers une histoire plus étroite, plus précise.

Le récit de sécurité de $BABY serait plus solide s’il s’appuyait sur cette distribution réelle au lieu de laisser les gens supposer en se basant sur les noms qui sont le plus souvent mentionnés.

J’aimerais que Babylon affiche directement cette courbe de distribution dans l’interface de staking, car pour l’instant vous devez aller la chercher, comme je viens de le faire. #baby

⚠️ Ceci ne constitue pas un conseil financier. Faites vos recherches (DYOR).

#baby $BABY @BabylonLabs_io

Après avoir écrit au sujet de la réduction progressive des émissions et de la question de savoir si les revenus de frais peuvent combler le manque qu’elles laissent, je me suis mis à chercher les chiffres réels plutôt que de laisser le sujet dans l’abstrait. Je voulais savoir où Babylon publie la courbe d’émission et, idéalement, une projection des revenus liés à l’usage qui lui serait associée.

J’ai trouvé assez facilement le calendrier des émissions, des tableaux avec l’émission par période, les taux de décroissance, le tout clairement présenté.

Ce que je n’ai pas trouvé, c’est l’autre moitié de l’équation. Rien ne fait se croiser cette courbe d’émission avec le volume de prêts TBV projeté ou les revenus de frais de staking, et rien ne modélise le point auquel on est censé passer de l’un à l’autre. J’ai vérifié les publications de gouvernance, les mises à jour du blog, et même recherché toute prise de parole de l’équipe sur le sujet. Il y a beaucoup de discussion sur la croissance et l’adoption, mais rien n’est formulé comme « voilà à quoi devrait ressembler l’usage d’ici à ce que les émissions tombent à X ».

Point technique : publier un calendrier d’émissions constitue une base de transparence ; presque tous les tokens font au moins cela. Ce qui vous indique réellement si un réseau survit à sa propre phase de subvention, c’est la deuxième moitié : le côté des revenus qui rencontre le côté des émissions à un moment précis. Son absence ne signifie pas que Babylon n’a pas de modèle interne pour cela : les équipes calculent souvent ces chiffres en privé avant de s’engager dans des projections publiques. Mais de mon point de vue, en essayant de l’évaluer, le silence sur cette moitié se lit de la même façon, que la réponse soit rassurante ou préoccupante.

Auto-critique : je suis entré dans l’affaire en m’attendant à confirmer ou à infirmer ma propre inquiétude avec des chiffres concrets, et je n’ai obtenu ni l’un ni l’autre. Je n’ai fait que constater que le chiffre n’est pas public pour l’instant. C’est un constat différent et plus faible que ce que je cherchais, et je préfère le dire clairement plutôt que d’étirer le tableau d’émissions jusqu’à une conclusion qu’il ne soutient pas.

$BABY détenteurs sont effectivement en train de financer la transition sans qu’on leur montre le modèle correspondant.

J’aimerais que ce point de croisement soit publié, même approximativement, avant de considérer les niveaux de participation actuels comme autre chose que des émissions-subventions. #baby

#baby $BABY @BabylonLabs_io

Après avoir écrit sur la scission de gouvernance entre Babylon et Aave, j’ai décidé d’aller chercher une vraie proposition plutôt que de simplement décrire la structure en théorie. J’ai cherché le forum de gouvernance Aave et j’ai regardé tout ce qui touchait le marché BTC sur lequel TBV s’appuie.

J’ai trouvé des discussions. Je n’ai rien trouvé d’évident écrit pour quelqu’un venant du côté Babylon du produit.

Les propositions étaient denses : chiffres de pouvoir de vote délégué, écarts de paramètres listés en pourcentages bruts, évaluations de risque techniques faisant référence à des modèles que j’aurais dû consulter séparément pour comprendre réellement. Rien n’était caché : le forum est public, les horodatages et les décomptes de votes y sont. Mais rien ne donnait un cap à un utilisateur TBV vers tout ça ; pas de lien depuis l’interface même de Babylon, aucune notification indiquant qu’un paramètre affectant la garantie BTC était même soumis à un vote.

Point technique : j’y suis entré en sachant déjà que cette couche de gouvernance existait, car je venais juste d’en parler. Et pourtant, il a fallu un effort réel pour retrouver la proposition précise et comprendre concrètement ce qu’elle modifiait. C’est la différence entre « l’information est publique » et « l’information atteint les personnes qu’elle concerne ». Le processus de gouvernance d’Aave fait exactement ce qu’il est censé faire pour les utilisateurs d’Aave. Il n’a jamais été conçu en pensant à un dépositaire BTC venant de Babylon, et rien dans le flux actuel ne comble ce manque.

Auto-critique : je ne prétends pas qu’Aave doive redessiner sa gouvernance spécifiquement autour de TBV—ce n’est pas une demande équitable pour un protocole distinct. Mais j’y suis allé avec intention, et je me suis quand même senti en retard. Quelqu’un qui a déposé du BTC via le branding propre de Babylon, sans aucune raison de savoir que la gouvernance d’Aave existe, n’a essentiellement aucun chemin vers cette information.

$BABY utilisateurs sont exposés à des décisions prises dans une salle qu’ils ne savent même pas être une salle.

J’aimerais que Babylon affiche au moins un avertissement quand des propositions Aave pertinentes deviennent actives, ne serait-ce qu’un simple lien, plutôt que de laisser les utilisateurs tomber dessus par hasard comme je l’ai fait.

⚠️ Ceci n’est pas un conseil financier. Faites vos propres recherches (DYOR).

#baby $BABY @BabylonLabs_io

J’ai décidé de désengager (unstake) une petite position plutôt que de me contenter de lire comment le déliage (unbonding) fonctionne. J’ai cliqué sur “retirer” en m’attendant soit à une confirmation immédiate, soit à un compte à rebours clair. Je n’ai rien eu au début : seulement un statut indiquant “en attente” (pending), sans minuterie évidente me disant combien de temps allait durer l’attente.

Je suis retourné consulter la documentation pendant l’attente pour vérifier si j’avais raté quelque chose.

Je n’avais rien manqué : la période de déliage est bien documentée, elle n’est tout simplement affichée nulle part dans l’interface pendant le temps où vous patientez réellement. Je savais intellectuellement que le staking natif Bitcoin signifie que la sortie n’est pas instantanée, la même logique que pour le calendrier de règlement de TBV. Mais lire “il existe une période de déliage” avant, puis vivre un état “en attente” indéfini avec votre propre BTC, ce sont deux expériences différentes : l’une est de l’information, l’autre consiste à voir vos fonds quelque part que vous ne pouvez ni toucher ni suivre pleinement.

Point technique : le délai de déliage en lui-même n’est pas le problème. Chaque système de staking sérieux en a un : c’est justement ce qui rend le slashing applicable dès le départ. Vous ne pouvez pas punir une mauvaise conduite si les fonds peuvent sortir avant même qu’une violation ne soit détectée. Le problème se situe entre le fait que le mécanisme est sain et la façon dont l’interface le communique clairement pendant qu’il se déroule. Le silence pendant une attente est perçu comme une incertitude, même quand le processus sous-jacent fonctionne exactement comme prévu.

Auto-critique : je suis entré en sachant déjà comment le mécanisme fonctionnait, et pourtant l’ambiguïté m’a quand même rendu suffisamment anxieux pour re-vérifier la documentation en cours de route. Quelqu’un qui stake pour la première fois, sans ce contexte, a encore moins de raison de penser que le silence est normal, et davantage de raisons de croire qu’il y a un souci.

$BABY a besoin de personnes prêtes à immobiliser du BTC pour de vraies périodes, pas seulement à entrer, et la façon dont la sortie se ressent influence si quelqu’un recommencera.

Je voudrais un compte à rebours visible pendant le déliage, pas seulement un statut qui reste là, inchangé. #baby

⚠️ Ceci n’est pas un conseil financier. Faites vos propres recherches (DYOR).

#baby $BABY @BabylonLabs_io

J’ai replongé dans la documentation moi-même après avoir écrit au sujet de la manière dont personne dans un groupe n’arrivait à s’entendre sur le fait que le slashing touche aussi les délégataires, au lieu de simplement signaler la confusion et de la laisser là.

J’ai d’abord ouvert la documentation officielle. La section sur le slashing est courte : elle décrit le comportement punissable, la double signature ou l’équivoque, mais sans indiquer, en une phrase claire, si la mise des délégataires est réellement affectée. Je suis passé ensuite à des documents plus techniques, puis je me suis directement tourné vers le canal de la communauté pour demander.

La réponse que j’ai obtenue n’était pas fausse, mais elle n’était pas non plus totalement limpide : quelque chose comme « le mécanisme est conçu pour concentrer le risque du côté du fournisseur », pas un simple « les délégataires sont totalement en sécurité ». J’ai relu trois fois pour m’assurer que je ne déformais pas l’intention.

Point technique : ce qui m’a frappé, ce n’était pas une réponse fausse, c’était que la bonne réponse est dispersée à travers plusieurs couches : la documentation n’en couvre qu’une partie, l’explication de la communauté en complète une autre, et un utilisateur ordinaire doit assembler ces fragments pour avoir l’image complète. Pour un mécanisme qui décide si vous perdez du BTC ou non, devoir tout recoller comme ça constitue un vrai frein, pas une simple gêne mineure.

Auto-critique : j’avais l’avantage de savoir où chercher et d’avoir le temps de relire plusieurs fois. Quelqu’un qui délègue pour la première fois, impatient de commencer à gagner, ne passera presque certainement pas par toutes les étapes que je viens de faire, et finira par déléguer avec la même compréhension vague avec laquelle il a commencé.

$BABY n’attire du capital que si les délégataires comprennent le risque qu’ils portent réellement, et pas s’ils se contentent d’agir sur une impression de sécurité.

Je pense que Babylon a besoin d’une réponse claire et définitive, placée juste à l’étape de délégation, au lieu de laisser les utilisateurs aller la chercher comme je l’ai fait.

#baby $BABY @BabylonLabs_io

Quelqu’un qui délègue à un fournisseur de finalité de taille intermédiaire a demandé en groupe : « Si mon fournisseur est pénalisé (slashed) pour double-signature, est-ce que je perds aussi du BTC, ou seulement lui ? » Trois personnes ont répondu en même temps : deux ont dit « seulement le fournisseur », et une a dit « non, aussi les délégateurs ». Personne n’a cité de source ; le fil a juste enchaîné sur le sujet suivant.

Ce désaccord, qui existe même, est le problème.

Le modèle de staking de Babylon fonctionne parce que le BTC soutient des fournisseurs de finalité qui peuvent être punis en cas de mauvaise conduite : la double-signature ou l’équivocation étant la principale infraction qui déclenche une pénalité. @BabylonLabs_io a conçu le slashing comme mécanisme rendant la malhonnêteté coûteuse, exactement ce dont un système de sécurité distribuée a besoin. Mais le fait de savoir si ce coût ne touche que le stake propre du fournisseur ou s’il atteint aussi le stake délégué derrière lui est un détail qui détermine à quel point quelqu’un devrait réellement vérifier soigneusement à qui il délègue.

Point technique : ce n’est pas une nuance mineure. Si le slashing ne touche que le stake personnel du fournisseur, alors les délégateurs font face à un risque à la baisse limité lié à la mauvaise conduite du fournisseur, au-delà du coût d’opportunité, et choisir un fournisseur plus petit est vraiment peu risqué. Si le stake délégué partage l’exposition, alors chaque décision de délégation comporte un risque de queue réel, et déléguer par simple connaissance à n’importe quel fournisseur qu’un ami a mentionné cesse d’être une simple gêne et devient quelque chose de proche d’une due diligence. Trois réponses confiantes et contradictoires dans un seul fil suggèrent que ce n’est pas un savoir courant même parmi des personnes qui stakent déjà.

Auto-critique : je préférerais signaler que le désaccord existe plutôt que d’indiquer un chiffre que je ne peux pas vérifier pleinement moi-même ; c’est pire que d’admettre l’incertitude. Mais le fait que des délégateurs actifs ne puissent pas s’accorder sur leur propre niveau de risque à la baisse est, à lui seul, le constat.

L’argumentaire complet de staking de $BABY dépend du fait que les gens délèguent en confiance, ce qui exige qu’ils sachent d’abord à quoi ils sont réellement exposés.

Je voudrais que Babylon rende l’exposition des délégateurs au slashing impossible à mal comprendre, pas seulement documentée quelque part dans un texte technique.

⚠️ Ceci n’est pas un conseil financier. Faites vos propres recherches (DYOR).

$LAB créer le fond pas encore, les gars, achetez des billets de loterie peu nombreux, attendez le pump x3-x5, c’est parfait

#baby $BABY @BabylonLabs_io

Quelqu’un dans un groupe a posé une question simple après un ajustement de paramètre sur le marché Aave utilisé pour emprunter du BTC : « Qui a réellement approuvé ce changement ? » Quelques personnes ont deviné « la gouvernance Aave », quelques autres « Babylon », et une seule a répondu : « probablement les deux, est-ce que ça compte ? » Personne ne savait vraiment.

Je pense que c’est plus important que ce que laisse entendre « probablement les deux ».

TBV est en réalité deux systèmes cousus ensemble. @BabylonLabs_io gère les mécanismes côté Bitcoin, le coffre, les conditions de verrouillage et de déverrouillage, la partie « trust-minimized » vers laquelle tout le monde pointe. Mais dès que le BTC devient une garantie dans Aave v4, les ratios de loan-to-value, les seuils de liquidation, les courbes de taux et la configuration des oracles dépendent tous de la propre gouvernance d’Aave — un token distinct, des électeurs distincts, un processus entièrement différent.

Point technique : cela signifie que les paramètres de risque réels qui déterminent quand votre position se fait liquider ne sont pas quelque chose que Babylon contrôle, ni quelque chose qui peut vous protéger unilatéralement. La gouvernance Aave peut relever un seuil de liquidation, modifier un flux d’oracle ou ajuster un modèle de taux via son processus normal de proposition, et ce changement retombe directement sur les positions BTC des utilisateurs de TBV sans que Babylon ne soit celle qui prenne la décision. L’histoire de la garde « trustless » est entièrement celle de Babylon. L’histoire des paramètres de risque est entièrement celle de quelqu’un d’autre, et la plupart des utilisateurs vivent ces deux aspects comme un seul produit.

Auto-critique : je ne pense pas que ce soit un piège caché ; les deux processus de gouvernance sont publics et chacun peut regarder les propositions se dérouler. Mais « public » n’est pas la même chose que « visible » pour les personnes qui utilisent réellement TBV, qui y arrivent via le branding de Babylon et n’ont aucune raison évidente de suivre en même temps les forums de gouvernance Aave.

$BABY détenteurs peuvent influencer le côté Babylon de cette pile. Ils n’ont absolument aucun vote du côté Aave, qui détermine de plus en plus le risque pratique de détenir une position TBV.

J’aimerais avoir une carte plus claire de quelle entité de gouvernance possède quel mode de défaillance, avant de supposer que « c’est décentralisé » répond à cette question à elle seule.

#baby $BABY @BabylonLabs_io

J’ai suivi le flux TBV moi-même ce week-end, en utilisant un petit montant, juste pour voir l’ensemble de bout en bout. Dépôt de BTC, attente du verrouillage, puis emprunt de l’USDC contre celui-ci. L’étape du dépôt s’est bien passée. Ce qui m’a réellement fait faire une pause, c’est de voir le statut de confirmation rester là sans bouger bien plus longtemps que je m’y attendais.

Je n’ai cessé d’actualiser, à moitié en espérant une mise à jour instantanée façon EVM. Rien. Juste un statut qui n’avait pas encore changé.

Cette pause, c’est tout le produit, honnêtement. @BabylonLabs_io ne cache pas que ce sont des mouvements de collatéral natif Bitcoin, au rythme de Bitcoin, et non d’Ethereum. Mais lire ça dans la documentation et le vivre en direct, ce n’est pas la même expérience. Savoir intellectuellement que TBV évite les tokens encapsulés et les custodiens de pont, c’est une chose. Voir son propre BTC rester verrouillé alors que l’USDC emprunté sur Aave v4 est déjà dans son portefeuille, c’est une autre : du coup, le compromis paraît réel plutôt que théorique.

Point technique : l’asymétrie n’est pas un bug, c’est le coût réel et honnête de la suppression de la confiance via un custodian. Un pont vous donne de la vitesse parce qu’un custodian fait une promesse à votre place. TBV abandonne cette promesse, et le rythme de règlement propre à Bitcoin, c’est ce que vous récupérez en échange. Personne ne ment sur le mécanisme, mais la sensation de ce compromis ne se manifeste que lorsqu’on l’a réellement utilisé, pas quand on vient juste d’en lire la description.

Auto-critique : je suis entré en m’attendant à ce que l’histoire de la garde soit le gros argument, et je suis ressorti en pensant que, pour les utilisateurs, c’est surtout l’histoire du timing qui se fait ressentir en premier. Les docs expliquent les hypothèses de confiance. Elles expliquent moins bien ce que ça fait de regarder une barre de statut qui ne bouge pas.

Le pitch complet de $BABY repose sur l’idée que les gens acceptent cette patience comme prix du retrait d’un custodian, ce qui, en pratique, est une vente plus difficile que ce que ça ne paraît sur papier.

J’aimerais que davantage du message soit construit autour de ce que ça fait de l’utiliser, et pas seulement sur ce que ça supprime.

#baby $BABY @BabylonLabs_io

Quelqu’un a demandé sur un Discord Babylon : « Si mon fournisseur de finalité se comporte mal, est-ce que ça affecte aussi mon coffre-fort TBV, ou le staking et les vaults sont-ils des systèmes séparés ? » Un mod a répondu « des produits différents », et s’est arrêté là.

Je ne pense pas que cette réponse soit fausse, mais je ne pense pas non plus qu’elle soit complète.

Le côté staking de Babylon et TBV sont commercialisés comme deux choses différentes : l’un permet à BTC de sécuriser d’autres chaînes via des fournisseurs de finalité, l’autre permet à BTC d’emprunter contre lui-même via Aave v4. @BabylonLabs_io les a construits comme des produits séparés, mais les deux reposent au final sur la même couche de base : le script Bitcoin, ainsi que les mêmes mécanismes de timelock et de covenant qui permettent à BTC de bouger sans dépositaire.

Point technique : la propriété « trustless » (sans confiance) dans les deux produits provient de la même source : des conditions auto-exécutables appliquées sur Bitcoin, plutôt que par une partie de confiance qui les impose. La sécurité du staking dépend du fait que les fournisseurs de finalité se comportent honnêtement et soient suffisamment décentralisés, ce dont j’ai parlé auparavant. La logique de déblocage et de règlement de TBV dépend de la même classe de scripts natifs Bitcoin qui doit être correcte et active. Ce sont des applications distinctes, mais elles ne font pas des hypothèses de confiance séparées : c’est la même base utilisée pour deux finalités différentes.

Auto-critique : ça ne veut pas dire qu’un problème dans le staking casse automatiquement TBV, ou l’inverse ; les produits ne partagent pas d’état. Mais cela signifie que traiter le « risque de staking » et le « risque de vault » comme des catégories totalement sans lien, comme le suggérait la réponse du mod, trace une ligne qui est plus liée au marketing des produits que techniquement réelle.

$BABY est présent dans les deux produits comme couche de sécurité et d’incitation, et c’est précisément pour cela qu’une base partagée compte plus qu’un nom de marque partagé.

J’aimerais que Babylon soit explicite sur quels modes de défaillance sont réellement isolés entre le staking et TBV, et lesquels renvoient au même mécanisme sous-jacent.

#baby $BABY @BabylonLabs_io

Lors de la dernière bougie rouge nette, quelqu’un dans un groupe de trading a demandé : « Mon collatéral BTC sur TBV, s’il est liquidé, en combien de temps est-ce que ça se règle en réalité ? » Personne n’a répondu directement. Quelqu’un a juste dit : « ça devrait aller, Aave liquide rapidement », et la discussion a continué.

Cette réponse concernait la mauvaise chaîne.

Les liquidations d’Aave v4 sont rapides parce qu’Ethereum est rapide : des blocs toutes les douze secondes, des liquidateurs en concurrence pour clôturer presque instantanément les positions en dessous de l’eau. C’est le scénario auquel tout le monde pense quand il imagine le risque TBV. Mais le collatéral liquidé est du BTC natif, logé sous des conditions imposées par Bitcoin via le mécanisme de coffre (vault) de @BabylonLabs_io, et non un actif EVM qui se déplace à la vitesse EVM.

Point technique : un événement de liquidation, c’est en réalité deux horloges distinctes qui tournent en même temps. Le côté dette sur Aave peut être marqué et déclenché en quelques secondes. Le côté collatéral, c’est-à-dire le déverrouillage ou le déplacement du BTC réel hors d’un coffre, suit encore le rythme de règlement propre à Bitcoin : environ dix minutes par bloc, et plus long encore avec une profondeur de confirmation pour la sécurité. Dans les marchés calmes, ce décalage est invisible : une simple erreur d’arrondi que personne ne remarque. Dans une chute rapide, c’est précisément cet écart où le slippage, la mauvaise dette, ou le liquidateur qui absorbe des pertes peut apparaître : le prix auquel le côté dette a réagi et le prix auquel le côté BTC se règle réellement ne sont pas le même instant.

Auto-critique : ce n’est pas un défaut unique à TBV. Tout système de collatéral inter-domaines hérite quelque part du temps de règlement plus lent de la chaîne. Mais le marketing « sans confiance » décrit plutôt la garantie de garde et se tait sur le décalage temporel, alors que le timing est exactement ce qui casse en premier sous stress, pas la garde.

Le modèle de sécurité du staking de $BABY est construit autour des hypothèses de finalité propres à Bitcoin. La même patience qui rend Babylon sûr est donc aussi celle qui rend les liquidations rapides difficiles.

Je veux voir quel buffer, le cas échéant, Babylon met en place dans cet écart avant que des tests de volume réels ne le mettent à l’épreuve dans un crash. #baby

⚠️ Ceci n’est pas un conseil financier. Faites vos propres recherches (DYOR).

#baby $BABY

Quelqu’un dans un groupe a publié une capture d’écran de sa position TBV : « Plus de risque lié au pont, enfin du BTC dans DeFi fait correctement. » Quelqu’un lui a répondu : « Où se situe ton BTC, actuellement, en réalité ? » Il n’a pas répondu, il a juste republié la capture d’écran.

Ce non-répondre est l’angle qu’il faut garder en tête.

Les coffres Bitcoin sans confiance (Trustless) résolvent un vrai problème : pas de token enveloppé, pas de multisig de pont qui custodie ton BTC. @BabylonLabs_io a conçu le mécanisme pour que le BTC natif puisse servir directement de garantie d’emprunt, et la première version en production passe par Aave v4 : tu y déposes du BTC et tu empruntes USDC ou USDT en contrepartie. Le risque de garde côté Bitcoin diminue réellement. Mais le risque ne disparaît presque jamais : il migre.

Point technique : une fois que ta position adossée à ton BTC se retrouve dans Aave v4, tu hérites de la surface de risque d’Aave — bugs de smart contracts, manipulation d’oracles, changements des paramètres de gouvernance, comportement du modèle de taux d’intérêt sous contrainte. Rien de tout cela n’est nouveau pour Aave : c’est audité et éprouvé depuis des années. Mais ce n’est pas le même risque que celui que TBV a été conçu pour éliminer. Tu as échangé « quelqu’un contrôle mon BTC » contre « une pile de smart contracts contrôle ce que mon BTC peut faire », et ce ne sont pas la même catégorie, même si les deux sont compressées dans le même mot : sans confiance.

Auto-critique : je ne dis pas que cela rend TBV pire que le BTC enveloppé. Réduire le risque de garde reste une amélioration réelle, et le track record d’Aave est plus solide que celui de la plupart des opérateurs de pont. Le problème, c’est le raccourci marketing. « Sans confiance » est appliqué à l’ensemble de la pile alors qu’il ne décrit techniquement que la couche de custody, et c’est exactement cet interstice qui fait que les utilisateurs cessent de se demander où leur BTC est réellement placé.

La valeur de $BABY dépend de la croissance du volume TBV, lequel dépend de la confiance des utilisateurs en l’ensemble de la pile, pas seulement du mécanisme côté Bitcoin.

Je préférerais que Babylon nomme explicitement le risque côté Aave plutôt que de laisser « sans confiance » le couvrir discrètement.

#baby $BABY

Juste l'autre jour, un ami m'a envoyé un message : « Déposé du BTC sur le réseau de test de Babylon, emprunté du test USDC, fait en cinq minutes. »
Je lui ai demandé ce qu'il pensait du mécanisme sous-jacent.
Il m'a répondu qu'il n'avait pas vraiment regardé : il voulait juste que son portefeuille apparaisse sur l'explorateur avant la fin de la campagne.

C'est l'écart auquel je me heurte sans cesse avec les Trustless Bitcoin Vaults (TBV) : un problème difficile, pris en charge par des personnes qui, le plus souvent, ne réfléchissent pas au problème lui-même.

Utiliser Bitcoin dans la DeFi a longtemps signifié choisir votre poison. L’envelopper (wrap), c’est faire confiance à celui qui conserve le BTC et émet le jeton enveloppé. Le transférer (bridge), c’est faire confiance à un opérateur ou à un multisig — la surface exacte qui a été vidée plus de fois que quiconque ne veut le compter. @BabylonLabs_io built a conçu les TBV pour supprimer ce compromis : du BTC natif déposé directement comme collatéral, sans wrap, sans bridge qui conserve la garde pour vous. Le premier cas en direct est un emprunt adossé à du Bitcoin natif sur Aave v4, avec dépôt de BTC réel pour emprunter de l’USDC ou de l’USDT en contrepartie.

Point technique : « trustless » fait ici un travail précis. Vos clés restent les vôtres, le collatéral vit sous des conditions imposées directement par Bitcoin lui-même, et non sous forme de reconnaissance (IOU) enveloppée ailleurs. Cela ne veut pas dire que tous les risques disparaissent — les déclenchements de liquidation et le calendrier de déverrouillage du coffre restent des expositions que vous portez. Réduire le risque de garde est une vraie avancée. Ce n’est pas la même chose que supprimer tous les risques.

Autocritique : les utilisateurs du testnet qui cliquent rapidement ne sont pas paresseux. Quand une campagne demande un retour, faire le parcours une fois est l’usage rationnel du temps de n’importe qui. Le stress-test des cas limites demande des efforts que rien ne récompense différemment ; ainsi, le feedback penche vers « ça a marché » et reste mince sur ce qui casse réellement.

$BABY se trouve en dessous comme couche d’incitation, mais les incitations ne font que façonner des comportements orientés vers elles. Pour l’instant, rien ne distingue un simple clic rapide de quelqu’un qui a réellement essayé de faire échouer le coffre.

Je surveille si les récompenses de Babylon encouragent davantage ce type de tests « plus difficiles » avant que TBV n’avance vers le mainnet.

Top 70 + 350U = Dynamique pour l'événement à venir. Let’s go! 🚀💎 $BTC

Tham gia tại đây
Anh em làm sự kiện đua vol đi, chạy vol tầm 3k là lụm 70u, sự kiện này ít người tham gia nên mọi ng chiến mạnh nhé

Idol Ryker appelle l’entrée $SPCX vùng $129 l’heure s’apprête à être $132, est-ce que cette zone vaut la peine d’envisager d’importer des marchandises, les amis ?