L’app de réservation de taxi fait souvent ça : elle te donne un prix estimé pour te préparer psychologiquement, puis au final on te facture selon la distance réelle. Le Gas de @Dusk , c’est exactement la même histoire : les frais correspondent à `gas_used × gas_price`. Le Gas price est libellé en LUX, et 1 DUSK vaut 1 milliard de LUX. Le crédit non consommé n’est pas débité, mais si le Gas s’épuise en plein milieu de la transaction, toute l’opération est annulée (rollback) : les calculs effectués au début sont payés comme promis, sans compensation. Au début, je trouvais ce réglage vraiment piégeux, puis j’ai compris : si l’échec était totalement gratuit, des hackers pourraient déclencher des appels complexes en boucle pour provoquer d’infinies erreurs, et faire travailler les nœuds inutilement. Voilà le vrai piège.
Donc, à chaque fois que je confirme une transaction, je vérifie séparément trois choses : si le gas limit est suffisant pour exécuter tout le parcours, si le gas price est raisonnable, et si l’objet d’appel et les paramètres n’ont pas été mal remplis. Et si ça échoue, ne te précipite pas pour renvoyer : commence par consulter le navigateur officiel pour clarifier le type, les frais, la quantité utilisée et l’endroit précis de l’erreur. Doubler aveuglément le plafond ne fait que donner plus de carburant à un contrat erroné ; c’est un pansement, pas une solution.
Le flux des frais est aussi assez intéressant. Chaque bloc reçoit une récompense issue d’une nouvelle émission de $DUSK plus les frais de transaction, répartie entre le producteur du bloc, le fonds de développement et le comité ; la partie non attribuée peut être détruite. Quand le réseau est surchargé, les frais peuvent aussi alimenter des incitations à la validation, mais ce n’est pas une “distribution” que tu peux simplement empocher en détenant des tokens.
Ce qui m’a vraiment fait m’arrêter pour regarder de près, c’est la confidentialité. Dusk ne cache pas toutes les transactions : il fait une divulgation sélective. En situation de conformité, il permet de prouver les informations nécessaires, sans tout étaler en détail sur la chaîne publique. XSC, DuskEVM, et le cadre d’identité Citadel : ça ressemble davantage à un scénario financier réel que juste “crier privacy chain”.
Le processus de Citadel 2 se fait en quatre étapes : le License Provider procède à un audit hors chaîne et délivre des attestations chiffrées, l’utilisateur génère ensuite une preuve à divulgation nulle de connaissance (ZK) en ne montrant que qu’une preuve de détention valide, puis le contrat vérifie et conserve une session publique ; le service décide ensuite s’il accepte ou non. Sur la chaîne, on ne prouve que l’existence d’une session, sans se soucier de qui fait confiance à quelle institution, de quelles propriétés sont exigées, ni si les attestations ont expiré. Une même matière d’identité n’a pas besoin d’être stockée à répétition sur chaque plateforme : le risque passe de la duplication des données à la gouvernance de l’émetteur et à la synchronisation des révocations.
Avant d’utiliser Dusk, il faut d’abord comprendre le Gas : tu peux éviter quelques erreurs d’exécution et économiser sur les frais d’apprentissage. Et pour savoir si ça marche ou non, il faut regarder le résultat de la transaction : la valeur arrive-t-elle vraiment et durablement à s’écouler vers DUSK ? Il faudra continuer d’observer l’utilisation réelle du réseau et le rythme d’offre. #dusk $DUSK
Je regarde en boucle le @Dusk depuis un moment, et plus je regarde, plus je trouve ça intéressant.
D’abord, parlons du cycle de vie des transactions qui me met vraiment dans le rythme. Au début, j’ai été un peu trompé par l’idée de finalité déterministe : j’ai retourné des documentations pendant plusieurs jours avant de comprendre que « confirmed » et « finalized » sont deux choses complètement différentes. Le bloc n’est pas encore passé à l’étape finale : il peut toujours être revert. Le flux se fait comme suit : le provisioner propose d’abord un bloc candidat, puis un comité aléatoire fait la validation, ensuite une série de Ratification, et ce n’est qu’après le ratify que c’est réellement « posé ». Ce n’est pas comme si une fois proposé c’était automatiquement plié ; au contraire, après la finalisation, tu n’as plus besoin d’empiler des confirmations.
Si c’est juste un simple virement, ça passe encore, mais pour un dépôt d’échange ou une livraison de titres, on ne peut pas jouer comme ça. Le fait de détecter l’événement « executed » ne fait que dire que l’exécution a eu lieu : il faut encore vérifier que l’eventuel « error » est vide, et ce n’est qu’avec l’événement « finalized » que c’est solide. Si jamais tu reçois un « reverted », il faut reécouter/rejouer. Un revert de contrat, c’est une erreur de code ; un revert de bloc, c’est un changement de consensus. La logique de reprise part donc dans deux directions complètement opposées. Si l’intégrateur prend « confirmed » pour « finalized », la déterministicité s’effondre au niveau applicatif. Ce qui me préoccupe le plus maintenant, c’est de savoir si l’échange et Dusk Trade utilisent bien tous les deux « finalized » comme frontière, et s’il existe un processus de rejouabilité auditable.
Passons au trading équitable : là, ça m’a vraiment dégoûté. Le mempool, c’est comme une serre en verre sans rideaux : tu veux acheter quoi que ce soit, tout le monde le voit. Les robots à pinces peuvent te planter le bec à tout moment. Le $DUSK fait directement des enchères privées en lots à l’échelle du protocole : les offres et les quantités sont soumises, puis ZK les étouffe instantanément. Les nœuds calculent un prix « juste » qui fait tendre la différence entre la demande totale des ordres cachés et l’offre totale des ordres de vente vers zéro ; ensuite, dans le même bloc, tous les ordres en attente sont réglés à ce prix. L’asymétrie d’information est renversée : la dark pool n’est plus équitable seulement en surface, elle l’est jusque dans ses entrailles.
Côté conformité, on ne se moque pas du monde non plus. Phoenix utilise ZK pour préserver la confidentialité, Moonlight passe par un registre transparent, Citadel supporte la divulgation sélective, et XSC écrit les critères d’éligibilité, les limites et les rapports directement dans la logique du contrat. Nul besoin de tout compter sur des règles en dehors de la chaîne.
Plus un produit est complexe, plus il y a de règles ; et la vraie question est : est-ce que ces règles peuvent tourner de manière fiable ensemble dans différents workflows ? C’est exactement ce que je continue de surveiller. La véritable finalité n’est pas un terme : c’est un enchaînement d’événements de nœud jusqu’au registre, sans que personne ne se précipite entre-temps. #dusk $DUSK
J’ai encore relu hier le document de @Dusk et, franchement, ça m’a un peu mis dans un état de “décrochage”.
D’un côté, ils disent être dans la “privacy track”, et la solution de Phoenix avec UTXO plus preuves à connaissance zéro est vraiment solide : les infos de transfert sont soigneusement protégées. Puis, juste après, ils bricolent un DuskEVM compatible Solidity, clairement pour capter le flux des développeurs d’Ethereum. Et même l’officiel le dit : le modèle de compte et l’UTXO ne sont pas du tout la même espèce en matière de confidentialité. Donc la compatibilité “à fond” implique de sacrifier l’anonymat. C’est là que ça devient gênant : développer avec l’outil EVM, c’est ultra simple, mais la privacy n’est plus qu’à moitié ; si on veut une confidentialité vérifiable et réellement audit-able, il faut s’attaquer aux barrières de l’environnement natif, et se retrouver coincé entre les deux, c’est assez inconfortable.
Côté nœud, c’est encore plus tortueux. Avec le consensus Succinct Attestation, miser 1000 DUSK te donne le rôle de Provisioner : le seuil a l’air très abordable, et même les particuliers peuvent essayer. Mais si tu regardes plus haut, la vraie sortie de valeur : les canaux RWA, les licences NPEX, la vérification d’identité conforme, tout est entre les mains d’institutions. La couche de base est un PoS permissionless, la couche supérieure est un club permissionné. Dans ce type d’architecture, je n’ai pas encore compris comment le token pourrait capturer de la valeur.
Et il y a aussi cette émission native, avec une ambition franchement énorme. Leur intention n’est pas simplement d’émettre un token, mais d’embarquer dans une machine à états tout : liste blanche, view key, transferts contrôlés, et règlement/livraison. Dans l’idéal, les titres privés placés en privé n’auraient plus besoin de comptabilité hors chaîne, mais le problème, c’est la validité juridique et des sujets comme la garde et la reconnaissance : aussi élégant que soit le déroulement on-chain, ça ne remplace pas ces aspects.
Honnêtement, les choix de Phoenix en matière de divulgation sélective, le basculement entre deux modèles de Moonlight, et la logique d’émission de Citadel sont, sur le plan du design, vraiment ingénieux. Mais l’expérience concrète montre une complexité non négligeable : pour un utilisateur lambda, ça a de fortes chances de décourager. Il y a de la place pour le récit de conformité dans le cadre du MiCA en Europe, j’admets. Mais est-ce que l’avantage technique pourra vraiment se traduire par de l’activité on-chain ? Ça dépendra surtout de la capacité de l’écosystème à tourner réellement.
Je continuerai à surveiller, mais avant que l’argent réel ne rentre, il faut d’abord démêler proprement ces logiques d’épine dorsale. #dusk $DUSK
J’ai passé la moitié d’une année à tester des nœuds, et maintenant je suis habitué à commencer par fouiller la couche de diffusion. Récemment, je suis tombé dans un piège : la bande passante du nœud montait directement au maximum, et les mails d’alerte se sont mis à remplir l’écran. Au début, je pensais que c’était à cause du volume de transactions trop élevé ; en parcourant les logs, j’ai compris : au niveau de la couche inférieure, le comportement par défaut ressemble à une diffusion « arrosage » à l’échelle du réseau entier. Il suffit que le nœud oscille un peu pour que les messages répétés soient poussés jusqu’à l’extrême, comme dans un embouteillage.
Ensuite, en relisant le document @Dusk , j’ai vu la partie Kadcast, et je dois dire que j’y ai passé un bon moment. Ça n’utilise pas une diffusion aveugle : c’est basé sur la topologie de Kademlia. On calcule une distance XOR via le hachage d’identité du nœud, puis on répartit les correspondants dans différents « buckets » de routage. Lors de la diffusion, on ne fait plus un envoi désordonné en rafale : on envoie de façon ordonnée par niveaux de distance, et on synchronise tout le réseau en une sorte d’arbre de multidiffusion structuré. En test local, j’ai clairement vu que les pics de bande passante étaient nettement réduits. Et après plusieurs sauts, il devient beaucoup plus difficile pour un observateur externe de remonter l’émetteur rien qu’à partir des caractéristiques de trafic. Le livre blanc annonce 25%-50% de bande passante économisée par rapport au Gossip classique ; perso je le prends comme référence. Mais avec des nœuds qui s’allument et s’éteignent fréquemment, des secousses entre zones, et un rafraîchissement de table de routage qui accuse du retard : une fois tout ça superposé, l’économie réelle sera forcément rognée. En complément, l’usage de BitVM3 pour vérifier et faire office de garde-fou garantit que les transactions non conformes n’ont même pas la possibilité d’entrer. Cette approche partage la même logique de base que celle de la mise en garantie : on « soude » les règles dans la cryptographie.
Mais une forte dépendance à la topologie logique a aussi un coût. Si jamais on subit un découpage en partitions transnationales, ou si des nœuds malveillants injectent des données polluées dans les buckets de routage, alors lors du basculement vers des chemins de secours, le surcoût de recherche d’adresse peut très vite annuler l’avantage en latence. Une bande passante contrôlée, c’est vraiment une bonne nouvelle : pour les utilisateurs ordinaires qui font une mise en garantie, pas besoin de tirer une ligne dédiée, le seuil baisse d’un cran. En revanche, le dépannage est plus compliqué que pour une diffusion classique, donc il faut avoir ça en tête.
J’ai aussi rencontré des soucis côté cross-chain. Le transfert du mainnet vers la BSC n’est pas juste un « déménagement » direct. Il faut envoyer le DUSK natif vers le compte de pont officiel ; une fois la validation sur le mainnet terminée (verrouillage confirmé), on génère un BEP20 sur la BSC à partir de l’adresse BSC indiquée dans le Memo. Le montant doit être supérieur à 1 DUSK : les frais correspondent aux frais du mainnet plus les frais de pont de 1 DUSK. L’arrivée prend environ une heure ; dans les faits, le montant reçu correspond à la quantité envoyée moins 1.
Kadcast utilise une distance mathématisée pour réduire le risque de redondance et d’investigation (traçage) de l’origine, mais, dans l’environnement public où les nœuds entrent et sortent, il faut encore voir si la mise à jour des tables de routage est suffisamment rapide et si le pool de chemins alternatifs est assez fourni. C’est vraiment ce qu’il faut surveiller. Quand ça marche, c’est une mise à niveau pragmatique ; quand ça ne marche pas, c’est une simple décoration sur papier. $DUSK #dusk $DUSK
Je surveille récemment les RWA et, franchement, plus je les regarde, plus je me sens anxieux. Mettre des actifs on-chain, techniquement il y a de quoi faire — mais si tu demandes vraiment à une institution de rapatrier maison, obligations et actions, pour les mettre là-dedans et essayer ? La transparence des chaînes publiques, c’est comme des maisons en verre : les secrets commerciaux sont entièrement exposés, qui oserait ? Et les chaînes de confidentialité sont si opaques que même le régulateur n’arrive pas à mettre le doigt dessus. Après avoir fouillé, j’ai constaté que @Dusk ne s’est pas rangé d’un côté : il intègre directement confidentialité et conformité dans le socle. La logique est plutôt intéressante.
J’ai spécialement pris le temps d’examiner sa stack technique. Le consensus Succinct Attestation : des comités aléatoires qui travaillent, et les forks/retours en arrière ont très peu de chances. DuskEVM est compatible avec Ethereum ; j’ai lancé un petit démo avec Solidity, et la fonctionnalité de confidentialité s’est littéralement activée d’emblée. Le protocole Hedger, avec une confidentialité auditable, m’a laissé perplexe un moment : tous les détails sont verrouillés, mais au moment de la conformité, il peut produire des preuves vérifiables. La technique est plutôt redoutable. Deux modèles de transactions, Moonlight et Phoenix, fonctionnent en parallèle : selon les besoins, chacun son usage. J’ai aussi vu le plan NPEX d’horodater sur la chaîne plus de 300 millions d’euros de titres — le rythme de déploiement, je vais le surveiller de près.
Mais soyons honnêtes : j’ai une question qui me reste en tête. La clé capable de déverrouiller toute la confidentialité, à la fin, elle est en main de qui ? Tout dépend de ça : liberté ou une autre forme de contrôle. J’ai fait des calculs : l’émission continue de tokens et le verrouillage compriment l’élan ; si la réglementation européenne change, le récit risque d’être totalement reformaté. La liquidité secondaire des premiers actifs et le coût ZK restent à vérifier par l’empirique.
Il y a quelque temps, beaucoup de monde s’est laissé berner par des affirmations de validation on-chain en 2,8 millisecondes ; j’y ai presque cru aussi. PLONK réduit bien la vérification au maximum, mais c’est léger on-chain et lourd off-chain. De mon côté, j’ai tourné en local des circuits d’identité Citadel : avec une seule licence, on dépasse 30 000 constraints ; le prover a mis près de 16 secondes à travailler, tandis que le verifier prend seulement 0,007 seconde. La prime de calcul du ZK est à peu près 10 000 fois l’opération native : toute la pression est renvoyée sur l’équipement local.
Je suis du genre à vérifier moi-même : je ne regarde pas seulement l’origine, je regarde le code. La voie choisie par Dusk est difficile mais juste. Pourtant, pour ce qui est du passage à l’implémentation, il reste encore des enjeux de jeu réglementaire et d’acceptation par le marché. Mes deux priorités à l’instant sont donc : qui gère cette clé, et le volume de transactions réel après l’onshoring d’actifs de 300 millions d’euros. Le reste — je verrai après avoir fini les tests. #dusk $DUSK
J’ai lu hier le livre blanc @Dusk . Honnêtement, au début, j’y suis allé avec un état d’esprit prêt à critiquer. Et au fur et à mesure que je lisais, je me suis rendu compte que ce projet est un peu « obsessionnel » dans sa direction.
D’abord, les points à redire : le livre blanc est d’une technicité incroyable. On y trouve une foule de termes d’algorithmique et de cryptographie, ça se lit presque comme un article de recherche en ingénierie financière. J’ai failli abandonner en cours de route. La progression de l’écosystème est aussi lente : pendant que d’autres publient des annonces de collaborations tous les jours, eux travaillent dans leur coin sur le mainnet et la norme XSC, et la portée médiatique sur le marché est carrément minime. Les tokens et la communauté sont même assez « flegmatiques », sans aucune énergie pour faire décoller le cours.
Cela dit, après avoir critiqué ces trois points, j’ai finalement plus envie de l’observer sur le long terme. Car l’infrastructure financière ne fonctionne pas uniquement grâce aux appels et au pumping : les institutions cherchent surtout la stabilité et la conformité.
Techniquement, par contre, il y a vraiment quelque chose : Dusk intègre nativement PLONK zk-SNARK et Bulletproofs dans les couches fondamentales du protocole. La confidentialité n’est pas un simple module ajouté à un DApp, mais une propriété inhérente à la blockchain. En plus, avec Citadel ZK-KYC : quand les utilisateurs terminent la vérification d’identité, ils n’ont pas besoin de téléverser des données brutes comme un passeport ; ils soumettent uniquement une preuve de connaissance zéro déjà validée comme conforme. Cela cible directement les cas d’usage RWA et de tokenisation de valeurs mobilières au niveau institutionnel : il faut être conforme, sans exposer l’intégralité des positions et des stratégies sur le registre public.
Évidemment, il y a aussi eu des problèmes : OtterSec avait trouvé une faille dans dusk-plonk côté vérificateur ; un adversaire malveillant pourrait fabriquer des preuves frauduleuses. Heureusement, l’équipe a ensuite verrouillé les frais, le remboursement et la cohérence des adresses entre les deux frontières du mempool et de la VM avec AEGIS, et a ajouté des tests de régression ciblés. Une preuve de connaissance zéro correcte ne signifie pas automatiquement que les données autour de la transaction sont toutes sécurisées : cette leçon est très parlante.
Donc, aujourd’hui, je vois $DUSK davantage comme l’observation d’une trajectoire qui cherche réellement à faire une compensation financière axée sur la confidentialité. Plus lentement, ce n’est pas grave ; l’essentiel est de savoir si la couche de base et la sécurité tiennent face aux exigences des institutions. $DUSK #dusk $DUSK
Récemment, j’ai discuté DeFi avec des amis, et ce que tout le monde critique le plus, c’est le taux d’intérêt variable. Ça a l’air très séduisant : on dépose et le taux change comme bon lui semble, sans qu’on puisse savoir combien on gagnera dans six mois. J’en avais vraiment assez de ce genre de retournements, alors j’ai commencé à chercher des solutions à taux fixe, et je suis tombé sur <@TermMax >.
D’abord, le mécanisme : il découpe le prêt en trois parties, FT, XT et GT. Le FT ressemble à une obligation à coupon zéro : acheté avec une décote, il est racheté à la valeur nominale à l’échéance, et l’investisseur prêteur gagne la différence. Le GT est une position sous forme NFT, qui enregistre le collatéral et la dette ; le XT sert à maintenir l’équilibre. L’emprunteur encaisse des actifs en collatéral pour créer des GT et des FT, vend les FT pour obtenir des fonds, puis rembourse et rachète le collatéral à l’échéance. Ensuite, il y a l’« Range Order » : une courbe de prix permet d’écrire les plages de taux d’intérêt dans le mécanisme, et en théorie, cela permet de produire une courbe de rendement on-chain.
Puis, les points qui m’intéressent : la fonction de renouvellement automatique est vraiment utile. À l’échéance, on trouve un nouveau taux via une enchère Dutch auction, exécutée par un keeper, sans qu’il faille faire des manipulations manuelles. Mais pour savoir si le système est fiable, il faut vérifier si le keeper est suffisamment décentralisé : le nombre d’actifs/participants actifs, le taux d’exécution et d’autres données concrètes constituent réellement la « marge de sécurité ».
Bien sûr, il y a aussi des inquiétudes : le coût du taux fixe, c’est la baisse de la flexibilité. Si on veut sortir en cours de route, il faut vendre les FT sur le marché secondaire : le prix fluctue donc. Et si le collatéral est très volatile, le montant reçu à l’échéance peut aussi ne pas être aussi stable (par rapport aux stablecoins). Ma stratégie à moi est donc de privilégier les actifs courants et les marchés où le taux de collatéral est prudent ; si le rendement est trop élevé, je le considère d’abord comme une prime de risque.
Je suis d’accord avec l’orientation de <#TermMax > : la DeFi manque clairement de rendements déterministes depuis trop longtemps. Mais pour que ça marche vraiment, il faut voir si la demande d’emprunt et la liquidité sont réellement au rendez-vous. Je vais continuer à observer, et on verra quand l’usage réel augmentera.
Et vous, selon vous, la principale raison pour laquelle il est difficile d’adopter des taux fixes on-chain, c’est quoi ?
J’ai relu hier le livre blanc @Dusk , et quand je suis arrivé à la page sur « l’architecture à double VM », je me suis bloqué.
Commençons par l’architecture. Piecrust est une VM à connaissance nulle native, basée sur WASM, avec un règlement ramené à 2–3 secondes. DuskEVM est compatible avec Solidity : Hardhat et MetaMask s’y branchent directement et ça tourne, la confidentialité étant complétée au niveau ZK par Hedger. L’idée de la double voie est intéressante : l’une s’occupe des contrats de confidentialité, l’autre de la compatibilité, chacune son rôle.
Mais plus j’avance, plus je sens que quelque chose ne colle pas. Piecrust a développé sa propre VM ; l’audit AEGIS de ce mois de mars a révélé 39 problèmes, dont 7 critiques. Deux vulnérabilités clés sont bloquées au niveau de la couche sandbox. Même en faisant tourner le même code sur un nœud honnête, les résultats peuvent différer ; un contrat malveillant peut pousser l’exécution dans un état où la garantie de propriété n’est plus valable. Si la sandbox est percée, tous les contrats confidentiels de la couche supérieure sont foutus. DuskEVM, lui, ne prend en charge que les transactions publiques ; la confidentialité dépend d’un module supplémentaire pour faire le travail. Au final, deux VM s’attaquent chacune de leur côté : la taille du code et la surface d’attaque sont doublées.
Regardons ensuite la coopération. NPEX, Chainlink, Cordial, Quantoz, 21X : sur le site, il est indiqué €300M+ en émission confirmée, 50K+ d’accès investisseurs, 210M+ DUSK mis en jeu. Les ressources sont vraiment plus solides que des projets qui ne font que raconter des histoires RWA. Mais même leur propre équipe admet que la tokenisation peut réduire les frictions : elle ne fabrique pas à elle seule des acheteurs, des vendeurs et de la profondeur de marché. Le Dusk Trade est encore en Building/Waitlist, et DuskEVM ainsi que Hedger sont aussi en Testnet. La liste de partenaires montre qu’ils sont prêts à collaborer ; en revanche, pour que ça tourne vraiment, il faudra juger sur des indicateurs concrets : volume d’actifs on-chain, nombre de traders, profondeur sur le marché secondaire, etc.
Enfin, l’articulation entre conformité et confidentialité. Zedger, lors de l’émission, intègre dans le protocole la whitelist, le principe « une identité, un compte », et l’approbation explicite du destinataire : le transfert est découpé en deux étapes, avec annulation automatique en cas de délai. Phoenix utilise une architecture UTXO : les fonds sont stockés sous forme de notes chiffrées ; lors de la transaction, le ZK vérifie simultanément cinq éléments. Les Pedersen Commitments cachent complètement montants et adresses. DuskDS confirme en trois étapes : dès que le bloc est produit, c’est définitif. Les règles portent sur ce qui peut exister, Phoenix gère quels aspects n’ont pas besoin d’être publics, et DuskDS gère quel état fait foi. Ces trois maillons complètent le même point de rupture : de l’émission à la compensation des titres, en évitant autant que possible de devoir revenir hors-chaîne pour recoordiner.
La liste de collaboration est déjà assez « institutionnelle » côté finance. Pour la prochaine étape, je veux surtout voir de vraies données de migration et d’exécution, pas rester uniquement sur des slides. #dusk $DUSK
J’ai longtemps pensé que le recours aux prêts à taux fixe relevait d’un faux besoin. Allez, regardez la volatilité du secteur crypto : qui n’a pas les yeux rivés sur les rendements à court terme en profitant des taux variables ? Au mieux, on met parfois en place un hedge, mais il n’y a vraiment pas besoin de verrouiller un taux. Donc quand le @TermMax est arrivé sur le marché, je disais à un ami qu’en six mois, il allait forcément se transformer.
Puis récemment, j’ai vérifié les données : sur Token Terminal, son nombre d’utilisateurs actifs quotidiens reste autour de 4000, au-dessus de Morpho (3700). Ça m’a poussé à lire sérieusement la documentation.
Et là, j’ai compris : à la base, c’est un « prêt via AMM » — en s’inspirant de l’approche d’Uniswap V3. Le protocole découpe un prêt à taux fixe en trois tokens. Le FT ressemble à un zéro-coupon : il est racheté 1:1 à l’échéance. Le XT, avec le FT, suit le principe : 1 FT + 1 XT correspondent toujours à 1 token de dette ; à l’échéance, le XT retombe à zéro. Le GT est un NFT qui enregistre, pour chaque prêt, le collatéral et la dette. L’emprunteur verrouille son collatéral dans le GT, frappe des FT selon le LTV maximal, puis les vend pour obtenir du cash. Le prêteur achète les FT avec une décote, et à l’échéance, les rachète à la valeur nominale pour empocher l’écart.
La liquidation est encore plus directe : si le LTV dépasse le seuil ou si le prêt arrive à échéance sans remboursement, dans une fenêtre de deux heures, le liquidateur reçoit une récompense de 5 %, et l’emprunteur doit encore payer une pénalité de 10 %. Si personne ne liquide, il y a livraison en nature : le collatéral est remis directement au prêteur, sans robot pour « choper » la liquidation.
Le problème des variations brusques de taux est résolu, mais le risque lié aux fluctuations du prix du collatéral et à la liquidité du marché secondaire, lui, n’a disparu pour aucun compte. Avec les Range Order, les teneurs de marché affichent eux-mêmes des taux par tranches : le pool suit une formule de produit constant, et plus on emprunte profondément, plus le taux s’envole. Le démarrage à froid est vraiment difficile : sans des LP particuliers pour soutenir, tout repose sur des cotations professionnelles qui tiennent à bout de bras.
Maintenant, en regardant le TMX, ne te fixe pas seulement sur le TVL. Les signaux clés, ce sont : la profondeur des transactions des FT à même échéance, l’écart de prix entre prêt et emprunt, et s’il y a des départs groupés juste avant l’échéance. Le taux fixe peut-il survivre ? Tout dépend de savoir s’il y a vraiment des gens qui empruntent en payant « de leur poche » et qui continuent sur la durée, au même prix. #TermMax
#dusk Beaucoup de gens parlent des blockchains publiques, et dès qu’ils ouvrent la bouche, c’est : « TPS », comme si des performances élevées résumaient tout. Mais quand j’ai relu le livre blanc @Dusk , j’ai remarqué un détail intéressant : ils présentent le protocole réseau Kadcast avant même le mécanisme de consensus.
Au début, je n’y ai pas trop prêté attention. En y réfléchissant ensuite, c’est logique : si les blocs candidats, les transactions et les votes ne peuvent pas être transmis, ou s’ils arrivent avec retard, même si le comité choisit ensuite très correctement, on peut tout de même obtenir des forks ou des validations répétées à cause d’une désynchronisation des informations. Dans ce cas, tout le travail en aval devient inutile.
Le protocole Gossip traditionnel, c’est un peu comme crier à tout le monde dans la rue : les messages sont répétés partout, et toute la bande passante part dans de la redondance. Kadcast reprend la distance XOR et la table de routage de Kademlia pour transformer la diffusion en un arbre de multicast structuré : le message suit, par conception, un chemin prédéfini, étape par étape, de façon nette et efficace. Le livre blanc cite des recherches indiquant des économies de bande passante de 25% à 50%, et un taux de blocs « stale » en baisse de 10% à 30%. Bien sûr, ce sont des données de recherche, pas forcément des mesures réelles dans tous les cas. Mais pour une chaîne financière, quelques secondes de latence peuvent faire que différents nœuds voient des blocs candidats différents, ce qui affecte la détermination des transactions.
Le routage structuré a aussi un autre avantage : il rend plus difficile pour des acteurs externes d’identifier directement la source du message. Confidentialité et efficacité sont ainsi conçues ensemble.
Le nœud le plus compliqué de la finance on-chain, c’est le couple « transparence et confidentialité ». Avec une transparence totale, les institutions n’osent pas intervenir ; avec une confidentialité totale, la régulation surveille quand même. Le standard XSC de $DUSK utilise des preuves de connaissance nulle PLONK : on sépare la validité des transactions de leurs détails. Les montants et les contreparties restent confidentiels par défaut ; quand la régulation en a besoin, on utilise des clés de consultation pour une divulgation sélective. Vous pouvez prouver la conformité sans devoir montrer toutes vos cartes.
Le mainnet est déjà en cours de déploiement, et DuskEVM avance également. La collaboration avec la plateforme d’échanges réglementée néerlandaise NPEX aide aussi à transférer de vrais actifs sur la chaîne. La direction technique est très claire, mais il existe bel et bien des pressions au niveau de la circulation des tokens et des changements de liquidité, et parfois la courbe du marché et les fondamentaux se désalignent.
La voie de la RWA conforme est encore longue : l’enjeu clé est de savoir si la gestion des permissions et le déploiement concret pourront suivre les exigences de régulation de différentes régions. La couche de propagation n’a jamais été un rôle secondaire : confidentialité et conformité ne sont pas un choix binaire, il faut les faire avancer ensemble. $DUSK
#TermMax 给的解法很硬核,三代币结构把借贷、杠杆、收益拆分得明明白白。FT像零息债,打折买到期赎;XT对应锁成本;GT管杠杆仓位。再加上Range Order AMM让Curator自己设利率区间,玩得挺细。后来还补了闲置资金去Aave/Morpho生息、提前退出这些功能,能看出来是真在做产品,不是蹭概念。
#TermMax Les discussions autour du sujet récent @TermMax ont soudainement beaucoup augmenté. Tout le monde attend le TGE, et j’ai repris en main son mécanisme. Honnêtement, après avoir pas mal joué avec les prêts DeFi, le plus gros point douloureux n’est pas le niveau de rendement, mais plutôt le caractère trop instable des taux d’intérêt. Taux variable : aujourd’hui 4 %, demain peut-être 9 %. Les emprunteurs n’arrivent pas à contrôler leur coût, et les prêteurs ne peuvent que deviner leur rendement.
La solution proposée par TermMax est assez intéressante : il modifie l’AMM d’Uniswap V3, en transformant la courbe de prix en courbe de taux. Le marché met directement aux enchères, dans un intervalle personnalisé, “combien d’intérêts payer pour emprunter cet argent”. En ajoutant une dimension de durée, le taux ne dépend plus seulement de l’offre et de la demande actuelles : il tient aussi compte du temps d’utilisation. J’ai réfléchi longtemps à sa structure en trois tokens : le FT ressemble à une obligation à coupon nul, acheté à prix réduit puis remboursé à l’échéance ; le XT verrouille le coût d’emprunt ; et le GT est un justificatif de position à effet de levier. La tarification repose sur les Range Orders, et les fonds inutilisés peuvent aussi être automatiquement placés sur Aave ou Morpho pour générer des intérêts. En bref, ce n’est pas une simulation de taux fixe : c’est plutôt un actif échangeable.
Le positionnement produit est très clair : prêts à taux fixe + options. Le slogan tient en trois mots : taux connu, durée connue, risque connu. À l’heure actuelle, l’emprunt et le levier en un clic sont déjà en ligne, avec prise en charge de Pendle PT, d’une partie des RWA et de tokens d’actions. Environ 10 chaînes, TVL de plus de 90 millions. L’activité institutionnelle de Canton Network est également déployée.
Le TGE est fixé au 25 août, avec en parallèle l’ajout sur le Booster de Binance Wallet. Le pool total de récompenses est de 2 millions $TMX. 1,7 million est réservé à un tirage pour 80 000 utilisateurs gagnants, 300 000 pour les 1000 premières publications avant la mise en ligne sur Binance Square. La participation est possible avec ou sans wallet avec clés, et au moins 2 points Alpha. La date limite pour les posts Square est le 21 août à 23:59. Pour les gagnants, n’oubliez pas de valider votre classement : les récompenses seront débloquées au TGE.
Le taux fixe, dans la finance traditionnelle, relève des briques d’infrastructure ; sur la chaîne, créer un actif échangeable n’est pas simple. Côté ingénierie, TermMax a l’air solidement travaillé. Mais la question de la liquidité, la qualité des Curators, et surtout si la demande pourra tenir après le TGE restent à voir. Je vais continuer à surveiller : pas parce que son storytelling est particulièrement sexy, mais parce qu’il fait avancer d’un cran quelque chose de difficile à construire, tout en ayant une valeur durable.
#dusk J’ai remarqué $DUSK pendant plusieurs jours d’affilée. Honnêtement, ce qui m’inquiète le plus n’est pas la hausse ou la baisse, mais cette fine couche de papier qu’est la liquidité. Aujourd’hui, les chiffres sont là : contrats échangés 3,79 millions de dollars, et au comptant à peine un peu plus de 420 000 — 14,27 millions contre 420 000. Ce ratio donne vraiment le tournis. Les ordres sont d’habitude bien rangés, mais si un gros ordre arrive ? Quand les positions sur contrat s’envolent en premier, le comptant ne suit pas ; le slippage, les annulations d’ordres, le prix de référence et le prix réel te percent des trous en un rien de temps. Un volume élevé ne veut pas dire une bonne liquidité ; beaucoup de positions ne veut pas dire que le carnet peut encaisser la pression. On ne le comprend que quand de la vraie volatilité arrive et que tout le monde doit s’en rendre compte.
@Dusk Pour le projet lui-même, moi je m’intéresse davantage à l’autre aspect. Dans leur processus de travail, la vérification de l’investisseur, la liaison du portefeuille, puis la re-vérification lors du transfert — ça a l’air fastidieux, mais en réalité, c’est précisément pour dire clairement « non » à ce qui ne doit pas passer. Si un produit de type valeurs mobilières peut convenir à tout le monde, alors ce n’est peut-être tout simplement pas un vrai produit financier. Nationalité incorrecte, profil d’investisseur pas assez qualifié, période de verrouillage pas encore terminée, outil non autorisé pour la bonne personne : alors la transaction ne devrait pas avoir lieu, même si l’argent a été payé. $DUSK est un token que tout le monde peut obtenir, mais sur NPEX les outils ne sont pas utilisables par n’importe qui ; ces deux choses ne sont absolument pas la même histoire. J’ai vu qu’ils faisaient des démonstrations qui testaient surtout les chemins de refus ; pour ce qui n’a pas été refusé, je me suis dit que je regardais juste un jeu.
Ça me rappelle un ami qui, il y a quelques années, avait acheté des parts de fonds non cotés : pour les revendre, c’était impossible. Trouver un acheteur qualifié, obtenir l’accord de l’émetteur, resigner les documents ; les frais d’intermédiation étaient même plus élevés que la décote. Ses actifs ont dormi pendant trois ans. Dusk met les parts on-chain : les qualifications deviennent vérifiables, les restrictions s’exécutent via du code, et en théorie on n’a plus besoin de contrôles manuels pour transférer. En diminuant la friction, les petits et moyens investisseurs ont enfin une chance d’entrer. Bien sûr, où se trouvent les acheteurs, qui fixe l’évaluation, où aller en cas de litige, et si le dépôt/teneur est reconnu : la chaîne ne peut pas tout résoudre.
En bref : Dusk ne crée pas de sensation à court terme ; l’impact se fera attendre, le temps que la réglementation, la garde (custody) et l’acheteur soient tous en place. Ce genre de projet est le plus facile à critiquer comme « sans progrès », et justement, moi je suis prêt à y donner davantage de patience.
Promenade nocturne dans le verger de loquats, pour assister à un grand banquet de lumières de la ville de montagne 🌙 Dans toute la montagne, les lumières s’allument point par point ; les feux d’artifice s’élèvent, et l’agitation du monde entier se trouve à cet instant. Laissez le vent du soir de la ville de montagne vous caresser et ressentez le romantisme unique des nuits à Chongqing.$BNB $SOL
#dusk Je me suis récemment pris la tête à y réfléchir @Dusk , et plus je regarde, plus je me dis que beaucoup de gens l’ont mal compris dès le départ.
Dès qu’on prononce $DUSK , tout le monde parle directement de cette crypto-monnaie axée sur la confidentialité qui se trouve sur Ethereum. Pas du tout. J’ai pris le temps de fouiller le livre blanc : c’est une blockchain Layer 1 indépendante, avec ses propres nœuds, ses frais de Gas, et même sa couche de règlement entièrement construite en interne. Le fameux ERC-20 que vous voyez sur Etherscan n’est qu’une monnaie « mappée » créée au début pour faciliter les opérations.
Une fois qu’on a compris ça, toute la logique devient soudain évidente. Ce n’est pas une chaîne qui s’acharne à se demander si la piste « confidentialité » est encore à la mode ; elle sert à faire des règlements confidentiels dédiés aux actifs financiers.
Réfléchissez : dans un grand livre entièrement transparent comme Bitcoin ou Ethereum, la vérification est certes simple. Mais comment les grosses institutions font-elles entrer leurs fonds ? Si j’étais gérant de fonds, je réajuste l’allocation, je fais un hedge—et si tous les changements de position se retrouvent exposés dans le mempool pour que tout le monde les observe, ce n’est pas « à découvert » ? Alors, l’anonymat total ne passe pas non plus : l’audit et la régulation bloquent.
Ce nœud mort, Dusk cherche justement à le résoudre. Il utilise Phoenix pour cacher les détails des transactions, Zedger pour traiter les éléments de type valeurs mobilières, et aussi ce module XSC : liste blanche, limites de détention, conditions de transfert—tout est écrit dans le contrat. Les informations sensibles ne filtrent pas, et la partie conformité peut tout de même être vérifiée. À la fin, ça passe par une exécution de consensus pour sceller le tout.
Du coup, maintenant je ne discute plus beaucoup de la question de savoir si la confidentialité est « en vogue » ou pas. Le vrai sujet intéressant, c’est plutôt : si un jour des fonds ou des obligations viennent s’ancrâer sur la blockchain pour faire de la RWA, est-ce que ces institutions auront forcément besoin d’une telle couche de base ?
Le marché a des virages tous les jours, mais les gens capables de se retenir de parler fort tout en construisant une infrastructure financière de fond, ça me paraît au contraire assez intriguant.
#dusk Au début, j’avais rassemblé @Dusk données sans trop y faire attention. Je pensais que c’était juste un projet de mise en gage qui rapporte des intérêts. Mais en regardant de plus près, je me suis rendu compte que ce n’est absolument pas aussi simple : ce n’est pas juste un verrouillage pour toucher des revenus. Pour exécuter un nœud Provisioner, il faut au minimum miser 1000 DUSK, rester en ligne, utiliser le logiciel de version指定, et pour une nouvelle mise, attendre qu’un epoch passe. Il faut à peu près de 6 à 12 heures avant de pouvoir commencer à travailler. Les récompenses ne sont pas non plus un chiffre fixe : elles dépendent de votre participation réelle et du ratio de mise effective. Le plus sévère, c’est le mécanisme de pénalité : si vous perdez la connexion, vous perdez quelques points (de l’argent). Et si vous commettez des fautes ou votez malicieusement, une partie de votre mise est purement et simplement détruite. La conception est intelligente : un rendement élevé attire, mais seuls ceux qui sont prêts à assumer leurs responsabilités peuvent rester.
Ce qui m’a aussi vraiment fait m’arrêter et réfléchir, c’est l’architecture. Ce n’est pas simplement « tout regrouper » : elle sépare les capacités de consensus, d’exécution, de confidentialité et d’identité. DuskDS gère le consensus et la finalité, DuskEVM gère l’exécution, Citadel gère l’identité et la divulgation sélective. Avec cette séparation, les utilisateurs institutionnels n’ont plus à hésiter entre protection de la vie privée et conformité réglementaire : ils peuvent faire les deux.
Ce qui m’a le plus convaincu, c’est son mécanisme de finalité. Le processus en trois étapes de Succinct Attestation est bouclé : l’approbation confirme. D’après le site officiel, il faut environ 10 secondes. Pas de réorganisation de chaîne, pas de problème probabiliste : une fois approuvé, c’est définitivement acquis. Le traditionnel T+2 de la finance, ce n’est pas un problème technique, c’est qu’on n’ose pas aller vite. Ici, l’irréversibilité transforme le « probabiliste » en mécanisme : la notion même de règlement est redéfinie.
Et si l’on regarde sa collaboration avec la bourse réglementée néerlandaise NPEX, ainsi que la boucle de paiement avec le stablecoin en euros EURQ de Quantoz, ce n’est plus juste un test technologique : c’est la volonté de transférer l’ensemble du flux — émission, échange et règlement — de titres réglementés sur la blockchain.
Donc, quand je regarde maintenant $DUSK , je ne me demande plus seulement si la technologie de confidentialité est suffisamment « cool ». Je me demande si tout ce système peut vraiment transformer l’identité, les actifs, les transactions et le règlement en un processus financier exécutable. Bien sûr, la répartition des nœuds, les coûts d’exploitation et les incitations à long terme devront encore être observés. Mais au moins d’un point de vue mécanismes, j’ai l’impression qu’ils construisent un système de sécurité qu’on a intérêt à maintenir collectivement — et pas juste une « vitrine » pour attirer des capitaux.