Ra44

Le score DeFiSafety 93% de TermMax est cité en permanence. Le détail est plus utile que le titre.
Six catégories. Code et Équipe 100%. Oracles 100%. Contrôles d’administration 97%. Sécurité 94%. Tests 89%. Documentation du code 70%.
La documentation est la catégorie la plus basse, de très loin, et c’est la seule catégorie que la plupart des utilisateurs touchent réellement. Vous ne lirez jamais la suite de tests. Vous lirez la documentation.
J’ai trouvé des éléments de preuve en la parcourant. La FAQ indique que les apporteurs de liquidité gagnent un rendement via un token LP appelé lp-FT. Je n’ai trouvé nulle part ailleurs dans la documentation la définition de lp-FT.

Tout cela ne rend pas le protocole dangereux. Soixante-dix passe encore leur seuil, et les catégories qui protègent réellement les fonds ont obtenu les meilleurs résultats — dans le bon ordre, donc.

Mais cela signifie que l’écart le plus important de la pile se situe entre ce que font les contrats et ce que le lecteur peut découvrir.

Le score de documentation devrait-il peser autant que le score de sécurité pour quelqu’un qui dépose de l’argent à hauteur de détail ?

#termmax @TermMax

#dusk $DUSK @Dusk
Auparavant, je pensais que les tokens ne faisaient que se déplacer. Ils sont créés une fois, puis changent de mains jusqu’à ce que quelqu’un arrête de les négocier. Le mouvement semblait être tout le vocabulaire.
En observant ce que font réellement les titres au cours de leur vie, j’ai réalisé que le vocabulaire manquait un mot.
Une obligation arrive à échéance. Une part de fonds est rachetée. L’instrument n’est pas transmis à un dernier propriétaire et ne reste pas là. Il est réglé, puis il cesse d’exister, parce que l’obligation qui le sous-tend a été exécutée.
Ainsi, un système conçu pour ces actifs ne peut pas seulement gérer le transfert. Il doit gérer le moment où un actif est, de manière légitime, détruit, et le faire d’une façon qui laisse une trace convaincante pour quiconque posera des questions plus tard.
Ce que j’ai trouvé remarquable, c’est à quel point cela apparaît rarement dans les discussions sur la tokenisation. Presque toutes les explications s’arrêtent à l’émission et à la négociation, comme si la partie intéressante consistait à faire entrer l’actif on-chain et à le conserver là.
Mais la fin d’un instrument est le moment où l’argent revient réellement au porteur, et se tromper à cette étape est bien plus conséquent qu’un transfert lent.
Je ne sais pas comment cela est géré, dans la pratique, lorsque le paiement est effectué hors chaîne et que le token est détruit on-chain, ce qui semble être le moment où les deux enregistrements peuvent le plus facilement diverger.
À partir de là, j’ai commencé à lire en termes de cycle de vie plutôt que de propriété. L’émission est là où l’histoire commence, et le rachat est la partie qui doit vraiment fonctionner.

#dusk $DUSK @Dusk
Lorsque j’ai lu pour la première fois qu’une institution agréée a l’intention d’apporter une grande quantité d’actifs sur une chaîne, j’ai pris ce chiffre pour un résultat. Quelque chose qui serait arrivé.
En y regardant de plus près, j’ai réalisé que je lisais une intention comme un aboutissement.
Un chiffre de ce type décrit les actifs qu’une institution prévoit de représenter on-chain. Il ne décrit pas la fréquence à laquelle ces actifs bougent, la quantité de valeur qui s’établit au travers de la chaîne sur un mois donné, ni la quantité d’activité que le réseau traite réellement grâce à eux.

Ce sont des mesures distinctes, et elles ne se comportent pas de la même façon. Un actif peut être émis on-chain puis rester complètement immobile pendant des années, ce qui est tout à fait normal pour de nombreux instruments. Rien n’a mal tourné. Cela signifie simplement que le chiffre mis en avant et l’activité du réseau répondent à des questions différentes.

Ce qui a retenu mon attention, c’est à quel point les deux finissent facilement par être confondus dans la discussion, y compris par moi. Un grand nombre apparaît, et cela donne l’impression d’une preuve d’adoption, alors qu’il s’agit en réalité d’une déclaration d’intention d’une seule institution.
Cela ne le rend pas pour autant dépourvu de sens. Une institution disposant d’une licence qui choisit de s’engager sur quelque chose est un signal réel, et un signal plus difficile à obtenir que la plupart des partenariats crypto.

Mais je voudrais voir la deuxième série de chiffres avant de tirer des conclusions, et je ne suis pas sûr qu’ils soient encore disponibles publiquement sous une forme sur laquelle je pourrais m’appuyer.
Peut-être que c’est l’habitude la plus utile. Lorsqu’un chiffre apparaît, il faut se demander s’il décrit quelque chose qui s’est produit, ou quelque chose que quelqu’un a l’intention de faire se produire.

#dusk $DUSK @Dusk
Alors, quelles règles s’appliquent réellement à une obligation tokenisée en Europe ?
Auparavant, je supposais que la réponse était simple. L’Europe a adopté une large réglementation sur les cryptoactifs ; donc, les cryptoactifs en Europe en font partie, et un actif tokenisé est une crypto. C’est à peu près ainsi que le sujet est généralement abordé, et je ne l’avais jamais remis en question.
Mais en lisant ce que Dusk cherche à construire, j’ai commencé à voir que cette hypothèse se brise à un endroit important.
Le cadre européen des crypto-actifs a été rédigé pour des éléments qui n’avaient pas encore de base juridique — les jetons d’utilité, les stablecoins et les entreprises qui fournissent des services autour d’eux. Il a comblé un vide.
Une obligation tokenisée ou une action tokenisée n’entre pas dans ce vide. C’est un instrument financier, et les instruments financiers étaient déjà réglementés bien avant l’existence de tout cela, dans le cadre d’un corpus de règles entièrement différent, conçu pour les marchés de valeurs mobilières. Le fait de les placer sur une blockchain ne les fait pas entrer dans le nouveau cadre. Cela reste là où c’était déjà.
Ce qui m’a particulièrement frappé, c’est à quel point cela explique la façon dont un projet comme Dusk est structuré. Si l’actif reste soumis à la réglementation sur les valeurs mobilières, alors la chaîne ne peut pas simplement être conforme par elle-même. Elle doit fonctionner en parallèle avec des plateformes autorisées et des intermédiaires autorisés qui détiennent déjà les permissions nécessaires à cette catégorie d’actifs.
Cela a redéfini pour moi la notion de partenariats. Ce ne sont pas des étapes marketing. Ce sont le mécanisme qui rend la chose juridiquement utilisable, tout simplement.
Je ne suis pas qualifié pour dire où se situe la répartition des responsabilités entre le protocole et les institutions qui l’utilisent, et je préférerais un spécialiste à une opinion assurée.
Mais à partir de là, j’ai cessé de lire les affirmations réglementaires comme un simple oui ou non. Les règles applicables dépendent de ce qu’est l’actif, et tokeniser quelque chose ne change pas sa nature.

#dusk $DUSK @Dusk Auparavant, je pensais qu’un transfert de blockchain n’avait que deux issues possibles : il réussit, ou il échoue. La réussite signifiait que la valeur avait bougé. L’échec signifiait qu’un problème s’était produit. Mais plus j’ai creusé la manière dont Dusk décrit les transferts d’actifs réglementés, plus j’ai réalisé que ce modèle est trop simpliste pour les marchés financiers.
Sur une chaîne ordinaire, une transaction rejetée ne vous apprend presque rien. Le gas s’est épuisé, une condition « require » s’est déclenchée, l’état a changé sous vos yeux. Il ne vous reste qu’à deviner ce qui s’est passé.
Pour un actif réglementé, cette ambiguïté n’est pas acceptable. La documentation de Dusk décrit des vérifications de transfert qui échouent avec des raisons explicites, et — le point que j’ai trouvé le plus intéressant — des vérifications qui peuvent être simulées avant même qu’une transaction ne soit soumise.
Ce qui m’a particulièrement marqué, c’est la signification de ce second point. Cela implique que l’éligibilité n’est pas quelque chose que l’on découvre en tentant un transfert et en observant son échec. On peut poser la question d’abord et obtenir une réponse, sans jamais toucher au registre.
Cela reflète la façon dont le processus côté « classique » fonctionne déjà. Un courtier n’envoie pas un ordre et n’espère pas que le système de conformité l’autorisera. La vérification intervient avant, et lorsqu’une transaction est refusée, quelqu’un peut expliquer précisément pourquoi : le contrepartiste n’était pas accrédité, la période de détention n’avait pas encore expiré, ou la juridiction était restreinte. « Rejeté » sans raison n’est pas une réponse exploitable dans un processus réglementé.
L’échec devient de l’information plutôt qu’un accident. Et un rejet qui comporte une raison est, à bien des égards, plus utile qu’une réussite qui n’en comporte aucune.
Je n’arrive toutefois pas encore à juger à quel point ces raisons sont détaillées dans la pratique, ni quelle part de tout cela est disponible pour une application aujourd’hui par rapport à ce qui est simplement présenté comme un objectif de conception.
À partir de là, j’ai commencé à voir la conception autrement. La conformité on‑chain ne consiste peut‑être pas à bloquer les mauvaises transactions. Elle pourrait plutôt viser à rendre l’issue prévisible avant que quiconque ne s’y engage.

#dusk $DUSK @Dusk Les développeurs Solidity ne veulent pas avoir à tout réapprendre une chaîne d’outils juste pour essayer une nouvelle blockchain.

Ainsi, rendre DuskEVM compatible avec OP Stack semblait être un choix judicieux au premier regard.

Les développeurs peuvent utiliser Solidity et des outils EVM familiers au lieu de repartir de zéro. Mais DuskEVM n’est que la couche d’exécution. Le règlement final et la disponibilité des données passent par DuskDS, la couche de base de Dusk dotée d’une finalité déterministe.

C’est une vraie tentative d’avoir le meilleur des deux mondes.

Conserver l’expérience développeur d’Ethereum, tout en ancrant les applications sur une infrastructure conçue autour du règlement financier.

Mais cette architecture soulève une seconde question.

À chaque fois que l’exécution et le règlement vivent sur des couches différentes, la connexion entre les deux devient essentielle. La valeur, l’état et les preuves doivent être transférés en toute sécurité entre DuskEVM et DuskDS.

Et historiquement, les ponts et les interfaces entre couches ont été parmi les infrastructures les plus fragiles de la cryptographie.

Dusk a elle-même appris une version de cette leçon en janvier, lorsque son pont séparé Dusk↔BSC a subi une compromission du portefeuille de signature. Ce n’était pas une exploitation de la voie de règlement de DuskEVM ou de DuskDS, donc il ne faut pas confondre les deux.

Mais le principe reste important : la chaîne de base peut demeurer sécurisée tandis que l’infrastructure reliant deux environnements devient le point le plus faible.

Dusk présente le pont DuskDS↔DuskEVM comme natif et sans confiance, sans dépositaire externe ni actifs enveloppés.

C’est encourageant, mais à mesure que davantage d’applications et de valeur migrent vers DuskEVM, les hypothèses de sécurité liées à ce chemin de règlement deviennent plus importantes, et non moins.

La compatibilité EVM abaisse la barrière pour les développeurs.

Elle donne aussi à Dusk une autre frontière qu’il faut défendre parfaitement.

La compatibilité EVM est-elle simplement un compromis nécessaire pour l’adoption — ou chaque chaîne axée sur la confidentialité qui ajoute une couche EVM élargit-elle aussi la surface d’attaque qu’elle doit protéger ?

$DUSK @Dusk

Deux phrases tirées des pages TGE de TermMax qui vont modifier ce que certaines personnes feront cette semaine.
Une. Si vous voyez une récompense Genesis sur la page de vérification — décrite comme une récompense spéciale pour les contributeurs précoces et de long terme — elle est déjà incluse dans l’allocation totale affichée en haut.
Non ajoutée. Incluse.
C’est l’opposé de ce que lit instinctivement une ligne de bonus. Et si vous êtes au-dessus du seuil d’acquisition en train de décider entre renoncer à 70 % et acquérir 85 %, gonfler votre propre chiffre de base change la réponse à laquelle vous aboutissez.
Deux. Il n’y a pas de limite de temps pour réclamer votre TMX immédiatement réclamable. La page Management le dit directement — revenez et réclamez quand vous voulez.
Celle-là est vraiment une bonne conception, et elle est plus rare qu’elle ne devrait l’être. Beaucoup de lancements ajoutent une date d’expiration aux tokens non réclamés, ce qui pousse tout le monde à agir le jour le plus mauvais possible pour les frais de gaz et pour le prix.
Mettez-les ensemble et vous obtenez la chose que la plupart des gens comprendront à l’envers cette semaine.
La décision est urgente. Le 23 août, 23:59 UTC. Si vous la manquez, le verrouillage le plus long est attribué pour vous.
La transaction n’est pas urgente. Pas du tout.
Donc l’urgence concerne le choix, pas la réclamation. Attendez-vous à ce que beaucoup de gens se mettent à courir pour réclamer le jour un, selon ce que fait le marché, tout en traitant la date limite comme quelque chose à gérer plus tard.
Exactement l’inverse.
Quelle date limite traitez-vous réellement comme la vraie ?

#termmax @TermMax

Petit détail, étonnamment captivant.
Les transactions de crépuscule peuvent contenir un mémo allant jusqu’à 512 octets. Il existe au total quatre types de transactions : un transfert simple, un appel de contrat, un déploiement de contrat et un transfert avec mémo.
Pourquoi un champ mémo existe-t-il, tout simplement, sur une chaîne conçue autour de la confidentialité ?
Les échanges. La note d’ingénierie qui l’a introduit explique que l’objectif est de permettre à un échange de cibler des comptes internes tout en utilisant une seule clé ou une seule adresse de réception. Quiconque a déposé sur un échange sur Cosmos ou XRP connaît exactement ce rituel : une adresse partagée, et une étiquette qui indique quel client vous êtes.
Ainsi, sur une chaîne dont le pitch complet est « tout ne devrait pas être public », la réalité opérationnelle de l’intégration des échanges a produit un champ où l’on écrit, à ciel ouvert, à quel compte appartient ce paiement.
Je ne pense pas que ce soit de l’hypocrisie. C’est le même principe que @Dusk défend encore : la divulgation devrait être un choix, appliqué là où cela sert, et pas une valeur par défaut appliquée partout. Un mémo de dépôt est l’endroit où être lisible est exactement le but.
Mais 512 octets, c’est beaucoup de place, et les champs à usage général ne restent jamais bien sagement dans leur voie. Les mémos sur d’autres chaînes sont devenus des références de facture, des numéros de commande, des messages, et parfois même des choses que personne n’avait prévues. Quoi qu’il finisse par y être écrit, cela se retrouve gravé dans un registre public pour toujours, par des utilisateurs qui n’y penseront pas.
La question intéressante n’est pas le champ. C’est ce que les gens y mettent une fois que le volume arrive, et s’il y a quelqu’un qui surveille.
Si vous avez intégré une chaîne avec des dépôts basés sur des mémos — quelle est la chose la plus étrange que vous ayez vue quelqu’un écrire dans l’un d’eux ?

#dusk $DUSK @Dusk

Native DUSK a 9 décimales. Un DUSK équivaut à 1 000 000 000 LUX.
ERC20 et BEP20 $DUSK ont 18.
J’ai relu ces deux lignes de la page de tokenomics plus longtemps que je ne l’avais prévu, parce que ce sont le genre de détails qui ne déclenchent jamais une discussion, mais qui finissent par créer un ticket de support.
Deux conséquences que je ne cesse de remettre en question.
Un : LUX est la résolution de l’ensemble du marché des frais. Le prix du gas est fixé en LUX par unité de gas, et les frais correspondent au gas utilisé multiplié par le prix du gas. Neuf décimales, c’est le plus fin de tout ce que @Dusk peut jamais atteindre en termes de prix. Pour une chaîne visant le règlement de valeurs mobilières — où les calculs de coupons, les découpages de dividendes et les participations fractionnaires sont monnaie courante — ce plafond est un paramètre de conception réel, pas un détail sans importance. Neuf décimales suffisent pour un token. Mais la question est différente : est-ce suffisant pour chaque instrument qui finira par être réglé par rapport à lui.
Deux : passer de 18 à 9 n’est pas un déplacement sans perte. Tout ce qui se situe sous la neuvième décimale sur Ethereum ou BSC n’a pas d’endroit où atterrir sur le mainnet. Quelqu’un doit décider si cette poussière est arrondie, tronquée ou bloquée — et cette règle compte le plus pour les personnes exactes pour lesquelles le guide de migration est rédigé.
J’ai lu le guide de migration et le guide de bridge BEP20, et je n’y ai pas trouvé cette règle énoncée clairement. Elle peut être gérée correctement et simplement sans être documentée. Elle peut aussi être documentée quelque part où je n’ai pas regardé.
C’est pourquoi je préfère demander plutôt que supposer.
Si vous avez migré ERC20 ou BEP20 DUSK vers le mainnet — votre solde est-il tombé exactement, ou bien les derniers chiffres sont-ils allés quelque part ?

#dusk @Dusk $BTC

Un clic, trois choses distinctes

L’effet de levier en un clic ressemble à une seule action. La documentation décrit trois étapes.
Vous fournissez des jetons de dette. Le protocole prend un prêt flash pour le reste. Le montant combiné sert ensuite à acheter l’actif en collatéral, et cet achat est verrouillé dans un jeton Gearing.
L’étape deux est celle qui mérite qu’on s’y attarde. C’est un achat sur le marché. Il passe par un adaptateur de swap — le périmètre audité mentionne les adaptateurs Kyberswap et Odos — et les adaptateurs autorisés sont contrôlés par un rôle d’administrateur.

Ainsi, votre taux est fixe à l’entrée. Votre prix d’entrée ne l’est pas. Un bref instant de liquidité limitée sur le DEX du collatéral se traduit par une exécution moins favorable sur la position que vous venez d’ouvrir, et la certitude sur le taux ne corrige rien.
C’est tout de même clairement mieux que de boucler manuellement sur quatre protocoles. Moins de transactions, moins de gaz, un point de défaillance atomique au lieu de cinq.
Mais « taux fixe » décrit le financement, pas le remplissage.
Vérifiez-vous la profondeur du DEX du collatéral avant d’ouvrir une position avec levier, ou seulement le TRP ?

#termmax @TermMax #DEX

@Dusk
J'ai additionné la répartition du bloc de Dusk en supposant qu'elle tomberait à 100 %. Générateur de blocs 70 %, fonds de développement 10 %, comité de validation 5 %, comité de ratification 5 %. Ça fait 90 %. Les 10 % manquants sont la part que j'avais supposée être fixée. Ce n'est pas le cas.
Cette dernière tranche revient aussi au générateur de blocs — mais seulement jusqu'à 10 %, selon les crédits inclus dans le certificat du bloc. Toute portion non distribuée est brûlée.
Ainsi, l'émission sur Dusk dépend partiellement de la performance. Un bloc dont le certificat porte l'ensemble complet des votes des comités paie toute la récompense. Un bloc qui rassemble moins de crédits paie moins, et le manque n'est ni reporté ni redirigé — il est détruit. Chaque bloc est un petit référendum sur la participation aux comités, réglé dans l'offre.
C'est pourquoi le titre de l'émission et le chiffre destiné aux stakers sont deux questions différentes. Dusk émet 500 000 000 DUSK sur 36 ans avec une décroissance géométrique, r = 0,5, division par deux toutes les quatre années. Période une : 19,8574 DUSK par bloc sur 12 614 400 blocs, 250,48 M DUSK au total. C'est l'émission. Mais 10 % de chaque récompense de bloc est acheminé vers le fonds de développement, et une fraction inconnue des 10 % conditionnels est brûlée. "Combien la chaîne émet par bloc" et "ce qui parvient à un staker" se résolvent différemment — et le second dépend de la qualité avec laquelle le réseau a attesté ce bloc précis.
Je pense que c'est plus honnête qu'une promesse d'APY fixe. Cela valorise la participation réelle au consensus plutôt que d'annoncer un chiffre et d'espérer que le réseau le réalise. Mais honnêteté et modélisabilité ne sont pas la même chose. Dimensionner une activité de validateur nécessite maintenant une hypothèse sur l'exhaustivité moyenne des certificats — une variable qui n'a pas de page marketing.
Dusk vise les validateurs institutionnels pour des marchés réglementés. Une récompense conditionnelle, partiellement brûlée, est-elle la bonne incitation pour ce public, ou les institutions ont-elles besoin de prévisibilité plus que d'élégance ?

#dusk $DUSK

J’ai continué à défiler au-delà de cette ligne jusqu’à ce qu’elle cesse de ressembler à de la plomberie.
FT est la moitié dont tout le monde parle. Une créance à coupon zéro, achetée au-dessous du pair, remboursée au pair. Une obligation.
XT, c’est ce qu’il reste de la même unité de dette une fois que cette créance est séparée. La jambe d’intérêt. Déposez un jeton de dette : les deux moitiés sont émises, et XT se vide vers rien à mesure que l’échéance approche.
Voici ce qui a fait “tilt”. L’identité est maintenue à chaque instant, pas seulement à la fin. Un FT et un XT brûlent à nouveau pour redevenir le jeton de dette, au pair. Pas d’enchères, pas d’oracle. Le remboursement reste clair parce que les deux moitiés finissent toujours par faire un.
Du coup, ils se retrouvent entre des mains opposées. Dans le flux de prêt, la jambe XT est échangée dans la même transaction qui la frappe, et le prêteur repart en ne gardant que du FT. Le “leverager” acquiert XT, parce que détenir la moitié qui se déprécie face à la garantie est la manière dont la boucle se construit.
Quelqu’un doit détenir la jambe qui expire sans valeur à une date connue. C’est le leverager, pas le prêteur.
Encore un doute : la documentation appelle XT une obligation d’intérêt sur une page et un indicateur d’effet de levier sur une autre. Je ne sais pas sur quoi les traders se basent pour la valorisation.
Si FT est l’obligation, qui évalue vraiment XT, et contre quoi ?

#termmax @TermMax

Le pré-dépôt (pre-mine) @TermMax possède un détail à noter : 40M TMX (4% de l’offre de 1B), réservés aux incitations destinées aux early users, avec aucun vesting — échangeables 1:1 peu de temps après le TGE, selon les propres documents de TermMax.

Le contexte compte ici : une couche bonus distincte de TMX, proposée par le partenaire de vault tiers Neutral Trade (et non TermMax), *utilise* un vesting linéaire sur 6 mois, sans cliff. Donc, le vesting était clairement une option que le TMX supporte — mais cet arbitrage de structuration relevait de Neutral Trade, pas de TermMax. Je ne lirais pas la conception sans-vesting du pool principal comme un signal délibéré de #termmax .

Deux interprétations sont également plausibles : l’équipe ne s’inquiète pas de la pression de vente concentrée au début, ou bien un pool sans vesting est simplement plus simple à administrer. Pas assez d’éléments pour trancher.

Sécurité : les audits Spearbit/Cantina sont cités via les documents de Neutral Trade, pas via un rapport publié par TermMax — probablement vrai, mais recoupé de seconde main. Le score de DeFiSafety à 93%, listé sur le site même de TermMax, est solide.

Financement : ~6,8M au total — 2,55M d’angel (2022) + seed avec une valorisation à 38M, mené par Cumberland (2023). Le montant du seed est contesté : 4,25M (CryptoRank) vs 4,45M ailleurs, lié à l’entité parente « Term Structure ». Petit écart non résolu.

Plus grand point d’inconnue : aucune échéance publique de vesting/cliff pour les 96% restants (équipe, investisseurs, trésorerie) — ce point compte davantage sur le long terme que les 40M du pre-mine.

La vraie question : quelle quantité du pool de 40M s’accumule dès le TGE. C’est cela qui détermine si ce n’est qu’un petit bruit de liquidité ou un vrai catalyseur de marché.

#dusk $DUSK @Dusk Le consensus de Dusk, l’Attestation succincte (SA, Succinct Attestation), est un protocole de preuve d’enjeu (proof-of-stake) sans permission, fondé sur des comités. Les pourvoyeurs éligibles sont sélectionnés par une sélection déterministe pondérée par le capital (stake-weighted sortition) afin de constituer de petits comités par ronde ; ces comités proposent, valident et ratifient des blocs en utilisant des signatures agrégées plutôt que d’exiger que l’ensemble des validateurs intervienne sur chaque bloc. La documentation de Dusk décrit des transactions progressant à travers quatre états : Accepté (reçu et valide), Confirmé (inclus dans un bloc sur lequel des blocs ultérieurs s’appuient), Stable (enterré assez profondément pour être très improbable qu’il soit renversé) et Final (garanti irréversible de manière déterministe et cryptographique). Cela s’oppose explicitement au consensus de type Nakamoto, où les blocs ne sont jamais absolument finaux et sont considérés comme « probablement sûrs » après qu’un nombre suffisant de confirmations s’accumule.

La plupart des chaînes donnent aux utilisateurs un seul signal — le nombre de confirmations — et leur laissent le soin de décider ce qui est « suffisant ». Le modèle en quatre étapes de Dusk rend explicite ce qui est généralement laissé implicite : différents acteurs ont besoin de seuils de certitude différents à des moments différents. Un transfert de détail pourrait raisonnablement considérer « Confirmé » comme suffisant ; une compensation de titres a presque certainement besoin de « Final ». Par rapport aux systèmes purement probabilistes, la SA échange une partie de la surface de décentralisation (seul un comité atteste par bloc) contre un point explicite et borné où la finalité cesse d’être probabiliste et devient absolue.

Rendre visibles quatre états de finalité est plus honnête quant à la manière dont la compensation fonctionne réellement, mais cela reporte aussi une décision sur la couche utilisateur ou application — quel est l’état « suffisant » pour cette transaction. Le fait de mettre en avant la structure réelle de la finalité aide-t-il les utilisateurs à prendre de meilleures décisions calibrées, ou bien la granularité ajoutée est-elle de toute façon largement abstraite par les portefeuilles et les applications ?

#dusk $DUSK @Dusk

Je n’avais pas beaucoup réfléchi à la couche réseau jusqu’au moment où j’ai remarqué que Dusk ne déplace pas les blocs et les votes comme le font la plupart des chaînes. Au lieu d’inonder chaque message à chaque pair, il utilise quelque chose appelé Kadcast, construit sur un routage structuré de type Kademlia.

Pris isolément, cela ressemble à un détail d’infrastructure auquel personne en dehors de l’équipe cœur ne pense. Mais cela devient plus important une fois qu’on le met en regard de la façon dont l’Attestation Succincte fonctionne réellement. Le consensus basé sur des comités dépend d’un petit groupe de pourvoyeurs qui échangent des votes assez rapidement pour finaliser un bloc en quelques secondes. Si la couche réseau située en dessous est lente ou gaspille de la bande passante en retransmettant le même message à tout le monde, cette fenêtre de vote serrée devient plus difficile à atteindre à mesure que l’ensemble des validateurs grandit ou se répartit géographiquement.

Kadcast achemine les messages via des chemins déterministes fondés sur la distance dans le réseau, plutôt que sur une inondation aléatoire, et le résultat documenté est une baisse significative de la bande passante par message. Pour une chaîne qui s’appuie sur des comités échangeant des votes à chaque tour, ce n’est pas un simple gain esthétique — c’est beaucoup plus proche d’une condition préalable pour que les garanties de finalité tiennent réellement à grande échelle, et pas seulement dans un petit testnet.

Ce qui me manque, en revanche, c’est une image claire de ses performances dans des conditions plus difficiles : un ensemble de validateurs répartis entre plusieurs continents, une qualité de connexion inégale, ou encore un comportement réellement adversarial au niveau réseau plutôt qu’une simple inefficacité. Les protocoles de routage structuré comportent leurs propres compromis lorsque les nœuds se comportent mal ou décrochent de façon imprévisible. Savoir si l’efficacité de Kadcast tient bon une fois le réseau plus vaste et plus chaotique qu’aujourd’hui, c’est probablement quelque chose qu’on ne saura vraiment qu’après l’avoir testé à grande échelle dans la réalité.

Décomposons ça correctement, parce que la notion de « tokenized asset » est utilisée de façon assez lâche.

L’ancienne approche, c’est la tokenisation via un wrapper (enveloppe). Vous prenez un actif. Vous l’enveloppez dans un token. Ce token représente alors la propriété. Mais tout le reste — négociation, compensation, conservation, règlement — reste exactement où il était, dans des systèmes séparés, puis rapprochés après coup. Le token est une représentation. Ce n’est pas le registre opérationnel réel de l’actif.

L’alternative, c’est l’émission native. Au lieu d’envelopper un processus existant, l’ensemble du cycle de vie vit directement on-chain dès le départ. Émission, propriété, transferts, règlement, gestion (servicing), reporting — un seul enregistrement continu, pas cinq morceaux disjoints qu’il faudrait recoller manuellement.

Pourquoi cette distinction compte-t-elle concrètement ?

Imaginez ce qui se passe lorsqu’une obligation change de mains selon chacun des modèles. Avec l’enveloppe, le token bouge, mais quelque part hors chaîne, un dépositaire (custodian), une chambre de compensation (clearinghouse) et un registraire doivent tous mettre à jour indépendamment leurs propres registres pour qu’ils correspondent. C’est à cette étape de rapprochement (reconciliation) que se logent généralement les coûts, les délais et les litiges.

Avec l’émission native, il n’y a qu’un seul enregistrement. Quand la propriété change, tous les faits en aval — règlement, reporting, gestion — s’y reflètent immédiatement, parce qu’il n’y a rien séparé qui resterait à rapprocher.

C’est l’avantage théorique. Voilà la limite honnête : les institutions ne changent pas de modèle parce que l’un serait, sur le plan architectural, plus « propre ». Elles changent lorsque le coût de rester sur l’ancien modèle dépasse le coût de la transition. Les infrastructures héritées (legacy) s’accrochent pour des raisons qui n’ont rien à voir avec le fait que l’une des conceptions soit meilleure, sur papier.

Donc, la façon utile de réfléchir à ce sujet n’est pas de savoir quel modèle est le plus intelligent. C’est de comprendre quel modèle est réellement adopté à grande échelle — et c’est une question beaucoup plus difficile à résoudre à partir d’un livre blanc.

#dusk $DUSK @Dusk

Activité réelle
Au lieu de relire le pitch deck, j’ai passé une soirée à ne faire que regarder les chiffres. C’est là que l’écart s’est révélé.
Partout, on présente Dusk au crépuscule comme un rail RWA d’un niveau institutionnel — avec des partenariats et des intégrations associés à des noms bien connus. Mais ce qui bouge réellement on-chain en ce moment ressemble à quelque chose de petit : une paire Binance DUSK/USDT qui ne représente qu’une part modeste du volume total du marché, le reste étant dispersé en fines miettes sur des places plus petites. Pas du tout l’endroit où un récit « institutionnel » est censé prendre racine.
Le staking présente la même forme à plus petite échelle. Le Hyperstaking est conçu pour être accessible — un seuil d’entrée bas, permissionless, une fenêtre de maturité relativement courte. Pendant ce temps, les grandes initiatives de tokenisation sont encore décrites surtout au futur, comme « en cours de déploiement ».
Il y a aussi un angle sécurité qui mérite qu’on s’y attarde. Les évaluations de sécurité indépendantes montrent actuellement une couverture d’audit assez limitée, une notation d’assurance modeste et une couverture en bug bounty tout aussi limitée. Ce n’est pas inhabituel — de nombreux L1 lancent avant que leur pile de sécurité complète ne soit mûre — mais c’est un manque notable pour une chaîne qui courtise précisément des banques dépositaires et des titres tokenisés.
Rien de tout cela ne se lit comme un signal inquiétant, plutôt comme quelque chose d’« encore au début ». L’infrastructure prend du temps à construire. Ce qui vaut vraiment la peine d’être surveillé, c’est qui finit par utiliser la couche de règlement en premier — les stakers déjà actifs aujourd’hui, ou les institutions qui attendent encore la paperasse et les rails de conformité pour finaliser.
L’écart entre le récit institutionnel et l’activité on-chain actuelle n’est-il qu’un décalage normal lié à une phase initiale, ou cela dit-il quelque chose sur le niveau réel d’adoption institutionnelle ?

#dusk $DUSK @Dusk

#dusk $DUSK Voici quelque chose qui est souvent passé sous silence dans la plupart des explications sur DUSK : ce n’est pas une chaîne avec un seul modèle de confidentialité greffé. C’est une chaîne qui exécute simultanément deux modèles de transaction distincts, car un paiement et une sécurité ne sont pas le même type d’objet et ne peuvent pas échouer de la même manière.
Phoenix est le modèle de type UTxO pour les transferts du quotidien rendus obscurs — les soldes et les contreparties sont cachés, les notes sont suivies dans un arbre de Merkle, et des nullifiants empêchent les doubles dépenses sans révéler quelle note a été dépensée. Il est conçu pour le débit et la confidentialité lors des transferts de valeur ordinaires.
Zedger est différent, volontairement. Il est modélisé spécifiquement pour les titres tokenisés, où l’enjeu n’est pas seulement de masquer un solde — il s’agit de prouver correctement les événements du cycle de vie (émission, restrictions de transfert, opérations sur titres, rachat) dans un cadre réglementaire, sans divulguer la table des capitalisations au public de la chaîne. Un token de sécurité a des obligations que Phoenix n’était jamais conçu à porter : des restrictions de transfert liées au statut de l’investisseur, la capacité pour un émetteur de geler ou de récupérer dans des conditions juridiques spécifiques, des exigences d’audit qui subsistent même lorsque les soldes restent scellés.
Exécuter les deux sur une même couche de règlement est le pari d’ingénierie. Dusk ne choisit pas entre « chaîne de paiements privés » et « chaîne de titres conformes » — elle soutient qu’il faut disposer des deux primitives dans le même environnement d’exécution, parce qu’un marché réglementé touche les deux types de transactions le même jour de bourse. Le contrat de transfert gère ces deux flux via le même modèle d’intégrité basé sur l’arbre de Merkle : une architecture plus propre que de faire du pont entre deux chaînes avec deux garanties de confidentialité différentes.
La question ouverte est de savoir si cette complexité à double modèle devient un fardeau de maintenance au fur et à mesure que chaque spécification évolue indépendamment, ou si elle est réellement plus robuste qu’une couche de confidentialité « universelle ».
Quelqu’un connaît-il un autre L1 déployant deux modèles de transaction de production volontairement séparés par classe d’actifs, plutôt qu’une primitive générique de confidentialité étirée sur tout?
@Dusk $NVDAB

L’équipe de Babylon a présenté BABE — son nouveau système de vérification de preuve — comme la clé qui rend les coffres Bitcoin Trustless pratiques : environ 1000× de stockage en moins, 1000× de configuration plus rapide, passant d’heures à des secondes. À lire ça seul, on dirait une amélioration déjà livrée.
Ensuite, j’ai consulté leur propre plan de déploiement depuis le même appel. BABE n’est pas encore une fonctionnalité live sur le mainnet — elle avance par étapes : d’abord un testnet alpha (renforcement du côté Bitcoin, ZK, vérification), puis un testnet bêta (API et documentation prêtes pour le mainnet), puis une cible mainnet par la suite. Les chiffres de compression proviennent de résultats de laboratoire réels. Qu’ils tiennent à l’échelle de production, dans des conditions réseau réelles, avec de vrais tests contre des adversaires, est une autre affirmation distincte et encore ouverte.
Pas un signal d’alarme — c’est ainsi que la cryptographie sérieuse se déploie généralement, par étapes, pas tout d’un coup. Mais « 1000× plus petit » comme accroche et « encore en alpha » comme statut sont vrais simultanément, et seul l’un des deux ressort dans le fil.
Où est un bon endroit pour suivre la progression réelle de BABE, étape par étape, plutôt que de se fier au post d’annonce ?
@BabylonLabs_io #baby $BABY

9 all dn #BibanceTurns9