Anl_

#dusk $DUSK @Dusk
Alors qui décide si vous pouvez détenir un actif tokenisé, et comment cela est-il vérifié sans tout savoir de vous ?
Je n’avais jamais réfléchi à l’une ou l’autre des deux moitiés. Je pensais que l’actif se crée, que les gens l’achètent, et que la paperasse se fait quelque part, à l’abri des regards.
La séquence se déroule en sens inverse. Avant toute transaction, l’émetteur définit l’actif, les conditions d’éligibilité et les règles qui régissent sa vie. Ce n’est qu’ensuite que quelque chose bouge. L’émission, c’est essentiellement un acte d’écriture de règles, et le jeton n’est qu’un sous-produit.
Cela crée un problème que je n’avais pas relié à tout ça. Si les règles dépendent de faits concernant une personne, les vérifier normalement signifie stocker ces faits. Et en Europe, les informations personnelles s’accompagnent de droits, y compris, dans certains cas, le droit d’être effacé. Une base de données conçue pour que rien ne puisse jamais être effacé cohabite mal avec cela.
La seule solution vraiment propre consiste à ne jamais conserver les données personnelles dans le registre permanent et à y mettre plutôt une preuve. Si l’information n’a jamais été écrite, la question de l’effacement se répond presque d’elle-même.
Ce qui amène au troisième élément, celui qui détermine si tout cela est réaliste. Les preuves ne sont utiles que si leur vérification reste abordable. J’avais supposé que la cryptographie sérieuse et les smart contracts ne faisaient pas bon ménage — c’est possible, mais trop coûteux pour un usage ordinaire. Dusk traite la vérification des preuves comme une capacité native plutôt que comme quelque chose que chaque contrat doit reconstruire.
Ce que je ne peux toujours pas évaluer, c’est la manière dont cela tient quand une application a réellement besoin de connaître quelque chose sur une personne pour la servir, ce qui décrit la plupart de la finance réglementée.
À partir de là, je lis les revendications en matière de confidentialité différemment. La version la plus forte n’est pas un chiffrement plus puissant. C’est organiser les choses de façon à ce que les données sensibles n’aient jamais été enregistrées du tout.

#dusk $DUSK @Dusk
Alors, quand vous achetez quelque chose sur une blockchain, à qui l’achetez-vous ?
Dans la crypto “classique”, la réponse est : à personne en particulier, et cela est considéré comme une fonctionnalité. Vous interagissez avec un contrat, la transaction s’exécute, et l’identité de l’autre partie n’a pas d’importance.
Sur les marchés réglementés, cette réponse est inacceptable, et je n’ai pas pris la mesure de la profondeur du problème que récemment.
Les institutions doivent savoir avec qui elles traitent. Pas par curiosité — parce qu’elles ont des obligations concernant les personnes avec lesquelles elles sont autorisées à transiger, et ces obligations ne disparaissent pas parce que la transaction a eu lieu sur une blockchain. Une contrepartie anonyme n’est pas, pour elles, une simple optimisation. C’est un manquement à la conformité.
Ce qui a attiré mon attention, c’est à quel point cela modifie ce qu’une chaîne financière doit fournir. Elle ne peut pas seulement prouver qu’une transaction est valide. Elle doit permettre aux participants d’établir que l’autre partie est bien quelqu’un avec qui ils sont autorisés à commercer, sans exposer cette personne à tous les autres qui observent la chaîne.
C’est un problème plus difficile que la seule confidentialité, et plus difficile que la seule transparence. Il se situe maladroitement entre les deux.
Je travaille encore à déterminer dans quelle mesure c’est réellement résoluble avec la cryptographie, et dans quelle mesure cela ne fait que déplacer la question vers la personne ou l’entité qui a délivré les identifiants.
À partir de là, j’ai cessé de considérer l’anonymat comme le “bien” par défaut dans la finance. Parfois, la capacité de savoir qui se trouve de l’autre côté est précisément ce qui rend le marché possible.

#dusk $DUSK @Dusk
Alors, quand une transaction est « confirmée », qu’est-ce qui s’est réellement passé ?
Par le passé, j’avais tendance à traiter la confirmation et la finalité comme le même mot. Je voyais une transaction passer, j’attendais un peu, puis je considérais l’affaire close. Si quelqu’un m’avait demandé si cela pouvait encore être inversé, j’aurais répondu non, sans vraiment réfléchir au pourquoi.
Mais plus j’ai creusé la façon dont Dusk décrit le règlement, plus j’ai réalisé que je mélangeais deux idées différentes.
Sur la plupart des chaînes, une transaction devient plus sûre à mesure que l’on attend. Rien ne la déclare permanente. On arrive simplement à un point où l’inversion coûterait si cher que personne, raisonnablement, ne le ferait. C’est une probabilité, pas une promesse.
Dusk l’aborde différemment. Son consensus est conçu pour qu’un bloc soit réglé par les règles du protocole lui-même, plutôt que de devenir progressivement plus sûr avec le temps.
Ce que j’ai trouvé particulièrement remarquable, c’est pourquoi cette distinction compte beaucoup plus en finance que dans un usage courant de la crypto. Si j’envoie de l’argent à quelqu’un et qu’il faut encore une minute pour se sentir en sécurité, rien d’important ne se produit. Mais un système de règlement ne peut pas fonctionner sur la base de « très probablement permanent ». Quelqu’un doit être redevable du moment où un transfert devient irréversible, et ce moment doit être un fait plutôt qu’une estimation.
Cela explique aussi quelque chose qui m’avait intrigué plus tôt. Construire une couche de règlement à partir de zéro représente un travail immense, alors que des options plus rapides existent déjà. Cela n’a de sens que si la garantie elle-même est le produit.
Je ne suis pas encore en mesure de dire comment cela se comporte lorsque le réseau subit une pression réelle, plutôt que des conditions normales. C’est là que les conceptions révèlent généralement ce qu’elles promettent vraiment.
Mais à partir de là, j’ai cessé de lire « confirmée » comme une idée unique. Il y a le moment où une transaction se produit, et il y a le moment où elle cesse d’être réversible, et ces deux instants ne sont pas toujours la même chose.

#dusk $DUSK @Dusk Auparavant, je pensais qu’une blockchain devait choisir un camp. Soit elle est sans permission (permissionless), où n’importe qui peut effectuer des transactions et personne ne vous garde à l’écart, soit elle est avec permission (permissioned), où un consortium décide qui peut participer. Publique ou privée. L’une ou l’autre.
Mais plus je lis sur Dusk, moins cette séparation semblait décrire ce qui est réellement en train d’être construit.
La couche de base est ouverte. N’importe qui peut exécuter un nœud, n’importe qui peut miser, le code est public, et aucun comité n’approuve votre participation. En revanche, les actifs destinés à vivre sur cette couche sont l’inverse : éligibilité restreinte, transferts contrôlés, et uniquement détenus par des parties vérifiées.
Ce qui m’a particulièrement marqué, c’est que ces éléments ne sont pas en conflit, car ils opèrent à des couches différentes. Le réseau n’a pas besoin de savoir qui vous êtes pour inclure votre transaction. L’actif, lui, doit savoir qui vous êtes avant de vous autoriser à le détenir. Ouverture au niveau du règlement, restriction au niveau de l’instrument.
Les marchés traditionnels fonctionnent déjà ainsi, et nous le remarquons rarement. L’infrastructure Internet transporte une transaction sur des actions sans se faire d’opinion sur le fait que vous ayez le droit de posséder ces actions. Le transport est neutre. L’instrument ne l’est pas.
Ce qui rend cette approche difficile à reproduire en chaîne, c’est que la plupart des gens évaluent une chaîne comme un objet unique. Alors ils se demandent si Dusk est sans permission, obtiennent une réponse partielle, puis tirent une conclusion erronée dans un sens comme dans l’autre.
Je ne suis toujours pas sûr que cela tienne lorsque qu’un actif restreint se retrouve quelque part où la restriction ne peut pas le suivre — c’est, semble-t-il, le cas vraiment difficile.
À partir de là, j’ai cessé de demander si la chaîne est ouverte ou fermée. La question la plus utile est de savoir sur quelle couche vit l’ouverture, et si les restrictions de la couche au-dessus sont appliquées par le code ou seulement par accord.

#dusk $DUSK @Dusk Quand vous entendez « privacy coin » (monnaie de confidentialité), pensez-vous à Monero ou à Zcash ?

Je le pensais. Mais la comparaison devient plus intéressante dès lors qu’on se demande ce que « la confidentialité » est censée accomplir.

Monero adopte une position radicale : la confidentialité est obligatoire. L’expéditeur, le destinataire et le montant sont masqués par défaut. Zcash est plus flexible, avec des transactions protégées (shielded) et des clés de consultation qui peuvent révéler certaines informations de manière sélective.

Dusk pousse cette seconde philosophie directement dans la finance réglementée.

L’idée est une confidentialité avec divulgation sélective : votre activité financière n’a pas besoin d’être publique, mais une partie autorisée — un auditeur, un superviseur ou une institution — peut recevoir la preuve précise dont elle a besoin, sans voir le reste.

Je comprends pourquoi les institutions préféreraient cela.

Les banques, les émetteurs et les marchés réglementés ont besoin de confidentialité, mais ils ne peuvent pas non plus fonctionner dans un système où l’on ne peut pas prouver que la conformité est possible.

La controverse est évidente aussi.

Pour un défenseur de la confidentialité natif des crypto, « visibilité autorisée » peut sembler moins une confidentialité qu’un accès dérobé contrôlé. Si quelqu’un peut se voir accorder l’accès, le débat porte alors sur qui contrôle cet accès et selon quelles règles.

Il y a aussi l’adoption.

La pression réglementaire sur les actifs axés sur l’anonymat n’est plus théorique. Kraken a retiré Monero pour les clients de l’EEE, en citant explicitement des changements réglementaires.

Cela rend le compromis de Dusk plus facilement viable sur le plan commercial : masquer l’information au public tout en permettant une vérification réglementée.

Mais « plus adoptable » ne veut pas automatiquement dire « meilleure confidentialité ».

Peut-être que l’anonymat pur protège mieux le principe, mais peine à être accessible aux institutions. Peut-être que la divulgation sélective sacrifie la pureté idéologique pour rendre la confidentialité utilisable à l’intérieur du système financier.

Et cela laisse la question inconfortable :

Si la confidentialité peut encore être démontrée à « quelqu’un », est-ce vraiment de la confidentialité — ou simplement une visibilité réglementée ?

La plupart des chaînes en preuve d’enjeu font une chose après qu’un bloc est proposé : un comité vote, et si suffisamment de votes arrivent, le bloc est comptabilisé.
@Dusk le fait deux fois, et le second tour, c’est celui dont personne n’explique la raison.
Succinct Attestation exécute chaque tour en trois étapes. Un proposeur propose un bloc candidat. Un comité sélectionné aléatoirement le valide. Ensuite, un second comité ratifie — et ce qu’il confirme n’est pas le bloc. Il confirme le résultat de la validation.
Il m’a fallu un moment pour bien voir cette distinction.
La validation répond à « ce bloc est-il valide ? ». La ratification répond à « est-ce que le réseau a effectivement accepté qu’il a été validé ? ». Ce sont des questions différentes, et c’est la seconde qui permet la finalité déterministe. Sans elle, on a l’avis d’un comité, propagé sur un réseau, qui arrive à différents nœuds à des moments différents. Avec elle, on a un enregistrement attesté indiquant que l’accord lui-même a eu lieu.
C’est la différence entre « ce bloc est très probablement final » et « ce bloc est final ». Pour une chaîne qui vise le règlement de titres, cet écart n’est pas qu’une question philosophique. C’est la différence entre une garantie de règlement et une estimation du règlement.
Le coût est réel aussi. Deux comités signifient deux tours de signatures, deux occasions pour que la participation échoue, et des partages de récompense qui reflètent cela — la validation et la ratification prennent chacune une part de la récompense du bloc, distincte du générateur du bloc.
La question de savoir si ce tour supplémentaire vaut la latence et le surcoût de coordination est exactement le genre de chose qu’un audit ne peut pas vous dire. La revue d’Oak Security a jugé le protocole bien conçu. « Bien conçu » et « adapté à une charge réelle » sont des affirmations différentes.
Question sincère aux opérateurs de nœuds ici : quelqu’un a-t-il mesuré à quelle fréquence la ratification est l’étape qui se bloque, plutôt que la validation ?

#dusk $DUSK #block

@TermMax La page des options Alpha indique que votre perte maximale correspond à la prime. La page des frais ajoute trois lignes supplémentaires à cela.
Ouvrir ou fermer une position Long ou Short coûte 7 % de la prime payée.
Le profit/prise de profits est facturé sur le notionnel, et non sur la prime — 1,9 % au jour 1, décroissant linéairement jusqu’à l’échéance. L’exemple des documents : un contrat de 16 jours clôturé au jour 10 avec un notionnel de 10 000 USDT rapporte 47,5 USDT.

Ensuite, le financement. Vous payez des intérêts sur le notionnel pour chaque seconde pendant laquelle vous détenez la position. Leur exemple utilise un taux annualisé de 100 % et produit environ 1,37 USDT par jour sur 100 USDT de notionnel. Environ 10 % de ces intérêts vont à la plateforme, le reste aux déposants du Dual Investment.

Rien de tout cela n’est caché, et les frais de transaction sont annulés pendant le programme d’accélération (boosting).
Mais « le coût maximal est la prime » et « les intérêts s’accumulent par seconde sur le notionnel » sont deux phrases différentes décrivant la même opération.
Quand vous évaluez l’une de ces valeurs, évaluez-vous la prime seule, ou la prime plus le carry ?

#termmax @TermMax

#dusk $DUSK

Tout le monde débat du consensus. Presque personne ne regarde une couche en dessous.
@Dusk n’utilise pas de ragots aléatoires pour faire transiter des blocs entre nœuds. Il utilise Kadcast — une superposition structurée, où la position de chaque nœud détermine à qui il transmet. La documentation donne la raison en une ligne : moins de bande passante, et une latence plus prévisible.
Le mot qui compte ici, c’est « prévisible ».
Les ragots aléatoires sont robustes mais bruyants. Un message peut vous parvenir en 200 ms ou en 900 ms selon la chance. Pour la plupart des chaînes, c’est acceptable. Pour une chaîne qui vend une finalité déterministe d’environ 10 secondes à des institutions, la variance de propagation n’est pas un détail esthétique — c’est une partie de la promesse de règlement. On ne peut pas garantir le timing de la finalité par-dessus une couche de transport qui hausse les épaules.
La seconde moitié, c’est l’audit. Blaize a relu l’implémentation Rust et lui a attribué une note de 9,8 sur 10, mais ce qui intéresse, ce sont les conclusions : des écarts par rapport à la spécification originale de Kadcast, des cas limites manqués dans le traitement des nœuds inactifs, et un traitement ambigu des champs réservés dans les en-têtes de messages. Tout a été corrigé ou vérifié, sauf deux éléments d’information.
Champs réservés et nœuds inactifs. Pas glamour. Exactement le genre de chose qui se transforme en incident de production étrange trois ans plus tard.
La question ouverte avec laquelle je continue de composer : une superposition structurée signifie que la topologie est déductible plutôt qu’aléatoire. C’est ce qui permet la prévisibilité. Est-ce que cela rend aussi les schémas de trafic plus faciles à observer pour une chaîne dont toute la proposition de valeur est la confidentialité ? Je l’ignore vraiment, et je n’ai pas trouvé d’analyse publique qui réponde à cette question.
Pour une chaîne de confidentialité — accepteriez-vous une partie de prévisibilité de propagation contre un réseau plus chaotique, plus difficile à cartographier ?

Deux choses que je pensais être fixes

Je suis allé dans la documentation sur le contrôle d’accès pour chercher autre chose, et je suis ressorti avec une liste plus courte de choses que j’appellerais des constantes.
L’oracle d’abord. Il y a deux fonctions : l’une qui soumet une nouvelle source de prix pour un actif, et l’autre qui l’accepte. Toutes deux relèvent du rôle administrateur par défaut. Ainsi, le flux qui décide si votre position est saine est un paramètre.
Ensuite, les frais. Un rôle de configurateur peut mettre à jour le taux de frais sur une commande spécifique, et mettre à jour la configuration du marché, y compris l’adresse du trésor et les paramètres de frais.

Aucune de ces choses n’est inhabituelle. Chaque protocole de prêt a des interrupteurs comme ceux-ci, et vous les voulez le jour où un flux commence à imprimer n’importe quoi. Morpho, Aave, tous.
Ce que je n’ai pas pu trouver dans cette page, en revanche, c’est une période d’attente explicitement indiquée entre le fait de soumettre l’une de ces informations et le fait de l’accepter. La couche des vaults documente clairement son timelock. Pour cette couche-ci, je ne suis pas sûr — et je préfère dire que je ne suis pas sûr plutôt que de deviner.

Si vous pouviez imposer un délai obligatoire sur exactement l’une d’elles, choisiriez-vous le flux de prix ou le taux de frais ?

#termmax @TermMax $AAVE

Je m’attendais à une transaction. J’en ai compté trois.

C’est un retrait via le pont DuskEVM, directement depuis le guide officiel de Dusk :

1. Initier le retrait sur DuskEVM
2. Le prouver sur le Dusk L1
3. Le finaliser sur le Dusk L1

Trois actions on-chain, et des frais des deux côtés : la transaction source, puis deux autres sur le L1.

L’instruction que je respecte le plus concerne le timing. La documentation dit que la disponibilité du retrait dépend de l’état du réseau publié, de la maturité de la preuve et des vérifications du dispute-game, et que le champ de statut du portefeuille est la référence — ne déduisez pas la disponibilité à partir du temps écoulé. Cette phrase existe parce que les fenêtres de retrait des rollups ne sont pas des horloges : ce sont des machines d’état. Toute intégration qui a codé en dur « attendre N minutes, puis finaliser » finit par se casser : une proposition arrive en retard, un contrôle dure plus longtemps, et votre finaliseur soumet dans un état qui n’est pas prêt.

Le deuxième détail en dit plus que le nombre d’étapes. Le guide vous dit de garder suffisamment de DUSK non protégé sur le L1 pour payer à la fois la preuve et la transaction de finalisation. Prenez le temps de considérer cela sur une chaîne dont l’argument central est le transfert confidentiel : la sortie depuis sa propre couche EVM est libellée dans un solde transparent. Mise en garde, et c’est important — c’est le guide du testnet : DuskEVM est encore étiqueté Testnet, donc la forme sur mainnet pourrait changer.

Pour être juste, rien de tout cela n’est une invention de Dusk. C’est une conception standard de rollup optimiste, héritée de l’OP Stack, et chaque chaîne OP vous demande les mêmes trois actions. La question n’est donc pas de savoir si Dusk s’est trompé. C’est ce que fait l’UX standard des rollups à une chaîne dont la différenciation entière est la confidentialité.

Les chaînes orientées confidentialité ont-elles besoin d’une conception de pont fondamentalement différente ? Ou bien le gaz transparent au niveau de règlement est-il un prix équitable à payer pour un environnement de développement familier ?

#dusk $DUSK @Dusk

Il est 2 h du matin et un prêt @TermMax vient juste d’arriver à échéance. Aucun remboursement n’est entré. Pendant les deux prochaines heures, n’importe qui peut le liquider — puis la fenêtre se referme.
C’est étrange si vous êtes habitué aux liquidations déclenchées par le LTV. Ici, le déclencheur est une horloge, pas un prix. La pénalité de 10 % sur la dette liquidée n’est pas vraiment des frais — la moitié revient à celui qui clôture la position, l’autre moitié au fonds de réserve du protocole. C’est une récompense pour s’assurer qu’un robot soit éveillé à cette heure précise, pas seulement lorsque le prix bouge.
Parfait pour l’ETH ou une stablecoin. Histoire différente pour un token PT ou un LRT peu liquide. Deux heures suffisent pour passer par un pool profond. Ce n’est pas beaucoup de temps pour dénouer une taille réelle en collatéral qui ne se négocie presque pas un jour normal.
Le mécanisme de livraison physique de TermMax est censé remettre aux prêteurs une tranche de collatéral au prorata si la fenêtre se ferme sans liquidation propre. Ce dont je ne suis pas sûr, c’est à quel point ce relais est réellement automatique — c’est la partie des documents que je relis sans cesse.
Dans tous les cas, le risque ne disparaît pas à la marque des deux heures. Il passe du liquidateur au prêteur.
Quel collatéral ne voudriez-vous pas détenir lorsque cette fenêtre s’ouvre, et pourquoi ?

#termmax @TermMax

Tout le monde vend l’emprunt à taux fixe comme une certitude. Après quelques heures passées dans la documentation, je pense que ce cadrage sous-estime en réalité ce que <0>@TermMax built</0> — et il cache une question que personne dans cette campagne ne pose.
Voici la phrase qui m’a bloqué. Sur <0>#termmax your debt isn't just a number sitting in a contract. It's denominated in FT, the fixed-rate token, and repayment can be settled by buying FT off the open market instead of paying face value.</0>
Restez-y une seconde.
Vous verrouillez une garantie dans un Gearing Token, vous émettez FT contre celle-ci, vous vendez la partie intérêts, puis vous partez avec de la liquidité à un taux convenu dès le premier jour. L’intérêt sur toute la durée est déjà intégré à la dette dès le premier bloc. Pas d’accumulation, pas de remise à zéro, rien qui dérive pendant que vous dormez.
Ensuite, les taux de marché montent. Chaque FT sur ce marché — y compris celui qui représente votre propre passif — commence à s’échanger avec une décote plus profonde. Et puisque la dette est en FT, vous pouvez la racheter en dessous du pair et régler moins que le taux que vous aviez initialement verrouillé.
Donc le taux fixe n’est pas un coût fixe. C’est un plafond. Verrouillé en haut, ouvert en dessous.
Passez maintenant au prêteur. Il détient une créance à coupon zéro qui se rembourse 1:1 à l’échéance. Quand les taux montent, son FT vaut moins s’il veut sortir tôt, et en conservant jusqu’à l’échéance, il obtient exactement le pair. Plafond et plancher sont le même nombre. L’emprunteur a de la convexité. Le prêteur n’en a pas.
Cette asymétrie ne disparaît pas simplement parce qu’aucun tableau de bord ne l’affiche. Elle est payée quelque part. Soit elle est déjà incluse dans la décote que les prêteurs exigent lors de l’émission — auquel cas le taux fixe que les emprunteurs voient porte discrètement une prime d’option — soit elle n’est pas du tout tarifée, et les emprunteurs détiennent une option de taux gratuit que des conservateurs et des faiseurs d’ordres financent sans la labelliser.
La deuxième version est celle que j’aimerais voir exclue avant de grossir la taille d’un vault. Les courbes de taux en DeFi sont généralement déterminées à partir de l’utilisation et des attentes de rendement, pas à partir de l’optionnalité.
Donc, pour toute personne qui place ici des ordres de range de prêt : élargissez-vous votre courbe pour que des emprunteurs puissent racheter leur dette à bon prix, ou est-ce que c’est toujours invisible dans votre tarification ?

#dusk $DUSK @Dusk La configuration de confidentialité de Dusk fonctionne en réalité sur deux filières distinctes. Sur DuskDS, le modèle Phoenix représente la valeur sous forme de notes engagées dans un arbre de Merkle — dépenser une note ne pointe pas vers quelle note est dépensée. À la place, l’émetteur publie un nullificateur et une preuve de connaissance zéro montrant que la dépense est valide, que la possession est réelle et qu’aucune valeur n’a été créée à partir de rien, sans révéler la note sous-jacente. En parallèle, Moonlight fonctionne comme un modèle transparent basé sur les comptes, sur la même chaîne.

Sur DuskEVM, en revanche, la confidentialité provient d’un ensemble d’outils complètement différent — un module appelé Hedger, qui combine un chiffrement homomorphe basé sur ElGamal avec des preuves de connaissance zéro, ainsi qu’une structure hybride UTXO/comptes. Ici, un utilisateur interagit avec des contrats via une adresse EVM standard, tandis qu’une adresse Hedger distincte gère les soldes chiffrés, avec une conformité imposée par liste d’autorisation.

Il ne s’agit pas de deux versions de la même idée. Phoenix est un système de preuve basé sur des notes ; Hedger calcule directement sur des soldes chiffrés, vérifiés via des preuves de connaissance zéro. La raison la plus probable de cette séparation est que la confidentialité basée sur des notes ne s’intègre pas naturellement dans une structure EVM basée sur des comptes, d’où la nécessité d’une approche différente.

Faire tourner en parallèle deux piles indépendantes de confidentialité cryptographique implique une surface d’attaque plus large et une charge d’audit plus lourde. On ne sait également pas clairement comment la garantie de confidentialité est préservée lorsque la valeur passe d’une couche à l’autre.

Le fait de maintenir deux moteurs de confidentialité distincts multiplie-t-il la charge d’audit de manière proportionnelle, ou bien le recours partagé aux preuves de connaissance zéro signifie-t-il que le coût incrémental du second moteur est en réalité plus faible qu’il n’y paraît ?

#dusk $DUSK @Dusk

Je me suis mis à chercher comment les récompenses de staking de DUSK sont réellement financées, en m’attendant à quelque chose de similaire à la plupart des chaînes PoS que j’ai vues : soit un taux d’inflation fixe et élevé au début, soit des récompenses financées presque entièrement par les frais de transaction dès le départ. Ce que fait Dusk n’est ni l’un ni l’autre.

Les récompenses sont financées par une émission de 500 millions de DUSK libérée sur 36 ans, selon une courbe de décroissance géométrique qui est divisée par deux environ tous les quatre ans. C’est une réduction longue et progressive, plutôt qu’un fonds de récompenses “front-loaded” (chargé en début de période) ou une “falaise” (chute brutale) agressive au départ.

Ce qui m’a fait m’arrêter, c’est l’inadéquation entre cet horizon d’émission et le rythme auquel la crypto avance d’ordinaire. La plupart des calendriers de récompenses en tokens sont conçus pour traverser rapidement les premières années volatiles — démarrage rapide, décrue rapide, puis laisser les frais prendre le relais au plus vite. Une courbe sur 36 ans se rapproche davantage de l’horizon d’un fonds de pension que d’un programme d’incitation typique pour validateurs. Et cela ressemble moins à un oubli qu’à un signal sur le type d’adoption que le protocole parie réellement : une infrastructure financière régulée, qui a tendance à avancer en années et en décennies plutôt que dans les cycles de marché.

La tension se situe entre “maintenant” et “plus tard”. L’adoption institutionnelle de valeurs mobilières tokenisées et le règlement on-chain conforme ne se font pas du jour au lendemain, et les revenus de frais issus de ce type d’activité sont probablement encore précoces par rapport à l’endroit où le protocole veut éventuellement en arriver. En attendant, les validateurs sont payés principalement via des émissions plutôt que via l’usage, ce qui est un état normal au début pour une chaîne PoS, mais une chose difficile à concilier avec un horizon de conception de 36 ans.

Je ne pense pas qu’une longue courbe d’émission soit intrinsèquement une faiblesse — des horizons longs disent la vérité sur la lenteur avec laquelle la finance régulée avance réellement. Mais cela soulève la question de savoir si des économies de staking conçues pour une adoption institutionnelle qui s’étend sur des décennies peuvent maintenir l’engagement des validateurs pendant les années qui précèdent l’apparition effective de cette adoption dans les revenus de frais.

Il existe un certain type de calme qui apparaît dans les projets d’infrastructure, et il vaut la peine d’apprendre à le lire correctement. Ce n’est pas la même chose que l’échec. Mais ce n’est pas non plus un succès évident.

Le crépuscule est sur le mainnet depuis un moment déjà. Le dossier technique est cohérent : contrats intelligents confidentiels, la norme XSC, la divulgation sélective — tout repose sur un problème concret et réel que la finance réglementée a vraiment. Et pourtant, lorsque l’on observe l’activité réelle du réseau, la majorité de ce qui se passe relève du jalonnement. Contrats confidentiels, émission réelle de titres — encore rares, d’après la plupart des signaux disponibles.

Cet écart entre ce que l’infrastructure peut faire et ce qui s’y exécute réellement mérite qu’on s’y attarde, plutôt que de l’expliquer trop vite.

Quelques éléments jouent en sa faveur, et il est utile de les nommer clairement. Le déblocage anticipé est déjà allé jusqu’au bout, il n’y a donc pas d’événement de déblocage imminent qui viendrait fausser les attentes concernant l’offre. Des partenariats avec des plateformes agréées donnent à la posture réglementaire quelque chose de plus proche du fondement que d’une simple ambition. Et, d’après la plupart des analyses techniques, la couche d’infrastructure elle-même n’est pas le point faible — cela ne se lit pas comme une histoire.

La question la plus difficile concerne l’alignement des incitations. Les institutions les mieux placées pour réellement utiliser ce type d’infrastructure de confidentialité et de conformité n’auront peut-être jamais besoin de détenir de grandes quantités du token : leur exposition pourrait rester minimale, juste assez pour un usage opérationnel. Pendant ce temps, les personnes qui détiennent effectivement le token absorbent des émissions continues, en attendant un volume qui n’a pas encore fait son apparition, du moins pas à une taille significative. Deux relations très différentes à un même actif, sans mécanisme évident qui les ferait converger vers l’alignement.

Ce n’est pas une critique du design. C’est simplement une description honnête de la situation actuelle : techniquement capable, financièrement encore en attente de preuves.

La question à laquelle personne ne peut vraiment répondre pour l’instant, y compris le projet lui-même, c’est combien de temps « l’infrastructure est prête » pourra rester une réponse satisfaisante avant que le marché commence à exiger que l’infrastructure soit effectivement utilisée.

@Dusk #dusk $DUSK

Un nombre m’a arrêté net : une capacité de plus de 17 milliards de feuilles, provenant d’un arbre qui n’a que 34 niveaux de profondeur.
Le modèle Phoenix de Dusk utilise un arbre de Merkle binaire pour stocker la preuve de chaque note, et c’est là que se trouve la vraie astuce : la capacité croît de façon exponentielle tandis que le chemin d’inclusion ne fait qu’augmenter linéairement. Passez de la profondeur 34 à 35 : la capacité double, mais le chemin de preuve n’allonge que de quelques pourcents. Cette asymétrie compte énormément pour une chaîne axée sur la confidentialité, car chaque transaction transporte une preuve à divulgation nulle, et plus cette preuve reste petite, mieux c’est.
Mais la taille de ce nombre n’est qu’un plafond théorique. Ce qui détermine réellement combien de temps cette capacité dure, c’est la vitesse à laquelle de nouvelles notes sont créées en pratique. À faible débit de transactions, l’arbre pourrait mettre des décennies à se remplir. En cas d’adoption soudaine, cette même capacité pourrait subir une forte pression en quelques mois.
Cela soulève la question la plus intéressante : que se passe-t-il quand l’arbre se remplit ? Stockage d’archives, coûts de preuve, synchronisation d’état — est-ce que tout cela s’ajuste harmonieusement en même temps que la création de notes, ou est-ce que quelque chose commence à se tendre en premier ? Un énorme nombre paraît impressionnant sur le papier, mais l’utilisabilité à long terme dépend de la façon dont ce nombre est employé, pas seulement de sa taille.
Avoir une capacité mathématiquement gigantesque est-ce la même chose que rester à l’aise d’utilisation sur des années de usage réel ?

#dusk $DUSK @Dusk

J’ai relevé les chiffres en cours avant d’écrire ceci, donc voici ce qui est vraiment sur la bande aujourd’hui : DUSK s’échange autour de 0,065–0,066 $, avec une capitalisation d’environ 32–33 M$ d’après la lecture de CoinMarketCap, et un volume sur 24 h qui se situe entre 3,5 et 4,8 M$ selon l’agrégateur auquel vous faites confiance — CoinGecko s’appuie sur 45 exchanges et 51 marchés, CoinCodex est plus près de 4,8 M$. Cet écart à lui seul vous dit quelque chose : la liquidité est assez faible, de sorte que le fait de vérifier une source de données plutôt qu’une autre change le récit de 30 %.
Les estimations de l’offre en circulation divergent aussi : la CMC l’évalue à près de 497 M, tandis que CoinGecko est plutôt autour de 590 M — par rapport à une offre maximale de 1 Md, ce qui signifie qu’entre la moitié et 60 % de l’offre totale est déjà débloquée et se négocie.
En reculant un peu, l’évolution des prix raconte une histoire plus approximative que le récit des fondamentaux. DUSK a cassé une tendance baissière de 8 mois en janvier 2026, a flambé au-dessus de 0,30 $ après le mainnet, puis a rendu presque tout — en se négociant près de 0,10 $ à la fin avril, et maintenant en consolidation autour de la zone 0,06 $. Cela représente un retracement d’environ 80 %+ depuis le plus haut de janvier, alors que le récit réel du développement — mainnet en ligne, avancement du testnet DuskEVM, tokenisation NPEX en cours — a continué d’avancer largement sans interruption.
Cette divergence, c’est la vraie histoire, pas le prix lui-même. La vélocité de développement et la vélocité des prix se sont fortement découplées quelque part autour du T1, et elles ne se sont pas (encore) recollées. Soit le marché a déjà intégré tout ce que la feuille de route promet et attend maintenant que le TVL soit effectivement livré, soit le récit RWA n’est simplement pas encore suffisamment liquide pour faire bouger, à lui seul, un actif de 32 M$ de capitalisation.
De quel côté de ce décalage pensez-vous que le marché se referme en premier — est-ce que le vrai volume NPEX finit enfin par apparaître on-chain, ou est-ce que le prix continue juste de dériver jusqu’à ce que ça arrive ?
#dusk $DUSK @Dusk

J’étais prêt à investir, mais j’ai renoncé après avoir vu les signes avant-coureurs.

?

bon 😊