BAAKU

La plateforme de titres tokenisés de NPEX sur Dusk a été présentée comme une preuve d’une traction institutionnelle, avec un objectif de 200 à 300 millions d’euros d’actifs réglementés devant circuler on-chain.
Fin avril 2026, la valeur totale immobilisée sur le réseau se situait sous 1 million de dollars.
Cet écart mérite qu’on s’y attarde. Une bourse néerlandaise réglementée intégrant le règlement on-chain exige un travail réel de licences et de conformité, et pas un simple choix marketing, et cette mise en place n’est pas anodine.
Cela dit, la préparation structurelle et le volume réel sont deux choses différentes. L’infrastructure peut être opérationnelle pendant que les actifs qu’elle devait transporter restent largement non émis.
Deux questions se posent. Ce retard correspond-il à un rythme normal d’onboarding de titres réglementés, où les processus juridiques et de garde évoluent plus lentement que les délais typiques du secteur crypto ? Ou bien le chiffre de 200 à 300 millions représente-t-il un plafond cible que personne n’a confirmé comme étant effectivement atteignable.
Une comparaison utile serait celle d’une route à péage ouverte à la circulation avant que le lotissement pour lequel elle a été construite ait commencé. La route fonctionne. Le volume pour lequel elle a été conçue n’est pas encore arrivé.
Vérifié à partir des données réseau disponibles au début de fin avril 2026.
#dusk $DUSK @Dusk

Le crépuscule ouvre une fenêtre de 36 ans pour ses 500 millions de DUSK restants. Sur le papier, cela semble lent.
D’après la page officielle de tokenomics, la moitié de ce pool, soit 250,48 millions de DUSK, est libérée au cours des 4 premières années. Chaque période suivante est divisée de nouveau par deux. Les années 32 à 36 émettent moins d’un million au total.
Le calendrier n’est pas progressif. Il est très concentré au début, puis il s’arrête presque.
Une première limite : cela concentre la nouvelle offre pendant que le réseau est encore le plus récent et le moins éprouvé, lorsque la découverte des prix est fragile.
Deuxième limite : de chaque récompense de bloc, 10 pour cent sont orientés de façon permanente vers un fonds de développement, avant que les stakers ou les validateurs ne voient leur part. Une revendication fixe, quelle que soit l’utilisation.
Une comparaison utile : les pools de capitaux propres d’une startup. Les fondateurs font souvent un « front loading » des attributions d’options pour attirer les premiers employés, puis ralentissent les attributions une fois que l’effectif se stabilise. La courbe de Dusk fait de même, sur un horizon de 36 ans plutôt que sur un cliff de 4 ans.
La question ouverte est de savoir si les incitations précoces compensent la dilution concentrée au cours des années un à quatre.
#dusk $DUSK @Dusk

NPEX est une plateforme de trading néerlandaise supervisée par l’AFM néerlandaise, avec un historique solide de financement des petites entreprises. Son partenariat avec Dusk est présenté comme permettant d’apporter près de trois cents millions d’euros de titres « on-chain ».
Le choix des mots compte ici. Les documents les plus récents de Dusk indiquent que ce montant est encore en cours d’intégration « on-chain », et non qu’il est déjà réglé. Plusieurs comptes rendus secondaires avancent au contraire que le même chiffre a déjà été tokenisé et déplacé. Aucune source primaire datée ne tranche ce point.
Une deuxième question ouverte concerne le statut réglementaire. NPEX a déclaré vouloir demander le régime pilote DLT de l’UE, qui lui permettrait de régler des transactions dans le cadre de ce nouveau dispositif. Aucune confirmation publique ne permet de savoir si cette demande a été approuvée ou si elle est encore en attente.
Cela ne rend pas le partenariat creux. NPEX fonctionne déjà comme une bourse agréée en propre, à la façon d’un détaillant bien établi qui peut tester un nouveau système de paiement tout en continuant d’opérer sous sa licence existante.
L’infrastructure est réelle. La part du volume annoncé qui est réellement en production n’est pas confirmée.#dusk $DUSK @Dusk

Citadel a été lancée en janvier 2023 comme un protocole de KYC à connaissance zéro pour Dusk.
La base de code actuelle, appelée Citadel 2, est une réécriture en cours. Ce n’est pas un produit fini.
Le dépôt indique que le code n’a pas passé un audit de sécurité complet. Il n’est pas destiné à une utilisation en production.
Cet avertissement tient toujours aujourd’hui. Pendant ce temps, la feuille de route de Dusk décrit Citadel comme l’outil permettant de supprimer les frictions liées au KYC et à la LMA dans le cadre des règles MiCA.
Une comparaison utile est celle d’un médicament encore en essais cliniques. Les résultats sont publiés. Les formules sont affinées. Aucun patient ne reçoit le traitement avant que les autorités réglementaires approuvent la version finale. Citadel est à un stade similaire : conçu, testé, mais pas encore certifié.
Deux points tempèrent cela.
Un avertissement de production concernant la cryptographie d’identité est normal avant un audit. Il ne signale pas, à lui seul, un retard.
Par ailleurs, aucune source disponible ne relie le processus d’onboarding actuel de NPEX à Citadel. Ce manque n’a pas empêché l’activité actuelle sur Dusk.
Aucune date publique n’existe sur le moment où l’avertissement pourrait être levé.
#dusk @Dusk $DUSK

Dusk Network est encore décrit comme le foyer du Contrat de Sécurité Confidentiel, ou XSC. Le terme remonte à la Whitepaper V2.0 de 2019, liée au modèle Zedger pour les actifs réglementés.
Les documentations techniques actuelles ne mentionnent pas XSC. L’émission passe désormais par Zedger et Hedger, la confidentialité par Phoenix et Moonlight. Le dépôt du protocole sur GitHub, marqué en travaux en cours, ne couvre que le consensus et l’économie. Les smart contracts sont placés dans les travaux futurs, sans aucune référence à XSC nulle part.
Deux interprétations correspondent aux éléments. XSC a peut-être été restructuré en Zedger et Hedger à mesure que le système a mûri. Ou il est resté un pitch de 2019 qui n’est jamais devenu une norme maintenue, remplacé discrètement.
Cela ressemble à une brochure qui liste un nom de fonctionnalité abandonnée, tandis que le manuel décrit la même fonction sous un nouveau nom. Les deux sont techniquement vrais. Seul l’un reflète ce qui est livré aujourd’hui.
Pour une infrastructure bâtie sur la confiance réglementaire, cet écart mérite d’être noté.#dusk $DUSK @Dusk

J’ai cherché XSC sur le site Dusk actuel. Il n’est pas sur la page d’accueil. Il n’est pas non plus sur la page des composants principaux. Cette page décrit plutôt Zedger et Hedger, et présente Hedger comme l’évolution de Zedger. XSC existe toujours. Je l’ai trouvé dans le glossaire, défini de la même façon qu’avant, simplement déplacé hors des pages principales de l’architecture. Première remarque. Il pourrait s’agir d’un ménage normal de la documentation. Les glossaires conservent souvent des termes plus anciens, sans signification plus profonde derrière. Deuxième remarque. La lignée de Hedger est documentée, pas cachée. Dusk indique clairement que Hedger a évolué à partir de Zedger, donc le changement ne se lit pas comme quelque chose de discret. Ça me rappelle une marque automobile qui abandonne un ancien nom de finition dans la brochure, alors que la fiche technique figure encore dans le manuel du propriétaire. La pièce reste. Le mot a juste cessé d’être tourné vers les clients. Je n’ai pas trouvé de publication expliquant le renommage. La fonction semble intacte. L’étiquette est passée à la fin du livre. #dusk $DUSK @Dusk

Au lancement sur le mainnet, Dusk a annoncé deux fonctionnalités ensemble : Dusk Pay, un circuit de paiement conforme à la MiCA, et Lightspeed, une couche 2 compatible avec l’EVM, assurant le règlement sur Dusk L1.
C’était en janvier 2025. Le langage de la feuille de route issue du T1 2026 liste encore Dusk Pay comme une fonctionnalité à lancer, et non comme une fonctionnalité déjà en cours de fonctionnement.
Entre-temps, la documentation technique actuelle décrit en détail une couche 2 EVM en activité, incluant le séquenceur, le batch (regroupement), et le règlement, mais sous un autre nom : DuskEVM. Lightspeed n’apparaît pas dans cette documentation.
Une explication est simple : un renommage pendant le développement. Les équipes le font souvent, et un changement de nom n’est pas une preuve à lui seul d’un produit en panne.
Une autre explication est que les priorités ont changé. Construire la couche EVM a peut-être eu la priorité, repoussant le circuit de paiements plus loin, sans que personne ne le formule clairement.
C’est un peu comme une entreprise qui annonce deux produits le même jour, en expédie un sous un nouveau label un an plus tard, et laisse les clients constater que l’autre n’a finalement jamais reçu de mise à jour.
Rien ici ne confirme un échec. Cela confirme plutôt un décalage entre ce qui a été dit et ce qui est documenté aujourd’hui.#dusk $DUSK @Dusk

Dusk a adopté Chainlink CCIP comme couche inter-chaînes pour les titres tokenisés sur DuskEVM, annoncée le 13 novembre 2025, aux côtés d’un partenaire boursier néerlandais réglementé.
Le problème, c’est la fragmentation. Un token de titre confiné à une seule chaîne a une portée limitée. CCIP permet aux tokens de circuler entre les chaînes, tandis que les émetteurs conservent la propriété des contrats et les limites de débit.
DUSK bénéficie aussi de transferts inter-chaînes via un modèle de brûlage et de mint, évitant ainsi la liquidité mise en commun.
Cela introduit une dépendance. Dusk est conçu pour minimiser la confiance grâce à des preuves à connaissance nulle et à une logique de conformité native. CCIP est externe. Son modèle de sécurité se retrouve désormais intégré au chemin de règlement.
Deux contrepoints sont importants ici. D’abord, le volume de production réel via CCIP pour ces titres n’est pas encore confirmé publiquement. Ensuite, les limites de débit côté émetteur offrent peu de protection si l’infrastructure de pont sous-jacente est elle-même perturbée.
Une comparaison utile : une banque qui envoie des fonds via un réseau de correspondants à l’étranger. Les contrôles propres à la banque restent intacts, mais le transfert dépend tout de même de la fiabilité du correspondant.

#dusk $DUSK @Dusk

L’accord de Dusk avec une bourse néerlandaise réglementée est de plus en plus présenté comme une mise à niveau de l’interopérabilité. Ce qui mérite d’être noté, c’est la bourse elle-même. Elle dispose déjà d’un statut de plate-forme de négociation autorisée et assure le règlement des financements pour les petites entreprises, pas la liquidité en crypto.
Cela change la nature de l’intégration. La norme d’interopérabilité adoptée ici ne concerne pas la vitesse. Elle fournit à un lieu réglementé un moyen documenté de transférer des actifs émis entre des chaînes, sous une forme que les régulateurs peuvent auditer.
Une comparaison concrète. Cela ressemble à l’adoption, par les banques, de systèmes normalisés de messagerie internationale il y a des décennies. Lent, peu glamour, conçu pour survivre à l’examen plutôt que pour impressionner les traders.
Contrepoint un. L’adoption de normes ne se traduit pas par un volume de règlement. À ce jour, aucune personnalité publique ne montre un flux de transactions en direct sur ce rail.
Contrepoint deux. L’autorisation réglementaire relève du partenaire boursier, et non de Dusk lui-même. Le rôle de Dusk dépend du fait que ce partenaire conserve son statut de conformité.
Qu’il s’agisse d’une infrastructure de règlement réelle ou que cela reste un pilote est encore une question ouverte.#dusk @Dusk $DUSK

Je n’ai cessé de revenir au flux de la Citadelle ce matin.
Un utilisateur demande une licence à un fournisseur de licences. Ce fournisseur vérifie la personne hors chaîne, signe les attributs pertinents, puis enregistre une licence chiffrée. Plus tard, l’utilisateur génère une preuve à connaissance zéro démontrant qu’il est bien propriétaire d’une licence enregistrée, sans inscrire sur le registre les informations personnelles ni la licence spécifique. Le contrat n’enregistre qu’une session publique.
C’est, dans la pratique, la partie de divulgation sélective. Le réseau ne voit jamais les attributs sous-jacents. Un service peut toutefois recevoir uniquement le champ exact dont il a besoin si l’utilisateur choisit de l’ouvrir.
Une situation réelle à laquelle cela correspond est celle d’un investisseur qui cherche à accéder à une offre de titres restreinte. Dans le processus traditionnel, l’émetteur ou l’agent de transfert reçoit souvent un ensemble complet de documents personnels pour confirmer le statut accrédité ou la résidence. Avec ce modèle, la preuve peut confirmer la condition requise tandis que le fichier complet reste privé et n’est pas exposé à répétition.
Deux points restent toutefois, pour moi, sans réponse.
L’ensemble du système dépend de fournisseurs de licences que les institutions auront réellement confiance. Le travail de vérification difficile se fait d’abord hors chaîne. Si ces fournisseurs restent peu nombreux ou tardent à apparaître, la couche de confidentialité on-chain n’a qu’une portée limitée.
Une preuve valide n’ouvre pas non plus automatiquement la porte. Le fournisseur de services applique encore sa propre politique après l’enregistrement de la session. Il détermine si l’attribut divulgué respecte la règle, si la session est toujours valide, et si le fournisseur de licences source est accepté. La cryptographie gère le chemin des justificatifs. La politique conserve la décision finale oui ou non.
La conception fait de la confidentialité le défaut et de la divulgation un choix délibéré. La question ouverte est de savoir dans quelle mesure ce partage fonctionne proprement lorsque des flux de travail réglementés réels commencent à l’utiliser à grande échelle.
#dusk @Dusk $DUSK

La documentation de Dusk indique que 500 millions de DUSK sont émis aux stakers sur 36 ans. Le modèle de décroissance divise par deux les émissions tous les quatre ans, à un taux de 0,5, libérant une quantité proche de la moitié de l’offre totale prévue au cours des quatre premières années.
Une comparaison utile : un plan de bonus sur dix ans qui verse la moitié de sa valeur totale dès la première année, puis de petites tranches ensuite, paraît stable sur toute sa durée, mais concentre le coût réel au début.
L’offre en circulation se situe déjà à près de 497 millions, contre une allocation de 500 millions avant le mainnet, ce qui laisse peu de risque lié à des déblocages. La pression sur l’offre provient désormais surtout des émissions liées au staking, plutôt que de chutes brutales côté investisseurs.
Deux contrepoints sont importants ici.
D’abord, des émissions “front-loadées” sont un choix de conception courant, qui n’est pas automatiquement un défaut. Des récompenses plus élevées au début peuvent renforcer la participation des validateurs tant que le réseau est encore jeune.
Ensuite, les chiffres de l’offre en circulation varient légèrement selon les calculateurs, et la participation réelle au staking derrière ces émissions n’est pas entièrement publique.
Le fait que ce calendrier ajoute (ou non) une pression pendant la phase actuelle d’adoption par les développeurs reste à déterminer.@Dusk #dusk $DUSK

DuskEVM permet aux développeurs de déployer des smart contracts écrits en Solidity, le langage que la plupart du code de contrats existant utilise déjà. Il fonctionne comme une couche d’exécution distincte qui revient ensuite à la couche 1 de Dusk. D’après la documentation officielle de Dusk, à jour en août 2026, les équipes peuvent utiliser des outils de développement familiers plutôt que de devoir reconstruire sur une infrastructure inhabituelle.
Cela supprime un obstacle spécifique. Historiquement, les chaînes axées sur la confidentialité ont imposé un choix. Les développeurs devaient soit réécrire les contrats dans des langages moins familiers, soit conserver leur code et perdre des fonctionnalités de confidentialité. DuskEVM permet aux contrats de s’exécuter en grande partie sans modification, tout en s’adossant à une chaîne conçue pour des transactions confidentielles et conformes.
Le gas sur DuskEVM est payé en DUSK. Les lots de transactions sont réintégrés sur la couche de base de Dusk pour la finalité et la disponibilité des données.
Deux points méritent d’être distingués de l’annonce elle-même.
D’abord, la compatibilité n’est pas l’usage. Un réseau qui accepte un code de contrat familier améliore l’accès. Ce n’est pas une preuve que les développeurs ou les capitaux y construisent déjà à une échelle significative.
Ensuite, ce type de compatibilité est désormais courant sur de nombreuses chaînes qui se disputent la même attention des développeurs. Sa valeur dépend du fait que les outils de transactions confidentielles et auditables de Dusk soient réellement utilisés, et pas simplement proposés.
Un exemple concret permet de l’ancrer. D’après des rapports de partenaires, une bourse européenne de valeurs mobilières, agréée, a tokenisé plus de 200 millions d’euros d’actifs traditionnels sur l’infrastructure de Dusk. C’est un exemple mesurable d’actifs réels qui passent effectivement on-chain, distinct d’une simple annonce de compatibilité.
Reste à savoir si l’activité des développeurs suivra à une échelle similaire : c’est une question ouverte, et non un résultat acquis.@Dusk #dusk $DUSK

DuskTrade, construit avec NPEX, revient dans les publications de la communauté avec un chiffre associé : plus de 300 millions d’euros en titres tokenisés. Ça vaut la peine de s’y attarder. En remontant la piste, ce montant n’apparaît que dans des publications sociales secondaires, et non dans une déclaration dédiée de Dusk avec un montant établi et une date. Ce décalage est léger, mais il compte si le chiffre doit être répété comme un fait.
Voici une façon simple de le comprendre. Une ville peut annoncer un projet de pont d’une valeur de 300 millions de dollars. Le chiffre est réel, mais il décrit le contrat, pas des voitures qui roulent déjà sur un pont terminé. Les titres tokenisés fonctionnent de manière similaire. La valeur d’une “pipeline” n’est pas la même chose qu’un règlement déjà intervenu on-chain.
Deux éléments jouent encore en faveur de Dusk ici. NPEX est une bourse réglementée sous la supervision financière néerlandaise, donc l’activité derrière DuskTrade ne démarrait pas de rien. Il existe aussi, désormais, des outils d’interopérabilité inter-chaînes pour soutenir un règlement vérifiable, ce qui comptera quand des chiffres réels datés seront publiés.
Pour l’instant, le chiffre à surveiller est celui qui est confirmé on-chain, pas celui qui est le plus souvent répété.#dusk @Dusk $DUSK

Vérifier un SNARK sur Bitcoin signifiait auparavant un litige on-chain coûtant plus de 14 000 dollars lors d’un récent test, selon des expériences BitVM2. BitVM3 a réduit le coût on-chain, mais a nécessité un circuit garblé de 42 Gio rien que pour l’installation, d’après son propre article. Le stockage a déplacé le problème, il ne l’a pas supprimé.
Le nouveau papier BaBe de Babylon, publié en février 2026 avec des chercheurs de Babylon Labs et de Berkeley, affirme un gain d’efficacité de 1000× par rapport à BitVM3 dans la vérification Groth16. C’est précisément la couche dans laquelle le vaultBTC sert de collatéral pour Aave V4, afin d’effectuer des vérifications de preuve bon marché et sûres.
Un détail. L’article de BitVM3 lui-même indique que BaBe y parvient en limitant les litiges à un ensemble de challengers autorisés, et non au modèle entièrement ouvert de BitVM3. Efficacité contre ouverture : c’est encore non prouvé à grande échelle et non testé en production.#baby $BABY @BabylonLabs_io

Je regardais un dossier de gouvernance concernant l’intégration du collatéral natif BTC de Babylon, essayant de comprendre ce qui, concrètement, fait fonctionner le chemin de liquidation. Enfoui dans la justification technique, il y avait une référence à un article appelé BaBe. Une fois que je l’ai ouvert, l’histoire m’a semblé différente du résumé marketing.
Bitcoin ne peut pas, nativement, vérifier un SNARK. C’est l’obstacle central à une DeFi BTC sans confiance depuis des années.
Un protocole antérieur, BitVM2, a résolu ce point en théorie. Mais ses propres notes de recherche indiquent que contester une allégation frauduleuse on-chain peut coûter plus de 14 000 dollars de frais. Cela ne fonctionne que si la fraude n’est jamais réellement contestée.
Un design de suivi, BitVM3, a réduit ce coût on-chain en déplaçant la vérification vers un circuit « garbled » exécuté hors chaîne. Cela a fonctionné, mais chaque circuit fait 42 gibibytes. La configuration et le stockage sont devenus le nouvel goulot d’étranglement.
BaBe est la réponse de Babylon à ce second problème. D’après l’eprint daté de février 2026, il conserve les économies on-chain de BitVM3 tout en réduisant les coûts de stockage et de configuration. Il est co-développé avec l’UC Berkeley et devrait être présenté lors d’une conférence de sécurité évaluée par des pairs plus tard en 2026.
Voici ce qui m’a accroché. Le flux de liquidation sur lequel un grand protocole de prêt voit actuellement voter sa gouvernance suppose que cette cryptographie tient bon en production, comme elle tient sur le papier.
Contrepoint un : la recherche sur Bitcoin sort souvent avant publication formelle. Attendre une date de conférence n’est pas la même chose qu’attendre que le mécanisme soit solide, et des évaluations indépendantes de sécurité peuvent valider un design avant même que l’article académique ne soit présenté formellement.
Contrepoint deux : l’hypothèse de confiance sous-jacente n’est pas nulle, mais elle est faible. La configuration du circuit garbled repose sur une méthode de « cut-and-choose », et des chercheurs qui examinent cette lignée de conception estiment la probabilité d’échec à environ 2 à la puissance de moins 40. En pratique, cela est considéré comme négligeable dans le domaine, et non comme un risque ouvert. Je continue d’y penser comme à un système d’extinction d’incendie qui a réussi tous les tests en laboratoire et qu’on installe maintenant dans un bâtiment occupé, dont l’audition de certification est prévue.$BABY #baby @BabylonLabs_io

J’ai passé une partie de mon week-end à faire quelque chose que j’apprécie vraiment : consulter directement la documentation technique propre à un projet plutôt que de me fier aux résumés qui circulent.
Cette habitude a payé cette fois-ci. Une grande partie de la couverture de 2026 décrit le Multi-Staking Mainnet de Babylon comme entièrement opérationnel. Mais la spécification actuelle de transaction de staking, écrite par l’équipe de Babylon elle-même, indique toujours qu’à l’heure actuelle, un seul fournisseur de finalité peut être sélectionné par stake, avec prise en charge de davantage de fournisseurs dans une version future du protocole.
Je me suis attardé là-dessus un moment.
Voici ce que cela signifie concrètement. Chaque transaction de staking verrouille Bitcoin dans un script qui code en dur exactement une clé publique de fournisseur de finalité. Si quelqu’un voulait déléguer le même BTC à deux réseaux différents aujourd’hui, il ne pourrait pas le faire dans une seule transaction. Il lui faudrait une deuxième transaction de staking et un UTXO distinct, c’est-à-dire deux stakes mono-réseau placés côte à côte, et non un stake multi-réseaux.
Je veux le lire de manière équitable, car il existe deux bonnes raisons pour que ce ne soit peut-être pas aussi inquiétant que ça en a l’air au premier abord.
La première, c’est que Babylon a déjà acquis une certaine confiance ici. C’est une équipe qui a déjà livré par étapes avec soin auparavant, et les limites initiales de staking sur Bitcoin avaient été remplies en quelques minutes seulement quand ils les ont ouvertes. Une mise à jour de script qui arrive après la couche de coordination est un choix de séquençage normal pour un projet qui gère des changements au niveau de Bitcoin : la prudence est la bonne instinct.
La seconde, c’est que l’opérationnel pourrait honnêtement signifier que le côté coordination et routage des récompenses est déjà prêt, même si le script Bitcoin n’a pas encore été mis à jour. Ce sont deux couches différentes qui accomplissent deux rôles différents, et il n’y aurait rien de surprenant à ce que l’une arrive avant l’autre.
Je n’ai pas trouvé de chiffre public indiquant combien de réseaux reçoivent réellement des délégations multi-stakées pour l’instant, donc je ne peux pas dire si cela est déjà largement utilisé ou si cela fonctionne seulement pour un petit groupe d’utilisateurs précoces, tandis que la majorité des Bitcoin sécurise encore un seul réseau à la fois.
Cela ne donne pas l’impression que la fonctionnalité n’arrive pas. Ça ressemble plutôt à ceci : Babylon va aller tellement loin.
$BABY @BabylonLabs_io #baby

Je parcourais le forum de gouvernance Aave pour la proposition relative au coffre-fort de Babylon, et un élément m’a fait m’arrêter et réfléchir.
L’idée est élégante. Verrouiller le BTC dans un UTXO Taproot sur Bitcoin. Obtenir un token miroir appelé vaultBTC sur Ethereum. L’utiliser comme garantie sur Aave V4. Pas de pont, pas de dépositaire, selon la proposition.
La conception de la liquidation est la partie la plus astucieuse. Comme le BTC natif ne peut pas être réglé instantanément, le processus se sépare en deux. Un liquidateur échange une position saisie contre du WBTC tout de suite, avec une petite prime, puis, une fois que la fenêtre de preuve de fraude se referme, quelqu’un d’autre revendique le vrai BTC sur Bitcoin.
C’est une manière réfléchie de séparer un problème que la plupart des gens ne penseraient pas à séparer. Le délai de plusieurs jours pour le règlement du Bitcoin est absorbé par celui qui achète le coffre-fort mis sous séquestre, et non par l’emprunteur ou Aave.
Deux points m’ont donné envie d’aller plus loin.
D’abord, Babylon décrit le staking et le système de coffre-fort comme une seule histoire de garantie, mais ils semblent être deux mécanismes différents. Le staking expose du BTC délégué à des pénalités (slash) si un fournisseur de finalité se comporte mal. Le coffre-fort est un UTXO verrouillé lié à des preuves de remboursement. Le fait qu’une position mise en coffre puisse aussi être déléguée, et ce qui arrive à un prêt ouvert si ce BTC est slashé en cours de position, n’est pas encore expliqué dans la documentation publique. Le propre forum de risque d’Aave a déjà un post distinct sur les pénalités de slashing de Babylon, rédigé avant l’existence de cette proposition de coffre-fort.
Ensuite, plus tôt cette année, un protocole de prêt a accepté un token ponté et générateur de rendement comme garantie. Le pont a été exploité. Les contrats propres du protocole étaient corrects tout du long, et pourtant il a tout de même subi des retraits se chiffrant en milliards sur une seule journée et a dû aider à organiser un fonds d’urgence. La leçon n’était pas liée au code de ce protocole. Il s’agissait de la quantité de confiance qui transite via un actif unique accepté.
C’est un peu comme un récépissé d’entrepôt sous garantie. Les marchandises restent hors site, le récépissé s’échange comme si c’étaient les marchandises, et chacun qui le détient fait confiance à un entrepôt qu’il n’a jamais inspecté.
$BABY @BabylonLabs_io #baby

Je vérifiais les chiffres d’approvisionnement de Babylon la semaine dernière et quelque chose ne me semblait pas juste.
BABY s’inflationne de 8% par an. Ce chiffre est fixe. Il est émis automatiquement, quoi qu’il arrive d’autre sur le réseau.
Le décalage est censé venir de la combustion. Lorsqu’un réseau partenaire envoie des récompenses de staking à Babylon, les gens enchérissent sur ces récompenses en BABY, et l’enchère gagnante est brûlée.
J’ai cherché un chiffre indiquant combien de BABY a réellement été brûlé jusqu’à présent. Je n’en ai pas trouvé. Toutes les sources décrivent le mécanisme, pas un résultat.
C’est mon premier doute. L’inflation est garantie. La combustion n’est pas encore prouvée.
Il est aussi question d’une proposition pour réduire l’inflation de 8% à 5,5%. J’ai vérifié si elle avait été adoptée. Non. Le taux actuel est toujours de 8%.
C’est mon deuxième doute. Les gens parlent de 5,5% comme si c’était déjà vrai. Ce n’est pas le cas.
Cela me rappelle un propriétaire qui augmente le loyer chaque année sans faute, tout en promettant un remboursement dès que suffisamment de locataires se coordonnent par eux-mêmes. L’augmentation se produit à chaque fois. Le remboursement dépend d’un effort dont personne n’a encore confirmé l’existence.
#baby $BABY @BabylonLabs_io

Je lisais les documents de tokenomics de Babylon et il y a une chose qui m’a vraiment surpris.
BABY a un taux fixe d’inflation annuelle de 8 % pour les récompenses de staking. Il ne diminue pas avec le temps. C’est stable, chaque année.
Au début, ça m’a semblé inquiétant. Mais plus je lisais, plus je me disais que c’était un choix de conception, pas un défaut.
Voici le mécanisme de compensation. À chaque fois qu’un Bitcoin Supercharged Network paie des récompenses, il paie en BABY, et ce BABY est brûlé. Donc plus l’écosystème est réellement utilisé, plus l’offre est retirée en retour.
Ça m’a rappelé une petite entreprise qui verse à ses employés un salaire fixe chaque mois, quoi qu’il arrive pour les ventes, mais qui ne rachète des parts de l’entreprise que lorsque les bénéfices le permettent. Les salaires sont garantis. Le rachat dépend de la bonne santé de l’activité.
C’est essentiellement ce qui se passe ici. Les validateurs reçoivent des récompenses prévisibles. La partie qui doit “gagner sa place”, c’est la combustion.
Contrepoint un, en faveur de ce design : une inflation prévisible est en fait bonne pour un réseau jeune. Les validateurs savent à quoi s’en tenir, indépendamment de l’humeur du marché, ce qui maintient la couche de sécurité stable pendant que l’écosystème continue de croître.
Contrepoint deux, aussi en faveur : c’est courant dans les réseaux en phase initiale. Les mécanismes de burn ont tendance à prendre du retard sur l’adoption au début, puis à rattraper leur retard une fois que l’utilisation s’accumule. Il n’est pas inhabituel que la compensation paraisse légère la première année et très différente à la troisième.
Donc mon ressenti n’est pas négatif. C’est plutôt que BABY n’essaie pas de copier le récit de rareté de Bitcoin, et je pense que c’est très bien. C’est un token fonctionnel pour un réseau fonctionnel, et son histoire d’offre dépend de la quantité d’activité réelle qui passe par lui.
Je vais simplement continuer à suivre les chiffres du burn à mesure que davantage de BSN se mettent en service, car c’est le chiffre qui raconte vraiment l’histoire ici.#baby $BABY @BabylonLabs_io

Je reviens sans cesse à un détail dans la tokenomics de Babylon qui est peu abordé : BABY dispose d’un mécanisme intégré qui s’auto-brûle, et il ne fonctionne que si le réseau grandit réellement.
Voici comment cela est censé fonctionner. Chaque Bitcoin Supercharged Network qui se branche sur Babylon Genesis redirige une partie de ses récompenses de staking vers une vente aux enchères (auction) en chaîne. Les participants enchérissent pour ces récompenses en utilisant BABY. Tout BABY qui remporte l’enchère est brûlé définitivement, hors de la circulation. Ainsi, plus il y a de réseaux qui apparaissent et qui veulent cette sécurité Bitcoin partagée, plus BABY est retiré de l’offre au fil du temps.
C’est une conception vraiment intéressante. Elle relie la rareté du token à un usage réel plutôt qu’à un calendrier fixe qu’une personne aurait inscrit dans un livre blanc. La plupart des brûlages de tokens que je rencontre sont purement cosmétiques. Celui-ci dépend de quelque chose qui se passe réellement dans le monde, ce qui le rend plus honnête, même si cela le rend aussi moins certain.
Les chiffres actuels mettent cette honnêteté en perspective. BABY a été lancé avec 10 milliards de tokens et un taux d’inflation annuel de 8 %, réparti à parts égales entre les stakers BTC et les stakers BABY. L’offre en circulation se situe aujourd’hui autour de 3,7 à 4 milliards. Le prochain déblocage prévu, le 10 août, libère environ 136 millions de tokens, soit un peu plus de 1 % de l’offre totale. Face à ce niveau d’émission relativement stable, le mécanisme de brûlage a un vrai travail à accomplir avant de compenser de manière significative la nouvelle offre qui arrive sur le marché.
Je ne pense pas que ce soit un reproche adressé à la conception. C’est simplement la réalité honnête de la situation pour l’instant. Un mécanisme déflationniste lié à l’adoption est un pari sur l’avenir, pas une garantie concernant le présent.
Deux points que j’aimerais continuer de surveiller. D’abord, le brûlage ne s’accélère que si l’adoption de BSN s’accélère avec lui, donc la trajectoire de l’offre du token dépend réellement de la réussite du développement commercial, et pas uniquement du fait que le protocole fonctionne correctement. Ensuite, BABY n’est pas un token ERC-20 : il est natif de la Babylon Chain, ce qui signifie que sa liquidité et ses intégrations dépendent de la maturation du propre écosystème de Babylon, plutôt que de se brancher sur une infrastructure qui existe déjà ailleurs.@BabylonLabs_io #baby $BABY