W Shakespeare

Hier, j’ai passé la majeure partie de la journée à essayer un emprunt adossé à du BTC natif via Aave v4 sur le réseau de test public de Babylon.
Après avoir suivi le flux de liquidation sur le testnet, j’ai remarqué quelque chose de moins évident : la manière dont le système gère les cas où la liquidation prend plus de BTC que ce que la position nécessite réellement. Comme chaque Trustless Bitcoin Vault (TBV) est un unique UTXO, le protocole ne peut pas toujours saisir exactement le montant requis. L’excédent est d’abord affecté à toute dette restante, et s’il reste encore de la valeur après cela, le déposant reçoit la différence en WBTC plutôt qu’en BTC natif.
C’est une autre forme d’équité. L’excédent provient du BTC natif, mais le déposant est compensé avec un autre actif censé conserver la même valeur sur Ethereum. Dans des conditions normales, cette distinction ne fait peut-être pas beaucoup de différence. Elle devient plus importante pendant les périodes de forte volatilité, lorsque les liquidations ont davantage de chances de se regrouper et que la valeur qu’un utilisateur peut réellement récupérer en WBTC peut différer du BTC pris en excès. Ce que je ne sais pas encore, c’est si un versement qui est correct selon la comptabilité du protocole laisse aussi le déposant intégralement compensé dans la pratique. L’oracle peut attribuer la bonne valeur en dollars, tandis que les coûts de conversion ou les conditions de marché peuvent quand même faire que l’utilisateur reçoive moins de BTC natif que ce que l’excédent était censé représenter. La question est de savoir si l’équité tient après le règlement, et pas seulement au moment où le versement est calculé. C’est pourquoi je surveille la valeur en BTC que les utilisateurs peuvent réellement récupérer à partir de ces paiements en WBTC lors d’événements de liquidation réels.
$BLESS $BABY #baby @BabylonLabs_io ✨

J’ai essayé un emprunt natif adossé au BTC via Aave v4 sur le testnet public de Babylon. La première étape consistait à créer un Trustless Bitcoin Vaults (TBV). J’ai terminé ma partie de la configuration et je m’attendais à ce que le coffre-fort passe à l’étape suivante. Il est resté en Pending.
Je pouvais voir que le Vault Provider avait coordonné le graphe de transaction et collecté les signatures de PegIn. Je ne comprenais pas pourquoi un ACK manquant pouvait encore empêcher le coffre-fort de devenir Verified.
Ensuite, j’ai regardé de plus près la règle de readiness.
Chaque participant requis doit reconnaître que sa partie de la configuration est terminée. Le Vault Provider peut collecter ces ACK. Il ne peut pas en envoyer un à la place de quelqu’un d’autre ni ignorer un ACK manquant.
Ma première réaction a été qu’un participant avait trop de pouvoir. Il n’avait pas besoin de prendre le BTC ni de modifier le graphe de transaction. Il lui suffisait de rester silencieux, et l’activation s’arrêterait.
Mais ce n’est qu’un côté de la frontière.
L’ACK manquant n’est pas un veto spécial remis à ce participant. Il existe parce que le coordinateur ne possède pas la définition finale de « ready ». Le Vault Provider ne peut pas dire au contrat que la configuration est terminée tant qu’un participant requis n’a pas confirmé sa partie.
C’est la garantie.
Le protocole peut exiger un ACK. Il ne peut pas forcer cet ACK à arriver à temps.
Ainsi, TBV réduit le risque que la readiness soit déclarée trop tôt en faisant dépendre la vivacité de davantage de parties. Un ACK manquant ressemble à un participant qui acquiert un pouvoir de veto. En pratique, ce veto est le coût de l’empêchement pour que le coordinateur possède la readiness.
TBV ne permet pas accidentellement à un participant de retarder l’activation. Il rend impossible l’achèvement de la readiness en présence d’un participant manquant.
Cela protège l’intégrité de la configuration. Cela transforme aussi chaque participant requis en partie du chemin de vivacité du coffre-fort.
Avant que je puisse passer à l’étape d’emprunt sur Aave v4, le statut Pending semblait différent. Ce n’était pas seulement un retard de configuration. C’était le protocole qui refusait de laisser la coordination devenir une approbation unilatérale.
Un ACK manquant donne-t-il trop de pouvoir à un participant, ou révèle-t-il le pouvoir que le Vault Provider aurait sinon ?
$BABY $BLESS #baby @BabylonLabs_io

Hier, j’ai essayé un emprunt adossé à du BTC « natif » via Aave v4 sur la testnet publique de Babylon. Ce qui m’a surpris, c’est ce qui s’est passé après avoir remboursé la dette fictive.
Côté Aave, tout semblait terminé. Ma dette avait été effacée, donc je m’attendais à ce que le BTC soit à un clic final.
Mais Repay ne fait que mettre fin à l’obligation de prêt. Avant que le vault puisse quitter Aave v4, chaque réserve doit être entièrement libérée. Cela inclut aussi les intérêts déjà ajoutés. L’utilisateur retire ensuite le vault de la position. Cela supprime l’enregistrement interne du collatéral, mais le Bitcoin reste toujours verrouillé dans son Taproot UTXO.
Ce n’est qu’après cela que le flux revient vers Trustless Bitcoin Vaults (TBV). Le fournisseur du vault publie une Claim. Une preuve ZK circule via Assert, puis le protocole attend pendant une fenêtre de challenge d’environ 432 blocs Bitcoin. Le paiement n’arrive qu’une fois ce processus terminé.
Cela m’a donné deux versions très différentes de « terminé ». Aave en avait fini avec ma dette. TBV n’en avait pas fini avec mon Bitcoin. La distinction est logique au niveau du protocole. Aave gère le prêt sur Ethereum, tandis que TBV contrôle comment le BTC sort de son vault sur Bitcoin. Mais l’expérience produit peut brouiller cette passation. Un utilisateur peut voir une dette à zéro et supposer que toute la position est clôturée.
C’est l’enseignement que j’ai tiré de la testnet. L’emprunt natif adossé au Bitcoin n’a pas une seule sortie. Il y a une sortie de prêt et une sortie Bitcoin, et elles se terminent sur des calendriers différents. Sans cette séparation, le remboursement donne l’impression d’être une ligne d’arrivée alors que c’est en réalité un relais.
Je pense que Babylon devrait rendre ces étapes impossibles à confondre. Le portail pourrait afficher d’abord « Dette remboursée », puis « Vault retiré d’Aave ». Ensuite, il pourrait passer à « Rachat du BTC en cours. »
La dernière étape a besoin de plus qu’un simple spinner. Elle devrait afficher l’étape actuelle de TBV et le nombre de blocs de challenge restants. L’adresse de paiement devrait aussi rester visible. Un avertissement clair doit expliquer que la clôture de la dette Aave ne libère pas le BTC immédiatement.
Babylon relie déjà les deux couches au sein d’un seul flux. Le prochain défi UX consiste à montrer précisément où une couche se termine et où l’autre commence.
@BabylonLabs_io $1000RATS $BABY #baby

J’ai essayé le flux du testnet TBV de Babylon pour emprunter contre du BTC natif via Aave v4. La première étape majeure a été la création d’un Trustless Bitcoin Vault (TBV). Avant l’activation du vault, le portail m’a demandé de télécharger les artefacts du claimer.

Ce paquet fait partie du parcours de self-claim. Si le rachat normal ne se termine pas, le déposant peut en avoir besoin pour récupérer le BTC. La clé Bitcoin reste importante, mais elle ne peut pas accomplir ce processus à elle seule. L’outil de récupération a aussi besoin de données liées à ce vault. Cela inclut le fichier WOTS, le graphe des transactions, la clé de vérification et les données de session BABE.
Les documents de Babylon expliquent la responsabilité immédiate. Exportez les fichiers et conservez-les en sécurité. Ce que je n’ai pas pu trouver, c’est un plan pour garantir que ces fichiers restent exploitables dans le temps.

Un vault peut rester ouvert pendant des mois ou des années. Le TBV peut changer pendant cette période. Les commandes de récupération peuvent changer, et les formats de fichiers peuvent passer à une nouvelle version. Le portefeuille qui a créé le vault peut cesser de prendre en charge l’ancien bundle. Les dépendances plus anciennes peuvent aussi disparaître.$KOMA
Cela crée un type de risque de récupération différent. Les fichiers peuvent rester intacts, et la clé Bitcoin peut rester sécurisée. Pourtant, l’utilisateur peut avoir besoin de l’ancien logiciel pour lire le paquet. La documentation ne précise pas si les outils futurs prendront en charge tous les bundles antérieurs. Elle n’explique pas non plus si Babylon archivera les builds legacy. Je n’ai pas non plus trouvé de façon claire d’identifier quel outil de récupération correspond à chaque version du vault.

Le TBV est encore sur le testnet public, donc la politique de compatibilité n’est peut-être pas encore définitive. Babylon pourrait prendre en charge les anciens bundles dans un outil de récupération. Il pourrait aussi archiver les builds antérieures et leurs instructions.

Pour l’instant, je ferais une sauvegarde qui va au-delà des fichiers du claimer. J’enregistrerais la version du vault et je conserverais aussi l’outil de récupération correspondant. Les données de récupération ne survivent pas seulement parce que les fichiers existent encore. Le logiciel qui les comprend doit aussi survivre.

Pensez-vous que Babylon abordera cela dans une mise à jour future du testnet TBV ? Est-ce que @BabylonLabs_io définira comment les anciens paquets de claimer restent récupérables après le changement des outils et des formats de fichiers ?
$BABY #baby ✨

J’ai supposé qu’un coffre Bitcoin sans confiance basé sur Babylon (TBV) avait encore 1 clé derrière tous ses scripts Taproot.
Peut-être que le déposant la détenait. Peut-être que le fournisseur du coffre. Ou alors que plusieurs participants pouvaient l’utiliser ensemble s’ils étaient tous d’accord.
Puis j’ai vérifié la clé interne Taproot.
C’est une clé publique NUMS, sans clé privée correspondante connue. Cela rend le chemin de clé inutilisable.
Une sortie Taproot donne normalement à la BTC deux façons de bouger. Une façon suit un script engagé et doit satisfaire ses conditions. L’autre utilise la clé privée correspondant à la clé interne. Cela permet à celui qui dépense d’éviter de révéler ces scripts.
TBV abandonne volontairement cette deuxième voie.
Aucun participant ne peut contourner le graphe de transaction avec une dépense par chemin de clé. La BTC ne peut sortir que par des voies préparées avant que la sortie du coffre n’ait été créée.
Au début, j’ai lu cela comme un simple choix anti-arrière-porte. Je pensais qu’il supprimait seulement une échappatoire cachée.
Puis j’ai remarqué ce que ce choix fait perdre.
Le déposant, le fournisseur du coffre et d’autres participants peuvent plus tard s’accorder sur une nouvelle destination. Leur accord ne peut cependant toujours pas créer un nouveau chemin de transaction.
Si le chemin n’a pas été préparé avant que la BTC ne bouge, il n’est pas disponible maintenant.
La clé interne bloque une sorte de contournement. Elle ne prouve pas que le graphe de transaction a été conçu correctement. Elle ne peut pas non plus ajouter plus tard un chemin de secours.
Personne ne peut improviser une dépense malveillante via le chemin de clé. Personne ne peut non plus improviser une dépense utile via celui-ci.
Cela a changé ma façon de penser la garde (custody) dans TBV.
Le protocole ne choisit pas la personne la plus sûre pour détenir l’autorité finale. Il rend cette autorité inutilisable via le chemin de clé.
La vraie décision se fait plus tôt. Les chemins de dépense autorisés doivent être choisis avant que la BTC n’entre dans le coffre.
La question ne porte pas seulement sur qui contrôle le Bitcoin. Elle porte aussi sur ce que le coffre était construit pour permettre avant que le Bitcoin ne bouge.
Rendre le chemin de clé inutilisable rend-il le coffre plus sûr, puisque personne ne peut contourner ses chemins préparés ? Ou bien le rend-il plus rigide, puisque personne ne peut ajouter un nouveau chemin après que la BTC a bougé ?
Pas de clé finale, ou pas de seconde chance ?
@BabylonLabs_io $BANK $BABY #baby ✨

Je me suis heurté à An ce matin. C’est un investisseur baleine, et il déteste le capital oisif.
Je lui ai dit que les coffres Bitcoin Trustless de Babylon (TBV) disposent d’un Circuit Breaker. En cas de problème sérieux, le Conseil de sécurité peut utiliser un Soft Pause ou un Full Pause.
Le Soft Pause bloque les dépôts, les emprunts et les retraits. Le remboursement et la liquidation peuvent continuer.
« Ça a l’air utile », a-t-il dit. « Pendant combien de temps peuvent-ils le geler ? »
J’ai ouvert la documentation.
« Je ne trouve aucune limite. »
« Qu’est-ce qui le remet en ligne ? »
« Rien de public non plus. »
Il a fronçé les sourcils. « Alors cette version de TBV n’est pas prête pour moi. »
J’ai insisté en disant que le conseil ne peut ni récupérer son BTC ni l’envoyer ailleurs. Les parcours de récupération du Bitcoin fonctionnent encore quand leurs conditions sont réunies.
« Cela prouve que mon BTC ne peut pas être volé », a dit An. « Mais ça ne me dit pas combien de temps le capital cesse de fonctionner. »
Un utilisateur particulier peut mettre 1 680 $ de BTC dans un coffre TBV. Une pause fait mal, mais elle ne changera peut-être pas le reste de ses finances.
An pourrait répartir 1,1 million de BTC sur plusieurs coffres. Ce collatéral peut servir à soutenir des prêts, des couvertures ou des engagements de liquidité ailleurs.
3 heures, c’est gérable.
1 jour crée un autre bilan.
Il lui faudrait plus de stablecoins en attente. Il pourrait remplacer le crédit ailleurs. Sa couverture continuerait de coûter de l’argent.
La récupération du Bitcoin ne préserve pas la stratégie. Récupérer le BTC met fin à la position du coffre.
Cela ne maintient pas le prêt en vie. Et cela ne sauvegarde pas le plan de liquidité autour de ce coffre.
« Donc tu ne t’inquiètes pas de perdre le BTC ? » ai-je demandé.
« Non. Je m’inquiète d’une durée que je ne peux pas évaluer. »
Je lui ai rappelé que TBV est encore sur un testnet public. Il y a du temps pour ajouter une limite de pause et un processus de reprise plus clair.
La prochaine version pourrait définir ce qui se passe pour les positions déjà en cours.
Il a hoché la tête.
« Peut-être que cette version de TBV vise davantage les particuliers que des baleines comme moi. Les particuliers ont besoin d’une preuve que le BTC ne peut pas être redirigé. »
« J’ai besoin de savoir combien de temps le coffre peut rester inactif. »
C’était la partie que j’avais manquée.
Circuit Breaker donne @BabylonLabs_io du temps pour vérifier un correctif. Mais si personne ne sait combien de temps cette fenêtre durera, comment une baleine pourrait-elle chiffrer le risque d’utiliser TBV ?
$BEAT $BABY #baby ☘️

J’essayais de répondre à une question de base concernant les Babylon Trustless Bitcoin Vaults (TBV) : après qu’un emprunteur rembourse le prêt, combien de temps faut-il avant que le BTC natif redevienne utilisable ?

Le remboursement ne le libère pas. Il ne fait que démarrer la phase de rachat. Ensuite, TBV publie une réclamation sur Bitcoin, demandant au vault de libérer le BTC.

Cette réclamation reste ouverte pendant 432 blocs Bitcoin. Environ 3 jours.

Durant cette fenêtre, les Universal Challengers et Vault Keepers inspectent la réclamation. Une faute valide peut arrêter le paiement. S’ils ne trouvent rien, le BTC est libéré une fois la fenêtre refermée.

Le réglage à 432 blocs appartient à la version actuelle en testnet public de Babylon. Pour l’instant, des tailles de rachat différentes utilisent la même fenêtre.

Un vault de 0,01 BTC attend 432 blocs. Un vault de 0,1 BTC aussi.

Cela m’a semblé raisonnable. Tout système optimiste a besoin de temps pour que quelqu’un puisse faire objection.

Puis j’ai remarqué ce que fait vraiment le paramètre.

TBV ne mesure pas une réclamation, ne décide pas à quel point elle paraît risquée, puis ne choisit pas une attente. L’attente est déjà là. La réclamation arrive plus tard et en hérite.

Ainsi, une sortie petite et une sortie beaucoup plus grande achètent le même temps de vérification. Pas parce que leurs risques sont égaux. Parce que le protocole a choisi un prix fixe pour l’incertitude.

L’utilisateur paie ce prix en perdant l’accès au BTC.

La position de prêt est clôturée. L’actif natif reste toutefois verrouillé. Pendant environ 3 jours, il ne peut pas servir à soutenir un autre prêt, couvrir un appel de marge, couvrir une position avec une couverture, ni être retiré en cas de crash.

Le nombre de blocs reste fixe. Le coût, lui, ne l’est pas.

Un marché calme peut rendre 432 blocs bon marché. Un marché violent peut rendre la même attente brutale.

Je comprends le compromis. Une fenêtre fixe est plus facile à auditer. Un timing dynamique pourrait créer de nouvelles surfaces d’attaque si quelqu’un manipule les signaux utilisés pour qualifier une réclamation comme étant à faible risque.

Mais le choix de conception est néanmoins brutal.

TBV applique la même taxe temporelle à des risques qui ne sont pas les mêmes.

Plus encore, il fait que chaque sortie honnête finance par défaut la suspicion du pire scénario du protocole.

Si TBV ne peut pas tarifer chaque rachat séparément, est-ce que chaque utilisateur devrait payer comme si le sien pouvait être le plus dangereux ?

$ON $BABY #baby @BabylonLabs_io

J’ai l’habitude de lire les annonces de partenariat de Babylon comme des mises à jour distinctes. Ledger pour la signature. Aegis pour les taux fixes. GoMining pour le déploiement.

Puis je les ai mises dans l’ordre.

Elles ressemblaient à une feuille de route construite autour des limites des coffres-forts Bitcoin sans confiance (TBV) de Babylon.

TBV résout d’abord le problème de garantie. Le BTC natif peut rester sur Bitcoin tout en étant affecté à une application financière. Cela crée une position d’emprunt. Mais cela ne rend pas cette position compréhensible, prévisible ou utile.

La première limite apparaît avant l’approbation.

Une transaction de coffre-fort peut être valide tout en restant difficile à lire. Ledger intervient ici. Il a vendu plus de 8 millions de signataires, et son intégration TBV ajoute la signature native avec Clear Signing.

Babylon peut définir correctement la transaction. Ledger réduit l’écart entre ce que fait la transaction et ce que l’utilisateur pense approuver.

La prochaine limite apparaît après que le capital devient disponible.

Un emprunteur peut accéder à la liquidité tout en étant incapable de planifier autour d’elle. Les coûts variables peuvent changer après l’ouverture de la position. Babylon peut sécuriser la garantie, mais elle ne peut pas rendre le coût du prêt prévisible.

Aegis comble cet écart avec un emprunt à taux fixe ciblé pour le T4 2026, sous réserve du développement et des tests. Fixer le taux donne aux emprunteurs un coût de financement connu. Un trésor peut comparer ce coût au rendement attendu de l’utilisation du capital.

GoMining répond à la limite qui suit le financement.

Babylon peut débloquer la liquidité en stablecoin contre le BTC. Elle ne peut pas décider où ce capital devrait aller ni si cela justifiera la dette.

GoMining donne au capital un usage défini. Son déploiement proposé pourrait activer jusqu’à 1 000 BTC. Les stablecoins empruntés seraient déployés dans des produits de minage, tandis que les récompenses seraient payées en BTC. Il relie le prêt à une stratégie opérationnelle avec un rendement mesurable.

Pris ensemble, les partenariats montrent comment la feuille de route de Babylon grandit à partir des limites de TBV.

Chaque limite révèle ce qu’il faut construire autour de TBV et quel partenaire est nécessaire pour y répondre.

@BabylonLabs_io
$BANK $BABY #baby ✨

Quand j’ai d’abord ouvert le graphe de transactions des Trustless Bitcoin Vaults (TBV) de Babylon, la sortie de 240 satoshis m’a semblé hors de propos. Elle se trouve à l’index de sortie 2 sous le script P2A 51024e73. Assez petite pour être ignorée. J’ai failli le faire.

Ensuite, je l’ai comparée avec la version 1.

Le graphe plus ancien avait deux sorties. La version 2 passe à nVersion 3 et ajoute l’ancrage. Au début, j’ai supposé que Babylon réservait un minuscule coussin de frais. Faux. Les 240 satoshis ne sont pas là pour couvrir uniquement la confirmation. Ils servent à créer une sortie qu’un enfant permettant l’augmentation des frais (fee-bumping) pourra dépenser plus tard, augmentant ainsi les frais du “package” afin que les nœuds de support et les mineurs puissent évaluer le parent et l’enfant ensemble.

Cela a changé ma compréhension de la transaction.

Un PegIn peut être préparé pendant que les frais Bitcoin sont bas, puis diffusé après que la congestion a modifié le marché. Il peut rester valide et rester intact, car ses frais reflètent les conditions d’hier. Babylon ne peut pas connaître le prix de compensation futur au moment où le coffre est créé.

Donc, il laisse une partie de la décision de tarification ouverte.

Pas pour toujours. Juste assez longtemps pour que le vrai marché des frais apparaisse.
Grâce à l’ancrage P2A, TBV peut réagir après un changement des conditions au lieu de reconstruire la transaction originale du coffre. C’est plus important que les 240 satoshis eux-mêmes. La conception accepte que la prédiction échouera. Elle préserve la marge de manœuvre.

Mais cette marge est étroite. TRUC est une politique de relais, pas une règle de consensus Bitcoin. Le chemin de diffusion et suffisamment de nœuds doivent encore prendre en charge le package. Une intégration peut construire correctement les deux transactions et les acheminer via une infrastructure qui gère mal l’enfant. Valide sur le papier. Manquant sur le chemin que les mineurs voient.

Les coffres plus anciens font face à une limite plus dure. Un PegIn v1 ne peut pas recevoir le nouvel ancrage une fois sa version estampillée. Les conditions de frais futures peuvent changer. Sa structure de transaction ne le peut pas.

Les 240 satoshis ont cessé de ressembler à un simple détail de frais. Elles révèlent une vérité plus dure : Babylon peut expédier un nouveau graphe TBV, mais un coffre existant conserve sa version estampillée.

La V2 gagne une nouvelle façon de réagir. La V1 conserve les limites d’hier.

À quel moment la version du coffre fait-elle partie du risque de l’actif ?

$BANK $BABY #baby @BabylonLabs_io

J’étais en train de mettre à jour une version locale de Babylon Trustless Bitcoin Vaults lorsque j’ai remarqué quelque chose d’inhabituel. À chaque fois que le commit de vault-wasm change, 2 suites de tests doivent rester identiques octet pour octet avant qu’on puisse aller plus loin : les vecteurs dorés JavaScript dans vault-secrets et le test d’égalité des transactions v1 dans pegin.test.ts. Si l’une des sorties dérive de façon inattendue, la mise à niveau s’arrête là.
Cela m’a amené à me demander ce que ces tests protégeaient réellement. Une recompilation WASM ne se produit que lorsque btc-vault publie un nouveau commit, tag, release, ou modifie son API de bindings. Mon hypothèse est que cela n’arrive que quelques fois par an.
Personne ne peut raisonnablement inspecter chaque implémentation Rust et vérifier manuellement que les scripts de paiement générés, les blocs de contrôle et les hachages des scripts Taproot restent identiques. Comparer des sorties observables coûte bien moins cher que de reprover l’implémentation à chaque fois.
Puis j’ai remarqué autre chose. 2 développeurs qui compilent la même source peuvent tout de même obtenir des binaires WASM différents d’environ 64 à 100 octets. Un nom d’utilisateur de 3 caractères, répété dans 29 chemins de debug intégrés, suffit à modifier le binaire. Pour un binaire ne mesurant que quelques centaines de kilo-octets, cela représente environ 0,02% à 0,04% de sa taille. L’implémentation a changé. Le comportement, lui, ne l’a pas.
Cette distinction m’a semblé plus importante que les chiffres eux-mêmes. Babylon accepte de tolérer du bruit à l’intérieur de l’artefact tout en refusant même un seul octet inattendu de dérive dans les sorties observables. L’un relève de l’environnement de build. L’autre est ce que chaque développeur peut vérifier indépendamment.
C’est à ce moment-là que le rôle des golden vectors a finalement fait sens pour moi. Ils ne sont pas simplement des tests de non-régression. Ce sont des références figées du comportement observable. Babylon n’a pas pour objectif de continuer à prouver que chaque implémentation est correcte. Il prouve qu’elles se comportent toutes de la même manière. Les toolchains peuvent changer, les binaires peuvent différer d’une machine de développeur à l’autre, et les implémentations peuvent évoluer. Mais dès que le comportement observable ne correspond plus à cette référence, le protocole a déjà changé.
$BANK $BABY #baby @BabylonLabs_io

En recherchant les coffres Bitcoin sans confiance (TBV) de Babylon, un détail n’a cessé d’attirer mon attention. L’outillage fixe Rust 1.94.1, exige des builds reproductibles et demande à chaque développeur de générer des binaires strictement identiques, octet par octet. Babylon semble se soucier du fait que tout le monde obtienne exactement le même résultat. Le produit réel, c’est donc la cohérence.
Si différents développeurs peuvent compiler la même source pour produire des binaires différents, de subtiles variations deviennent une autre variable que le système doit gérer. Babylon supprime cette variable avant le déploiement. Une seule source doit toujours produire un seul binaire et un comportement prévisible.
Cela explique aussi pourquoi la logique du coffre est compilée en WebAssembly plutôt que d’être réécrite pour chaque environnement. Rust reste l’implémentation sécurisée, tandis que WASM permet à la même logique d’alimenter des applications JavaScript et TypeScript. Plutôt que de reconstruire la logique centrale pour chaque intégration, Babylon conserve une seule implémentation et la réutilise à travers les écosystèmes.
Les décisions d’ingénierie ont commencé à ressembler à une stratégie économique.
Babylon choisit délibérément une approche « expensive-first, inexpensive-later » (coûteuse au début, moins chère par la suite). Construire une seule implémentation renforcée, verrouiller la chaîne d’outils et imposer des sorties identiques augmente le coût de la première construction. Mais chaque intégration future peut s’appuyer sur ce socle au lieu de le recréer, réduisant la maintenance, les bogues propres à l’implémentation et les risques de sécurité à long terme.
Bien sûr, cette stratégie comporte un compromis.
Le coût initial ne se rentabilise que si suffisamment de bâtisseurs réutilisent effectivement ce socle. Si l’adoption dans l’écosystème reste limitée, une grande partie de cette discipline d’ingénierie pourrait finir par ressembler à un surcoût inutile plutôt qu’à un avantage.
C’est pourquoi je ne pense pas que le TBV Public Testnet puisse démontrer si une approche « expensive-first, inexpensive-later » surpassera réellement la reconstruction de la même logique à travers des dizaines d’intégrations futures. Ironiquement, la preuve la plus solide n’apparaîtra peut-être que des années après le Testnet, lorsque les bâtisseurs continueront soit à réutiliser le même socle, soit l’abandonneront.
$RE $BABY #baby @BabylonLabs_io

Je vois sans cesse Babylon et Karak être placés dans la même conversation, parce que tous deux s’inscrivent dans le récit de la sécurité partagée. La plupart des comparaisons portent sur les modèles de staking, les mécanismes de slashing ou les actifs pris en charge. Après lecture plus approfondie, je pense que la vraie différence se situe ailleurs.
Babylon ne protège pas un produit. Il protège une philosophie de conception.
Tout commence par une hypothèse unique : les détenteurs de Bitcoin ne devraient jamais être forcés à faire confiance à un pont, à un dépositaire (custodian) ou à un actif “wrapped”. Une fois cette hypothèse rendue non négociable, l’architecture se dessine presque d’elle-même. Le staking de Bitcoin conserve le BTC sur le réseau Bitcoin. La sécurité vient du Bitcoin natif, et non du déplacement de capitaux entre écosystèmes.
Ce qui m’a surpris, c’est que cette philosophie n’a pas disparu lorsque Babylon s’est étendu au-delà du staking. Les Trustless Bitcoin Vaults auraient pu être une opportunité de compromis pour améliorer l’efficacité du capital. Au lieu de cela, @BabylonLabs_io continuait de poser la même question. Comment Bitcoin peut-il participer à la DeFi sans demander aux détenteurs de Bitcoin de changer ce qu’ils estiment fondamentalement fiable ? Le produit a évolué, mais le principe est resté exactement le même.
Karak part d’une croyance différente.
Sa stratégie repose sur la mise en productivité d’un maximum d’actifs numériques grâce au restaking. Une fois cette croyance fixée, l’architecture s’adapte naturellement. Des vaults, plusieurs types de collatéral, des risques isolés et une infrastructure dédiée ne sont que les conséquences de la poursuite de cet objectif.
C’est pourquoi je ne pense plus que Babylon et Karak se concurrencent uniquement sur le plan technologique. Ils reposent sur des croyances différentes concernant ce qui ne devrait jamais changer.
Le lancement du Public Testnet des Trustless Bitcoin Vaults de Babylon à la fin mai 2026 n’a fait que renforcer cette idée. Je le vois comme la preuve que la philosophie de Babylon n’a pas changé. Alors que beaucoup de protocoles remodèlent leurs principes pour s’adapter à de nouveaux produits, Babylon continue de construire de nouveaux produits autour du même principe. Pour moi, c’est là la vraie différence. Babylon ne parie pas sur une fonctionnalité. Il parie que les détenteurs de Bitcoin ne compromettront jamais ce qu’ils estiment digne de confiance.
$BANK $BABY #baby

Un détail de l’API de GRVT a attiré mon attention.
En plus de son API native, GRVT prend aussi en charge une intégration via CCXT, ce qui permet aux développeurs de se connecter en utilisant la même interface qu’ils utilisent déjà avec de nombreuses autres bourses.
Au début, cela ressemblait à une simple fonctionnalité de compatibilité.
Puis j’ai réalisé que GRVT réduit un coût qui apparaît avant même que le développement d’un produit ne commence. Ce coût se trouve dans la couche d’intégration, bien avant que les développeurs aient la possibilité d’améliorer eux-mêmes le système de trading.
De nombreux développeurs construisent déjà des bots de trading, des systèmes de trading algorithmique à partir de CCXT. Leur code d’intégration, leurs abstractions et leurs workflows de déploiement existent déjà. Ajouter GRVT ne nécessite pas de redessiner cette couche d’intégration simplement parce qu’une autre bourse a été introduite.
Cela change le point de départ de l’effort d’ingénierie.
Au lieu de revoir la connectivité, les développeurs peuvent continuer à construire par-dessus une couche d’intégration qu’ils connaissent et qu’ils jugent fiable. Plus de temps est consacré à l’affinage de la logique d’exécution, à l’amélioration des modèles de trading et au test de nouvelles idées, plutôt qu’au remplacement d’une infrastructure qui fonctionne déjà.
Le vrai coût n’est pas d’apprendre une autre API. C’est de réécrire des systèmes qui fonctionnent déjà avant même qu’un développement significatif puisse commencer. C’est là que l’Innovation Tax apparaît discrètement.
En prenant en charge CCXT, GRVT évite d’introduire cette taxe. Le code d’intégration et les abstractions existants restent réutilisables, ce qui permet à l’effort d’ingénierie de se diriger directement vers les parties d’un système de trading qui créent réellement une différenciation. La couche d’intégration cesse d’être l’endroit où les développeurs passent le plus clair de leur temps à adapter des logiciels et devient une base stable sur laquelle construire.
Le compromis est tout aussi clair. En réduisant l’Innovation Tax, GRVT renonce aussi à la possibilité de concurrencer grâce à une friction d’intégration ou à une expérience développeur propriétaire. Une fois la connectivité devenue familière, les développeurs évaluent GRVT beaucoup plus directement sur la qualité d’exécution, les capacités du produit et la valeur que la plateforme crée au-delà de son API. Plus il est facile de se connecter, plus le produit lui-même doit être difficile à concurrencer.
@grvt_io #grvt

En repensant à la compétition de trading GRVT KR / JP / CN, je ne pense pas que ce soit simplement une autre campagne de trading.
L’événement s’est déroulé du 2 février au 22 février, les participants choisissant l’une des trois places pays.
Après avoir relu les règles, je pense que la campagne résolvait deux problèmes différents en même temps.
Le premier : où créer de la liquidité.
Choisir la Corée, le Japon et la Chine n’était pas aléatoire. Ce sont trois des régions de trading crypto les plus actives au monde, avec une liquidité importante et des communautés de traders très dynamiques. Si GRVT voulait renforcer la liquidité avant le prochain TGE du token $GRVT, concentrer la campagne sur ces marchés lui donnait les meilleures chances d’attirer une activité de trading significative.
Le second : qui devait générer cette liquidité.
GRVT a explicitement exclu les comptes institutionnels, affiliés à des entreprises et basés sur une stratégie.
Si l’objectif avait simplement été de maximiser le volume de trading, cette décision n’aurait guère eu de sens. Les participants institutionnels auraient pu produire des chiffres bien plus élevés avec beaucoup moins de comptes.
Au lieu de cela, GRVT a augmenté la probabilité que l’activité derrière son volume provienne des utilisateurs particuliers.
Cela donnait à la bourse de meilleures chances d’attirer davantage de comptes approvisionnés, plus de traders actifs, plus de transactions, et une activité de trading répartie sur une base d’utilisateurs beaucoup plus large, plutôt que concentrée dans quelques gros comptes.
La différence n’est pas seulement statistique.
Ces indicateurs brossent un tableau très différent de l’échange GRVT. Au lieu d’avoir l’air d’une bourse dont l’activité dépend de quelques gros acteurs, @grvt_io a plus de chances de ressembler à une plateforme où la participation est large, organique et portée par la communauté.
La compétition s’est terminée en février.
Ses résultats ne deviendront peut-être pleinement visibles qu’une fois que $GRVT atteindra le marché.
Si cette stratégie a fonctionné, la compétition ne sera pas seulement retenue pour la liquidité qu’elle a aidé à construire, mais aussi pour l’histoire qu’elle a aidé GRVT à raconter sur l’échange au moment où le token a finalement été lancé.
$LAB #grvt

Je pensais autrefois que le Mainnet ressemblait à un coup d’envoi.
Le réseau passe en ligne, les développeurs arrivent, et tout le monde finit progressivement par comprendre comment jouer. La documentation s’améliore au fil du temps à mesure que de nouvelles questions apparaissent. Ce rythme est tellement devenu habituel en crypto que je le remettais rarement en question.
Puis j’ai regardé le protocole Newton.
Avant le Mainnet Beta, la documentation pour les développeurs couvrait déjà bien plus que le protocole lui-même. Il y avait des guides pour tester des politiques, enchaîner plusieurs oracles de données, déployer via la CLI ou le Dashboard, simuler des politiques de bout en bout, gérer des secrets et utiliser des Policy Packs. Ce n’était pas seulement une description de ce que les développeurs pouvaient construire, mais aussi de la façon dont ce processus était censé se dérouler.
Cela m’a amené à voir le lancement différemment.
Dans la plupart des écosystèmes, la documentation vient après le Mainnet. Les développeurs découvrent collectivement des conventions une fois le réseau en ligne, et ces conventions finissent lentement par devenir les standards officieux de l’écosystème.
Newton semble inverser cet ordre.
Au moment où le Mainnet Beta est arrivé, une grande partie du processus de développement avait déjà été documentée, structurée et démontrée. Les développeurs n’arrivaient pas sur une page blanche : ils entraient dans un environnement doté d’un workflow d’ingénierie établi.
La conséquence est plus importante qu’elle n’en a l’air au premier abord.
Quand chaque équipe découvre son propre workflow après le lancement, l’écosystème accumule naturellement des habitudes d’ingénierie différentes. Avec le temps, ces habitudes deviennent une fragmentation.
Quand le workflow vient en premier, le protocole distribue une approche d’ingénierie commune avec son infrastructure. Les développeurs restent libres de construire des applications différentes, mais ils commencent avec les mêmes hypothèses concernant l’écriture, les tests, la simulation et le déploiement des politiques.
C’est pourquoi le calendrier du Mainnet Beta de Newton m’a marqué.
Peut-être que le Mainnet n’était jamais censé être le moment où les développeurs apprennent les règles. Le protocole Newton semblait s’assurer que le guide arrive d’abord, afin que, lorsque le coup d’envoi arrive enfin, l’écosystème puisse consacrer moins de temps à comprendre comment jouer et plus de temps à décider quoi construire. @NewtonProtocol $LAB $NEWT #Newt

Après le prochain TGE, le token $GRVT aura plusieurs sources de demande.
Les utilisateurs pourront miser $GRVT pour débloquer l’adhésion et obtenir des avantages supplémentaires sur l’échange GRVT et son écosystème.
Ce n’est pas surprenant.
Ce qui m’a marqué, c’est une source de demande de tokens très courante qui, pour l’instant, ne semble pas faire partie de la conception de GRVT.
Utiliser $GRVT pour payer les frais de trading.
Si les utilisateurs devaient payer des frais de trading en $GRVT, chaque transaction créerait naturellement une demande supplémentaire pour le token.
Mais cela aurait un coût différent pour les utilisateurs.
Les gens ne veulent pas seulement des frais de trading bas. Ils veulent aussi des coûts de trading qui restent prévisibles, afin que le calcul du PnL, la réconciliation des transactions et le suivi des performances restent simples.
Une fois que les frais de trading sont payés avec un token dont le prix change constamment, ils cessent d’être un coût fixe.
À chaque fois que les utilisateurs calculent leur PnL ou réconcilient leur historique de trading, ils doivent également prendre en compte la valeur de $GRVT au moment où chaque frais a été payé.
Et s’ils conservent un solde de $GRVT spécifiquement pour les frais de trading, ce solde génère lui-même des gains et des pertes, distincts de la stratégie de trading elle-même.
Ainsi, GRVT pourrait tout à fait créer une autre source de demande pour son token, mais le coût serait finalement supporté par l’expérience utilisateur.
Au lieu de cela, il semble que GRVT soit disposée à laisser cette source de demande de côté.
Ce choix reflète la Discipline Token User-First de GRVT.
Plutôt que de pousser la volatilité de son propre token dans les frais de trading pour générer davantage de demande, GRVT permet aux frais de trading de rester simplement des frais de trading, tandis que le PnL reflète la performance des transactions elles-mêmes.
Les utilisateurs n’ont pas besoin de dissocier l’impact des variations de prix de $GRVT des résultats réels de leur stratégie de trading pour comprendre comment ils ont performé.
La vraie question se pose plus tard.
Alors que davantage de $GRVT entre en circulation et que la pression pour créer une demande suffisante pour absorber les déblocages de tokens futurs augmente, GRVT maintiendra-t-elle encore la priorité à l’expérience utilisateur et restera-t-elle fidèle à la Discipline Token User-First de GRVT ?
Ou @grvt_io will l’expansion de la demande de tokens finit-elle par prendre priorité ?
$SKHYNIX #grvt

En parcourant la documentation du protocole Newton, je me suis retrouvé à chercher les chiffres qui définissent généralement un protocole crypto.
TVL. TPS. Tableaux de benchmark.
Étonnamment, ils étaient à peine mentionnés. La plupart de la documentation porte plutôt sur les politiques, les simulations, les oracles de données, le déploiement et l’autorisation.
Ma première idée était simple : peut-être que ces chiffres ne valent pas encore la peine d’être mis en avant.
Mais après avoir lu davantage, j’ai commencé à me demander si les laisser de côté était en réalité un choix délibéré.
Une fois qu’un protocole donne au marché une métrique phare, ce nombre ne reste presque jamais une simple métrique. Il devient l’objectif à travers lequel les gens jugent les progrès. Les développeurs commencent à l’optimiser. La communauté le suit. Les comparaisons finissent naturellement par s’y référer. Au bout d’un moment, les décisions produit commencent à dériver vers l’amélioration de ce seul chiffre, parce qu’il est devenu la façon la plus simple de démontrer le succès.
C’est ce qui m’a fait penser au « Measurement Lock-in » (verrouillage par la mesure).
Une métrique est censée mesurer les progrès. Mais avec le temps, elle peut aussi commencer à les façonner. Plus un protocole s’ancre tôt dans un seul tableau de bord, plus il devient difficile de justifier des investissements qui ne font pas bouger immédiatement cette métrique, même s’ils renforcent l’architecture sur le long terme.
Newton Protocol, en revanche, construit encore une couche programmable de politiques qui pourrait, à terme, prendre en charge des agents IA, des wallets, des vaults, des RWA, et des cas d’usage qui n’ont pas encore pleinement émergé. À ce stade, @NewtonProtocol préserver la flexibilité peut compter davantage que de prouver la performance. Dès que le marché commence à juger un protocole à travers une seule KPI, chaque décision de feuille de route est inévitablement tirée vers l’amélioration de cette KPI. Ce qui commence comme un moyen de décrire le protocole peut progressivement devenir une contrainte sur la façon dont le protocole évolue.
Peut-être que c’est pour cela que l’absence de ces métriques m’a particulièrement marqué. Si Newton évite intentionnellement le « Measurement Lock-in », alors la question la plus intéressante n’est peut-être pas : « Pourquoi Newton ne publie-t-il pas plus de chiffres ? » C’est plutôt : « Quel type de protocole est encore trop tôt pour laisser une seule métrique définir à quoi ressemble le succès ? »
$NEWT $DEXE #Newt

La première fois que j’ai déposé du USDT sur l’échange GRVT, j’ai ouvert la liste des chaînes prises en charge.
Solana y était. La BNB Chain y était. Tron y était.
Mais Plasma n’y était pas.
J’ai été sincèrement surpris. Plasma a été conçu avec les stablecoins en tête, notamment l’USDT. Comme GRVT prend déjà en charge la plupart des grandes chaînes où la liquidité est concentrée, voir Plasma manquer m’a fait penser qu’ils pourraient passer à côté d’une source de capitaux importante.
En regardant au-delà de l’écran de dépôt, j’ai réalisé que ce n’était pas simplement une question d’ajouter ou de retirer une autre chaîne.
Chaque nouvelle chaîne signifie un autre portefeuille, davantage d’infrastructures, plus de surveillance, plus d’opérations et une plus grande surface de sécurité à maintenir. Prendre en charge une autre chaîne ne fait pas que multiplier les options de dépôt. Cela fait aussi évoluer l’infrastructure que GRVT doit exploiter au fil du temps.
C’est à ce moment-là que j’ai regardé à nouveau les chaînes déjà présentes dans la liste.
Solana, la BNB Chain et Tron sont toutes des écosystèmes où le trading et la liquidité DeFi sont profondément établis. Après un dépôt, le capital provenant de ces chaînes a davantage de chances de continuer à affluer vers l’activité de trading sur GRVT. Plasma, en revanche, a été conçu autour de paiements en stablecoins. Cela ne veut pas dire que le capital sur Plasma ne peut pas devenir du capital destiné au trading, mais cela signifie que GRVT doit se demander si l’activité de trading qu’il génère est suffisante pour justifier le coût d’intégration et l’infrastructure à long terme nécessaire pour soutenir une autre chaîne.
Vu sous cet angle, ce que GRVT optimise n’est peut-être plus le nombre de chaînes prises en charge, mais la Discipline d’Onboarding du Capital. Chaque nouvelle chaîne doit apporter plus qu’un capital supplémentaire. Elle doit aussi démontrer que le capital qu’elle introduit peut être converti en activité de trading qui justifie le coût opérationnel que GRVT est prêt à engager.
Ce que je vais surveiller, c’est la prochaine chaîne que GRVT choisit de prendre en charge. Si, un jour, Plasma apparaît sur cette liste, ce qui m’intéressera ne sera pas seulement d’avoir une option de dépôt en plus. Ce sera de comprendre ce qui a changé pour que GRVT conclue que le capital issu de la chaîne Plasma avait enfin atteint son niveau de Discipline d’Onboarding du Capital.
@grvt_io #grvt