Web3天命人-阿明

#termmax @TermMax
Récemment, j’ai vu une direction qui prend de l’ampleur dans les posts qui chauffent : on ne parle plus seulement de la « possibilité de mettre sur la blockchain », mais on commence à entrer dans l’étape suivante, celle qui concerne les garanties, la liquidité et la gestion des risques. Le 4 août, Ondo Perps a annoncé que l’USDC sur Arbitrum pouvait directement servir de collatéral pour ses transactions. Lors de la collecte de l’article, il comptait environ 112 000 vues. Cet événement ne signifie pas qu’@TermMax et Ondo ont une collaboration, mais il soulève une question plus générale : quand les portes d’entrée pour le trading d’actifs on-chain se multiplient, qui gère le coût du capital et le risque lié à l’échéance ? C’est justement pour cela que TermMax mérite d’être placé sur la même carte des infrastructures financières. Le marché à taux fixe ne crée pas forcément l’effet « buzz », mais il permet aux deux parties du prêt de voir d’abord clairement la date d’échéance, la structure des intérêts et le risque du collatéral. FT, XT et GT décomposent respectivement les titres à échéance fixe, la partie intérêts et les positions à effet de levier. L’accent n’est pas sur la promesse de rendement, mais sur le fait de rendre les coûts de la position et ses limites de risque plus calculables. Les discussions sur $TMX peuvent être suivies, mais ne doivent pas remplacer la vérification des conditions du contrat, de l’échéance et de la liquidation. Plus les échanges RWA sont dynamiques, plus la question de la détermination des taux mérite d’être discutée sérieusement.

#termmax @TermMax
La valeur des prêts à taux fixe ne consiste pas à écrire un rendement plus élevé, mais à rendre le coût du capital et l’échéance calculables à l’avance. En décomposant le marché des maturités en FT, XT et GT : FT correspond au principal à échéance fixe et aux titres de rendement, XT représente la partie intérêts, et GT encapsule les sûretés ainsi que la dette de levier sous forme de positions NFT. Une telle structure fait en sorte que l’emprunt, les rendements et l’effet de levier ne soient plus seulement une page APR variable, mais des composants on-chain modulaires. Le livre blanc officiel de TermMax définit $TMX comme un token de gouvernance et d’utilité, mais l’instant du TGE reste à confirmer via une annonce officielle ; avant de participer, vous devez vérifier les contrats, la maturité, la liquidité, ainsi que les risques liés aux smart contracts.#TermMax

#dusk $DUSK
@Dusk
Récemment Dusk : à voir absolument — ce n’est pas « encore un portefeuille de plus », c’est que l’entrée frontale de DuskDS est désormais en train d’être standardisée. Dusk Connect, ouvert aux développeurs en avril via une préversion, permet aux dApps de découvrir et de prendre en charge de façon unifiée les portefeuilles compatibles, de demander un compte, de signer et d’initier des transactions ; cela réduit les frictions liées à l’intégration personnalisée autour d’un portefeuille unique pour chaque application.

Le nouveau Dusk Wallet couvre les transferts publics/privés, Shield/Unshield, le staking et la collecte des récompenses. Moonlight rend le solde du compte et les transferts visibles, ce qui convient aux parcours nécessitant un audit ; Phoenix protège le montant et les liens de transaction grâce aux preuves à divulgation nulle de connaissance. Ces deux voies collaborent finalement au même niveau de règlement.

Pour Dusk, la vraie épreuve n’est pas de savoir si les fonctionnalités s’empilent, mais si les développeurs sont prêts à les intégrer, si différents portefeuilles peuvent fonctionner ensemble, et si ces capacités peuvent entrer dans les processus réels d’émission, de garde et de règlement d’actifs.#DUSK

#dusk $DUSK @Dusk
J’ai récemment pris le temps de lire sérieusement le livre blanc de Dusk, et je trouve que ce qui est vraiment intéressant ne se résume pas à la “blockchain de confidentialité”. L’ambition est de réunir, au sein d’une même infrastructure, la confidentialité, la conformité et la tokenisation d’actifs du monde réel.
Dusk protège la confidentialité des transactions grâce aux preuves à divulgation nulle (zero-knowledge proofs), tout en satisfaisant les exigences réglementaires via la divulgation sélective. 😁 Phoenix et Moonlight prennent respectivement en charge les transactions privées et les transactions publiques, tandis que Succinct Attestation assure un règlement final rapide et déterministe 😇. Et avec DuskEVM et des cas d’usage RWA, l’objectif est très clair : permettre aux actifs réglementés comme les valeurs mobilières et les fonds de pouvoir être émis, échangés et réglés 🤔 directement on-chain.
Si la prochaine phase des RWA passe du “récit” à de vraies infrastructures financières🤑, alors Dusk mérite d’être suivi de près.

#baby $BABY
Comprenez le fait de mettre des BABY en gage comme « percevoir des revenus, la gouvernance se fait ensuite ». Il manque peut-être un élément de pouvoir : si vous ne votez pas, le validateur pourrait voter à votre place.

Les règles de gouvernance de Babylon Genesis sont écrites très clairement : les détenteurs de BABY peuvent voter, mais si le délégant ne vote pas, le vote du validateur est automatiquement hérité. Autrement dit, le staking ne consiste pas seulement à remettre des tokens au validateur : vous intégrez aussi une partie de vos choix de gouvernance dans la logique de délégation par défaut.

Cette règle par défaut comporte un décalage temporel facile à ignorer. Si vous votez avant le validateur, le système n’héritera pas du vote du validateur ; si le validateur a déjà voté, vous pouvez ensuite encore utiliser votre propre vote pour le remplacer. Mais pour les propositions urgentes, la période de vote n’est que de 1 jour : il est possible que, dès que vous voyez le message, après avoir lu la discussion, la fenêtre soit déjà terminée. Les votes des propositions ordinaires durent 3 jours, avec un rythme plus souple. Une fois le vote soumis, il n’est plus modifiable, donc « regarder plus tard » n’a pas zéro coût.

Mon avis : choisir un validateur BABY ne doit pas seulement se baser sur les commissions et les récompenses anticipées. Il faut aussi vérifier s’il continue de s’intéresser à la gouvernance, s’il vote en temps voulu, et quelle est sa position publique lorsqu’il représente le poids de la délégation. Ce n’est pas une question de deviner exactement ce que tel validateur va voter : il s’agit d’identifier le risque de gouvernance lié à la délégation par défaut. Ne pas participer en est aussi un résultat.

La prochaine fois que je consulterai une proposition, je vérifierai d’abord trois moments : quand le vote se termine, si le validateur a déjà voté, et si mon vote est déjà enregistré on-chain ; puis je confirmerai si la proposition est ordinaire ou urgente. Si votre portefeuille ne contient que le solde mis en gage, sans rappel de gouvernance, le « staking passif » de BABY pourrait aussi céder passivement votre pouvoir de décision.#baby $BABY @BabylonLabs_io

#baby $BABY
Si vous avez commencé à re-vérifier votre portefeuille à cause des discussions récentes autour de COLDCARD, ne confondez pas tout de suite les trois mots « portefeuille froid » avec « capable de mettre en jeu (staking) BABY ».
La position officielle de COLDCARD est très claire : c’est un portefeuille matériel matériel Bitcoin uniquement (Bitcoin-only), dont le cœur de la fonction est la signature hors ligne et la protection de la clé privée Bitcoin. Les outils officiels de BABY Staking de Babylon n’ont actuellement pas non plus COLDCARD inscrit dans la liste de prise en charge ; dans le même tableau, pour les « BABY Address » et le « BABY Staking » de Keplr, Cosmostation et Leap, il s’agit de Coldlar, c’est-à-dire que le BABY Staking se fait sur l’adresse Coldlar. Coldlar et COLDCARD ne sont pas le même produit : les noms se ressemblent, mais les limites fonctionnelles ne doivent absolument pas être confondues.
Pour les utilisateurs de BABY, la vérification réellement importante porte sur la compatibilité en trois niveaux : pouvez-vous créer ou connecter une adresse Babylon, pouvez-vous initier une délégation BABY, et pouvez-vous finaliser un co-staking BTC-BABY conjoint sous la même adresse. Sur le site officiel de Babylon, l’usage de BABY est décrit comme le staking, le co-staking BTC-BABY et la gouvernance, mais cela ne signifie pas que n’importe quel portefeuille matériel Bitcoin puisse directement prendre en charge ces opérations.
Donc l’évaluation la plus sûre est la suivante : COLDCARD convient pour la conservation et la signature hors ligne « Bitcoin-only » ; pour BABY Staking, privilégiez d’abord les solutions marquées comme prises en charge par l’outil actuel de Babylon, puis confirmez la version, le réseau et les exigences liées à l’adresse. La documentation officielle rappelle aussi clairement que la liste peut évoluer. La prochaine fois qu’un sujet chaud revient, commencez par vérifier si « l’adresse BABY » et « le BABY Staking » sont bien deux éléments à ne pas confondre : ne vous fiez pas uniquement au fait qu’un portefeuille soit appelé « portefeuille froid ».@BabylonLabs_io

#baby $BABY
Déposer le BTC en garantie sur un protocole de prêt, le plus facile à négliger n’est pas le taux d’emprunt, mais plutôt la question de savoir si « une autre chaîne peut ou non confirmer l’état de ce BTC ».

Sur son site officiel, Babylon décrit aujourd’hui le processus des Trustless Bitcoin Vaults (TBV) de manière très directe : d’abord, verrouiller le BTC natif dans un Vault, ensuite rendre l’état de la garantie vérifiable sur Ethereum, enfin obtenir une liquidité en stablecoins via Aave v4. Cet enchaînement montre que l’argument clé des TBV n’est pas « ajouter une autre porte d’entrée vers le prêt », mais plutôt transformer le fait de la garantie du BTC en un état que des protocoles externes peuvent lire.

Ce n’est pas la même chose que d’envelopper le BTC en un token puis de le transférer inter-chaînes. La description du staking Bitcoin de Babylon sur le site insiste aussi sur l’absence de besoin de wrapping, pegging ou bridging ; mais « conserver la garde du BTC tout en obtenant de la liquidité » et « un protocole de prêt peut déjà accepter en toute sécurité cette garantie » sont deux propositions différentes, qu’il ne faut pas confondre.

À l’heure actuelle, il faut surtout retenir que le site fournit encore une entrée « Launch TBV Testnet ». Le fait que le testnet fasse tourner le processus ne signifie ni que le mainnet est déjà ouvert, ni que le ratio de collatéral, la liquidation, l’oracle et les conditions de sortie ont été validés par une expérience suffisamment longue. En particulier, une fois des stablecoins empruntés, les fluctuations du prix du BTC, un état contractuel anormal ou une route de sortie bloquée peuvent transformer une « garantie vérifiable » en risque réel.

Par la suite, trois indicateurs méritent d’être surveillés : le BTC natif est-il toujours dans les conditions de Vault attendues, l’état de la garantie lu du côté Ethereum reste-t-il continuellement cohérent, et, en dehors du testnet, des paramètres et divulgations de risques publics du mainnet apparaissent-ils. Le véritable point de bascule des TBV n’est pas de pouvoir cliquer sur la page d’emprunt, mais de savoir si ces trois couches d’état peuvent être vérifiées de manière indépendante.#baby $BABY @BabylonLabs_io

#baby $BABY
Ce week-end encore, il faudra faire des heures supplémentaires. En rentrant, je commande à manger à l’extérieur : l’erreur la plus fréquente n’est pas de ne pas avoir récupéré le coupon, mais d’avoir récupéré des coupons sur deux téléphones différents, puis de ne finalement pas les appliquer à la même commande. Le double jalonnement (BTC+BABY) de BABY présente un problème d’« apurement » similaire : BTC et BABY sont bien verrouillés, mais cela ne signifie pas forcément que le système les comptabilise ensemble.

Selon les règles officielles de Babylon, l’enjeu n’est pas le fait, “dit à l’oral”, que ce soit “la même personne”, mais plutôt de savoir si les deux delegations sont liées au même adresse BABY. Si les adresses ne correspondent pas, les récompenses du jalonnement conjoint peuvent tomber directement à 0 ; et BTC et BABY ne doivent pas rester simplement en statut VERIFIED : les deux doivent passer dans un état ACTIVE, pris en compte pour le calcul des droits.

Le ratio a aussi un effet de limitation : w = min（nombre de BABY ÷ 20 000，nombre de BTC）. Par exemple, 0,1 BTC avec 1 000 BABY ne donne qu’un poids conjoint réel de 0,05 BTC ; pour “consommer” pleinement le poids de 0,1 BTC, il faut environ 2 000 BABY. Mettre davantage d’un côté ne dépassera pas la limite de l’autre : pour de petites quantités, on calcule au prorata, sans qu’il soit nécessaire de tomber exactement sur un seuil entier.

À mon avis, ce qu’il faut vraiment surveiller dans le jalonnement conjoint de BABY, ce n’est pas le chiffre de gain individuel mis en avant dans la publicité, mais si, en même temps, l’adresse, le statut et le ratio correspondent. Les 2,35 % doivent aussi être compris comme un paramètre d’inflation annuelle du pool de récompenses partagées, et non comme un APR fixe pour chaque personne ; après avoir modifié la composition des participants et le poids total du réseau, la part de chacun change. La prochaine chose à consigner est donc l’état des delegations, le poids effectif et le poids total du réseau : toute mise à jour d’un paramètre peut rendre obsolètes les anciennes estimations de gains.#baby @BabylonLabs_io

#baby $BABY
BABY a déjà franchi la zone et a aussi commencé à rapporter. Ensuite, j’ai ouvert moi-même le shopping à deux pour faire une commande groupée et atteindre le seuil de réduction ; les produits et les coupons avaient pourtant été bien choisis, mais au moment du paiement, j’ai constaté que la remise ne s’était pas appliquée. La raison est simple : une commande est passée avec un compte, le coupon est obtenu avec un autre, et la plateforme ignore complètement qu’il s’agit de la même commande.
Le staking conjoint BTC-BABY se heurte aussi à ce petit détail. Ce n’est pas parce que « BTC a été staké et BABY aussi » qu’on obtient automatiquement une récompense supplémentaire : l’adresse BABY associée aux deux opérations de staking doit être exactement la même. Si les adresses diffèrent, le résultat indiqué par la documentation officielle est très clair : la récompense du staking conjoint est de 0.
Ne vous arrêtez pas non plus au simple statut VERIFIED et ne fermez pas la page. La délégation BTC doit encore passer à ACTIVE, et la délégation BABY doit également être en active ; ce n’est qu’alors que le système combinera les deux en une pondération de staking conjoint. « Vérifié » donne l’impression que tout est terminé, mais en réalité, on n’est pas encore entré dans la phase de comptabilisation.
La vraie formule est : w = min（quantité de BABY stakée ÷ 20,000，quantité de BTC stakée）. Par exemple, 0.1 BTC avec 1,000 BABY donne une pondération de staking conjoint de seulement 0.05 BTC ; pour exploiter pleinement la pondération de ces 0.1 BTC, il faut 2,000 BABY. À l’inverse, ajouter davantage de BABY n’augmentera pas la pondération au-delà de la quantité de BTC déjà stakée.
Ici, il n’existe pas de seuil du type « au moins 1 BTC ou 20,000 BABY » : les petits montants sont aussi calculés au prorata. Répartir le BABY entre plusieurs validateurs n’est pas un problème non plus ; tant qu’il provient de la même adresse, le système additionnera les montants.
Il y a aussi un chiffre très facile à mal interpréter : 2.35% n’est pas un APR fixe individuel, mais le pool annuel de récompenses d’inflation partagé par l’ensemble des stakers en staking conjoint. Le montant reçu par chacun dépend de la proportion de sa propre pondération par rapport à la pondération totale du réseau ; plus il y a de participants, plus la part distribuée pour une même pondération est petite.
Ainsi, ce mécanisme ne consiste pas simplement à « staker les deux jetons » ; il faut aussi que l’adresse, le statut et la répartition correspondent tous en même temps. Je vérifierai surtout quatre points : l’adresse BABY est-elle identique, BTC est-il bien passé à ACTIVE, la pondération réelle est-elle limitée par le maillon faible, et la pondération totale du réseau a-t-elle changé de manière significative. Les paramètres peuvent également être mis à jour ; avant toute opération, il faut encore se référer à la page officielle. Ce que le staking conjoint oublie le plus facilement n’est souvent pas l’action de staker, mais le fait que le système ait bien relié les deux comptes à la même adresse. #baby @BabylonLabs_io

#baby $BABY
Un véhicule inutilisé reste à la maison : le week-end venu, je vends cette voiture d’occasion. Au téléphone, l’acheteur répond simplement « j’arrive »—ce qui ne veut pas dire que l’argent est déjà crédité. Le prix est négocié, le contrat signé, mais pour que la transaction aboutisse vraiment, tout dépend finalement de sa capacité à sortir de la trésorerie immédiatement.
Le mécanisme de liquidation de TBV fonctionne de la même manière. Lorsque le facteur de santé passe sous 1.0, cela signifie seulement que l’interrupteur de liquidation est activé ; cela ne veut pas dire que le BTC a déjà été liquidé et converti avec succès. Le BTC natif sur Bitcoin : un rachat passe par claim, challenge et payout, ce qui prend généralement plusieurs jours. Impossible de faire, dans une seule transaction, l’opération de liquidation et les remboursements côté Ethereum en même temps.
La méthode actuelle de Babylon consiste à placer une couche intermédiaire de LLP. Par défaut, le BTCVaultSwap fournit un règlement immédiat à partir des réserves WBTC d’Aave Hub : le liquidateur rembourse d’abord et récupère du WBTC. Ensuite, le vault décompté est placé en escrow. Les arbitragistes enregistrés l’achètent ensuite, et le côté Bitcoin du rachat se fait progressivement. En clair : on avance d’abord le WBTC pour solder les comptes côté Ethereum.
Mais cette avance n’est pas un puits sans fond. La documentation officielle est très directe : si la liquidité en WBTC d’Aave Hub ou le allowance du Vault Swap n’est pas suffisant, les transactions de liquidation sans permission vont revert. Les arbitragistes enregistrés peuvent toujours passer par le direct redemption, mais il y aura beaucoup moins de parties capables de reprendre.
Il y a aussi un palier UTXO, facile à ignorer. Un vault ne peut pas être liquidé à moitié : si la position ne comporte qu’un seul vault, un dépassement même léger peut déclencher la fermeture de l’ensemble de la position, et l’UTXO complet sera alors intégré à la liquidation. La valeur sur-séquestrée servira à rembourser selon un mécanisme de juste valeur, ou sera compensée par du WBTC : ce n’est pas tout qui tombe à zéro. Le Portal officiel recommande donc par défaut de scinder en « sacrifier un vault + protéger un vault ».
Les paramètres actuels et la démo ci-dessus s’appuient sur le testnet public de TBV : le signet BTC, le mock WBTC et les stablecoins n’ont pas de valeur monétaire.
Donc, quand je regarde TBV aujourd’hui, je ne me contente pas de surveiller le facteur de santé : je regarde aussi la profondeur en WBTC dans Hub, le allowance du Vault Swap, et depuis combien de temps les vault en escrow peuvent être achetés. La ligne de liquidation n’est qu’un interrupteur : après l’avoir activé, c’est la présence de liquidités et d’un acheteur qui détermine si ce système peut résister dans un contexte de marché sous pression.#baby @BabylonLabs_io