Rokyo

Je voulais savoir à quoi exactement « Connect Wallet » donne accès une dApp, alors j’ai testé le flux réel sur Dario et Pieswap sur le testnet Dusk. Sur les deux, la première connexion n’a renvoyé que l’ID de profil et le compte public. La fenêtre contextuelle était explicite : « Le site ne pourra utiliser que le compte public du profil sélectionné. » Ce n’est que lorsque j’ai demandé l’adresse de réception protégée (« shielded receive address ») qu’une deuxième étape de consentement est apparue, et c’est seulement alors que la réponse a inclus shieldedAddress. La fenêtre contextuelle a aussi changé, en nommant la « shareable shielded receive address ». Les deux intégrations ont montré la même séquence.

Voici le retournement : je traitais « Connect Wallet » comme un seul événement de permission. Ce n’est pas le cas. Le test contrôlé a séparé l’accès au compte public du partage de l’adresse de réception protégée au moment du consentement.

Cette séparation place une partie de la limite de divulgation minimale dans le flux de consentement du portefeuille, et pas entièrement sur l’utilisateur à gérer. Dans les deux tests, cliquer sur « Connect » seul n’a jamais accordé la portée relative à l’adresse protégée ; une dApp a dû franchir une étape de consentement distincte pour l’obtenir.

J’ai aussi commis une erreur en enquêtant. Je pensais que la chaîne de compte de 132 caractères pourrait laisser entendre un accès protégé. Ce n’est pas le cas. Les deux dApps ont renvoyé le même format de compte en situation de base, tandis que shieldedAddress est restée absente jusqu’à la demande explicite.

Il reste une question non résolue. Une session plus ancienne sur le mainnet Dario a eu un comportement différent, mais je ne l’ai pas reproduite dans les mêmes conditions contrôlées ; je n’en parle donc pas comme d’une fuite. Je peux seulement dire que la limite de permission « publique uniquement » a tenu entre les deux intégrations testnet que j’ai vérifiées, et non que cela est garanti dans chaque environnement.

« Une connexion de portefeuille devrait exposer la portée que vous avez approuvée, pas vous laisser l’inférer. »

Ce que je voudrais voir ensuite : le même test contrôlé sur le mainnet, avec la même version du portefeuille, des permissions propres et une instrumentation identique, pour vérifier si la frontière tient selon les environnements.

#dusk $DUSK @Dusk

J’ai supposé que si je voulais faire trois opérations sur la chaîne — approuver, échanger, puis miser — alors la chaîne traiterait cela comme une seule chose qui arrive ou n’arrive pas du tout. Un sujet ouvert dans le propre dépôt Rusk de Dusk indique que ce n’est pas ainsi que cela fonctionne aujourd’hui.

Une transaction Dusk aujourd’hui transporte une seule opération optionnelle : un appel de contrat, un déploiement ou un mémo, avec une seule valeur, un seul destinataire, un seul nonce et une seule signature. Ainsi, approuver, échanger et miser deviennent trois transactions distinctes, chacune pouvant être incluse ou rejetée indépendamment. L’issue de Dusk le formule clairement : il n’existe aucune garantie d’atomicité entre elles. Approuvez et échangez mais pas misez, et vous vous retrouvez à mi-parcours sans mécanisme de rollback au niveau du protocole.

Le problème ne tient pas seulement au fait que les flux multi-étapes peuvent s’arrêter à mi-chemin. Les corriger change aussi qui doit absorber le coût de compatibilité.

Un contrat batcher rend toute la séquence atomique, car un sous-appel échoué annule la transaction externe. Mais un contrat cible qui vérifie qui l’appelle directement verrait le batcher, pas vous, sauf si ce contrat est déjà écrit pour passer outre l’appelant immédiat. Une transaction batch au niveau du protocole vous maintient comme appelant à chaque étape, mais elle ne s’expédie pas sans un nouveau format de transaction, des changements de consensus, un hard fork, et la mise à jour de chaque SDK de wallet.

Ajouter le batching ne supprime pas le compromis. Cela détermine si le fardeau de compatibilité se situe dans l’autorisation applicative ou dans la pile du protocole.

« La correction de l’atomicité ne supprime pas le compromis ; elle décide où le fardeau de compatibilité et la frontière de confiance se déplacent. »

Ce que j’aimerais en réalité surveiller : si Dusk choisit le batcher au niveau applicatif ou la transaction au niveau du protocole, et quelles hypothèses existantes d’autorisation ce choix force les développeurs à modifier.

#dusk $DUSK @Dusk

I assumed a transaction's meaning was fixed the moment its bytes existed: decode it once, get the same answer everywhere. Dusk's own Rusk changelog for the Boreas upgrade treats that as something that has to be engineered, not assumed.

Boreas added version-aware transaction decoding tied to a specific hardfork, plus hardfork-governed format selection for how old blocks get replayed. The codebase now has two explicitly separate types, CanonicalTransaction and LedgerTransaction, splitting the in-memory representation of a transaction from the format it's actually persisted in on the ledger. There's even a dedicated regression test just for decoding pre-Aegis-era transactions correctly during block serialization.

That only becomes necessary once transaction decoding has to account for different protocol eras and processing stages: fresh off the wire from a client, sitting in memory as a canonical object, replayed from a block that predates the current rules.

Which means a protocol upgrade isn't safe just because new transactions work under the new rules. It's only safe if those new rules don't silently break the ability to correctly replay old ledger state under the rules that produced it. That is the class of version-mismatch failure the historical-replay compatibility and hardfork-gated decoding are designed to prevent.

"A transaction is only reliable if every stage that touches it agrees on what it means."

What I'd actually want to see: a real pre-Aegis block replayed on a current node without changing how its historical transactions are decoded under the applicable rules, not just a passing regression test in isolation.

#dusk $DUSK @Dusk

J’ai supposé que « DuskEVM prend en charge Solidity » signifiait que les développeurs pouvaient arriver avec leurs outils Ethereum existants et en rester là. La propre documentation de démarrage rapide de Dusk ajoute discrètement une étape que la plupart des gens sautent : vérifier le code source.

Déployer est la partie facile. DuskEVM utilise Blockscout comme explorateur, et obtenir la vérification d’un contrat là-bas, « Verify & Publish », signifie que les paramètres de build pertinents, la version du compilateur, la configuration de l’optimiseur, les fichiers source et les arguments du constructeur doivent reproduire l’octetcode réellement déployé.

C’est une exigence différente de la simple compatibilité EVM. Le déploiement prouve que le code peut s’exécuter. La vérification permet à quelqu’un d’autre de contrôler ce qui s’exécute réellement. Un contrat peut être déployé et fonctionner tout en restant non vérifié, laissant les autres incapables de vérifier indépendamment si le code source publié correspond réellement à ce qui est en ligne.

Ce qui signifie que « compatible EVM » et « prêt pour les développeurs » ne sont pas tout à fait la même promesse. L’une concerne le fait de savoir si votre code s’exécute ici. L’autre concerne le fait de savoir si un auditeur, une institution ou un utilisateur peut réellement confirmer que ce qui s’exécute correspond à ce qui est déclaré.

« Une chaîne peut exécuter votre contrat Solidity et vous laisser malgré tout incapable de prouver ce qu’est réellement ce contrat. »

Ce que j’aimerais voir ensuite : si un contrat déployé via le parcours standard Solidity/Hardhat peut être vérifié de manière fiable par rapport à son octetcode déployé, plutôt que simplement déployé avec succès.

#dusk $DUSK @Dusk

Je pensais que la fragmentation était l’essentiel de l’histoire de la liquidité : fractionner un actif en unités plus petites élargit le cercle des propriétaires potentiels. Les propres écrits de Dusk sur la tokenisation pour les PME, publiés cette semaine, disent toutefois qu’il ne s’agit que d’une partie limitée du tableau, et une étude académique indépendante portant sur des actifs tokenisés réels montre pourquoi cet écart compte.

Dusk le dit clairement : « la propriété fractionnée joue un rôle limité. Des unités plus petites ne peuvent pas créer une demande d’investisseurs, une sécurité juridique ou de la liquidité ». La valeur, soutiennent-ils, provient du fait de relier le titre à des opérateurs responsables, à des acheteurs éligibles, à des paiements et règlements fiables, et à un site autorisé—et non de la finesse de sa découpe.

Une étude de 2023 publiée dans Financial Innovation a testé quelque chose de très proche, sur la base de 58 propriétés résidentielles tokenisées réelles aux États-Unis. En matière de propriété, les résultats étaient nets : la propriété moyenne comptait 254 propriétaires distincts. En revanche, pour le trading, le tableau était différent. Les parts ont changé de mains environ une fois par an en moyenne ; les propriétés échangées sur des bourses décentralisées étaient plus souvent cédées que celles négociées de pair à pair, même si, dans tous les cas, la base annuelle restait faible.

Cela signifie que les deux affirmations que les gens confondent—« cet actif est fractionné » et « cet actif est liquide »—décrivent en réalité deux choses différentes. La fragmentation est une propriété du token. La liquidité est une propriété du marché qui l’entoure.

« Une unité plus petite peut élargir qui est autorisé à posséder quelque chose, sans créer un marché où l’on peut réellement le négocier. »

Ce que je surveillerais à mesure que des actifs liés à NPEX arrivent chez Dusk : non pas la finesse de leur fragmentation au moment de l’émission, mais la persistance effective du trading secondaire après coup—le même écart que l’étude portant sur les 58 propriétés a mis en évidence entre une propriété largement répartie et une négociation active.

#dusk $DUSK @Dusk

Je pensais qu’un piratage du pont signifiait que quelqu’un avait trouvé un bug dans le code, une faille dans la cryptographie, quelque chose qu’un audit de sécurité avait manqué. Le propre rapport post-mortem de Dusk sur son incident de pont de janvier décrit autre chose.

Le 16 janvier, un attaquant a compromis un portefeuille de signature utilisé par le pont Dusk vers EVM, déplaçant des fonds directement sur Dusk avant d’acheminer une partie de ceux-ci vers la BNB Smart Chain. Dusk a arrêté le pont en plein milieu de l’attaque, ce qui a provoqué l’échec d’une dernière tentative de transfert d’environ 8,9 millions de DUSK.

Il ne s’agissait ni d’un échec du consensus, ni d’une exploitation du protocole. Dusk indique que la cause directe était une compromission de clé, et que l’ancienne conception permettait au portefeuille de signature, à la gestion des événements et à la connectivité réseau de fonctionner tous dans un seul et même chemin. La faiblesse était concentrée dans l’autorité opérationnelle, et non dans une cryptographie faible.

La refonte qui a suivi se résume à une phrase enfouie dans le post-mortem : « l’ingestion n’est désormais plus équivalente au fait de dépenser ». Autrefois, constater qu’un événement s’était produit et avoir l’autorité de libérer des fonds à cause de cela correspondaient à la même étape. Désormais, ce n’est plus le cas. L’ingestion d’événements est mise en file avec des points de contrôle, sous forme de tâche ; un processus séparé, explicite, déplace réellement les fonds en fonction de celle-ci.

« Un protocole peut fonctionner comme prévu, tandis que la couche opérationnelle qui l’entoure donne à un chemin compromis une autorité excessive. »

Ce que j’aimerais réellement voir : une confirmation que le pont remanié conserve bien, dans la pratique, l’ingestion d’événements et la libération des fonds sur des chemins séparés, et pas uniquement dans la description de la nouvelle architecture fournie dans le post-mortem.

#dusk $DUSK @Dusk

I assumed a fixed-rate loan on TermMax meant one number: whatever you borrowed, that's the fixed amount you eventually hand back. That's not the whole picture.

Here's the mechanic. When a borrower takes a loan, they receive debt tokens and can repay by returning that exact face value. But TermMax also lets them buy back FT, the token representing that same debt, from the open market instead. FT can trade below face value before maturity, and TermMax's worked example illustrates how that can lower the repayment cost. In that example, a borrower who owes 800 FT can buy them back at $0.80 each and settle the debt for $640, instead of repaying $800 directly. Same obligation, two different prices to close it.

That's not a rounding difference. It's a 20% gap between the contractual repayment amount and what closing the position can actually cost, depending on where FT happens to be trading that day.

Here's what that reveals: the same FT token is simultaneously the lender's fixed-income claim held until maturity, and the borrower's tool for settling debt early. The debt isn't a number that sits still between origination and maturity. It can have a market price before maturity, and that market price can move independently of the rate quoted at origination.

One caveat worth naming: TermMax's own documentation uses this 20% figure as a worked example, not a guaranteed market condition. FT's actual discount moves with market conditions and won't always be that wide.

So which number should actually define a "fixed-rate loan": the rate you locked in at origination, or the market price of the instrument you'd need to buy to close it?

#termmax @TermMax

J’ai supposé que « liquidated » sur TermMax signifiait qu’une position était simplement clôturée une fois qu’un liquidateur intervenait. Ce n’est pas tout à fait comme ça que ça fonctionne pour les positions plus importantes.

La liquidation se déclenche lorsque le LTV d’un prêt dépasse le seuil LLTV, ou lorsque l’emprunteur manque le remboursement à échéance fixe, ouvrant une fenêtre de liquidation de deux heures. Mais il y a un plafond intégré au mécanisme lui-même : si la dette en cours dépasse 10 000 $, un liquidateur ne peut liquider que jusqu’à 50 % de la valeur totale de la dette lors de ce passage.

Donc, pour une position suffisamment importante, la contrainte n’est pas forcément de savoir si un liquidateur veut agir. Le protocole lui-même n’autorise pas une seule liquidation à régler l’ensemble.

Cela change ce que signifie « liquidated partiellement ». Ce n’est pas nécessairement la preuve que la demande de liquidation était trop faible ou que le marché a bougé trop vite. Cela peut être une conséquence attendue du mécanisme lui-même. Et si le prêt n’est toujours pas payé ou n’est que partiellement liquidé lorsque cette fenêtre de deux heures se referme, la livraison physique commence automatiquement.

La taille d’une position ne fait pas qu’influencer le montant en risque. Elle peut aussi influer sur la question de savoir si le processus de liquidation peut résoudre entièrement la position dans la fenêtre dont il dispose.

Alors faut-il juger l’efficacité de la liquidation en fonction de la présence d’un liquidateur, ou en fonction de la quantité de la position que le mécanisme peut effectivement résoudre avant que la fenêtre ne se referme ?

#termmax @TermMax

Réponses KYC pour ceux qui remplissent les conditions lors de l’onboarding. Les contrôles de transfert répondent à qui est encore éligible lorsque l’actif change de main. Le modèle propre à l’infrastructure de marché de Dusk traite ces éléments comme deux étapes distinctes, et c’est cet écart qui est intéressant.

Dusk liste l’onboarding des investisseurs, « lier des portefeuilles à des participants ou des identifiants vérifiés », séparément des contrôles de transfert, « imposer qui peut détenir ou transférer l’actif ». L’un établit un état d’éligibilité initial. L’autre est ce qui rend cet état applicable lorsque l’actif est réellement transféré.

Le matériel XSC plus ancien va plus loin que l’onboarding : les émetteurs peuvent mettre des portefeuilles sur liste blanche et conserver des contrôles au niveau de l’actif, comme le gel ou le transfert forcé. Cela compte, car l’éligibilité n’est pas seulement établie une fois. Elle doit rester applicable après la décision initiale.

Ce qui signifie que « KYC validé » et « éligible à détenir cet actif » sont deux affirmations différentes qui peuvent diverger discrètement. Un portefeuille peut rester vérifié au sens de l’identité, tout en n’étant plus le type de détenteur que cet actif précis est autorisé à avoir. L’application de la conformité ne s’arrête pas à l’onboarding ; elle doit se poursuivre dans tout le cycle de transfert de l’actif.

« Réussir un contrôle de conformité et rester éligible sont deux affirmations différentes. »

Cela modifie la question d’évaluation réelle. Ce n’est pas « cet actif dispose-t-il de contrôles d’éligibilité ». La vraie question est de savoir si l’état d’éligibilité actuel est appliqué lorsque l’actif est transféré, ou si le statut d’onboarding initial est simplement reconduit.

Ce que je voudrais réellement voir : un portefeuille dont l’éligibilité change après l’onboarding, par exemple en cas de changement de juridiction, tout en continuant à détenir l’actif, puis une tentative de transfert, et vérifier si la logique de transfert de l’actif détecte ce changement.

#dusk $DUSK @Dusk

J’ai supposé qu’un « marché à taux fixe » signifiait un seul taux : vous connaissez le taux avant d’effectuer la transaction, point. En regardant de plus près comment TermMax fixe réellement le prix d’un prêt, cette hypothèse ne tient pas.

Les taux ne sont pas cotés comme un simple nombre. Ils sont définis via des courbes. Dans un Lending Range Order, la courbe peut commencer à un taux plus bas et monter par paliers à mesure que davantage de l’ordre est exécuté, un peu comme une AMM qui traverse différents niveaux de prix au lieu d’offrir un seul prix. Un marché peut contenir plusieurs range orders en même temps, de sorte que différents participants peuvent être exécutés à différents points de la courbe.

C’est cette distinction que j’avais manquée : le marché n’a pas un unique taux fixe. Chaque position exécutée obtient un taux fixe déterminé par l’endroit où son exécution se place sur la courbe. Une fois exécuté, ce taux reste fixe pendant toute la durée.

Et la courbe n’est pas non plus arbitraire à l’exécution. Les actions du Curator s’inscrivent dans des contraintes du protocole, comme des marchés autorisés (whitelisted) et des changements temporisés (timelocked).

Ainsi, quand TermMax appelle cela un « marché à taux fixe », la question intéressante n’est pas simplement : quel est le taux fixe ? C’est plutôt : quelle part de ce taux est déterminée par la courbe, et quelle part dépend de l’endroit précis où votre liquidité est effectivement exécutée ?

#termmax @TermMax

Demandez à la plupart des personnes qui évaluent une chaîne de confidentialité si elle est privée, et elles cocheront une case : oui ou non. Pour Dusk, c’est la mauvaise question, et la présentation de Dusk sur Hedger l’explique.

Zedger, le protocole natif de confidentialité préservée de Dusk, peut offrir une anonymat total. Hedger, conçu pour DuskEVM, ne le peut pas. Dusk le dit clairement : le modèle de comptes de l’EVM empêche un anonymat complet, tandis que Hedger conserve les détails des transactions chiffrés grâce au chiffrement homomorphe et à des preuves à divulgation nulle (zero-knowledge), sans fournir la même garantie d’anonymat total.

Ce n’est pas un bug que Dusk cache. C’est un compromis que l’architecture rend explicite : la compatibilité EVM s’accompagne d’une garantie de confidentialité différente de celle de l’anonymat total de Zedger.

Voici ce qui change réellement quand ce compromis est fait. La différence importante n’est pas simplement de savoir si les détails des transactions sont chiffrés. C’est la garantie d’anonymat. Utilisez la voie Zedger, et un anonymat total est disponible. Utilisez la voie Hedger compatible avec l’EVM, et la même garantie n’est pas offerte. Même marque, même mot « confidentiel », garantie différente en dessous.

Cela change la question réelle que devrait se poser toute personne qui évalue ce sujet. Pas « Dusk prend-il en charge les transactions confidentielles ? ». Les deux voies prennent en charge des flux de transactions privées, mais elles n’offrent pas la même garantie d’anonymat. La vraie question est de savoir si la garantie qu’un actif réglementé obtient correspond réellement à ce dont son workflow a besoin.

« Une confidentialité qui maintient les détails des transactions confidentiels et une confidentialité qui fournit un anonymat total sont deux garanties différentes, même quand un projet publie les deux sous le même mot. »

Ce que je voudrais réellement voir : quelle voie de confidentialité un titre réglementé utilise en pratique au sein de Dusk Trade, et quelles exigences de workflow obligent cette voie à rester cachée.

#dusk $DUSK @Dusk

J’ai supposé que faire du staking sur une blockchain PoS signifiait une clé qui contrôle tout : on met DUSK, on récupère des récompenses, et la même clé gère l’ensemble de bout en bout.

Les propres documentations de Dusk découpent cela en deux.

La clé de consensus est la clé qu’un nœud utilise pour signer et voter dans le consensus. Elle doit résider sur un nœud connecté à Internet et participer au fonctionnement du validateur. La clé propriétaire est distincte : c’est la clé qui permet de retirer le staking (unstake) ou de retirer les fonds, et la documentation indique qu’elle n’a pas besoin de toucher le nœud du tout.

Le bénéfice sécurité ne se limite donc pas au fait qu’il y ait deux clés. L’idée est que l’autorité pour participer au consensus et l’autorité pour retirer les fonds n’ont pas besoin de résider au même endroit. Si la clé de consensus est compromise parce que le serveur sur lequel elle se trouve a été violé, un attaquant peut perturber la participation au consensus, mais il ne peut toujours pas unstake ni retirer le stake. Cette autorité n’a jamais existé sur la machine exposée à Internet en premier lieu. Autrement dit, la vraie question de sécurité n’est pas seulement le montant staké. C’est où l’autorité de retrait se situe réellement par rapport à la machine exposée aux attaques.

Mais il y a un piège que la documentation ne cache pas : cette séparation n’est pas le paramètre par défaut. Si vous stakez sans préciser un propriétaire distinct, la clé de consensus devient automatiquement la clé propriétaire aussi, une seule clé, une seule frontière, retour au modèle que je supposais au départ. Le configuration plus sûre est un choix que l’opérateur doit faire activement, pas quelque chose que le protocole lui impose.

« Une frontière de sécurité qui doit être choisie (activement) n’offre pas la même garantie qu’une frontière intégrée au chemin par défaut, même si les deux sont techniquement disponibles. »

Ce que j’aimerais savoir concrètement : combien de provisionneurs actifs fonctionnent avec une clé propriétaire distincte par rapport au paramètre par défaut, car cela me dirait si la frontière plus forte est réellement adoptée, plutôt que simplement disponible.

#dusk $DUSK @Dusk

J’ai supposé qu’une position à terme fixe verrouillée signifiait exactement cela : verrouillée, point final, jusqu’à l’échéance. Puis j’ai découvert le Smart Unwind de TermMax et j’ai supposé qu’il résolvait simplement ce problème. Mais ce n’est pas comme je m’y attendais.

Le Smart Unwind ne retire pas la liquidité de sortie d’un pool. Il fonctionne en rendant votre position suffisamment attrayante pour que quelqu’un d’autre ait envie de la reprendre à sa place. Un levier (leverager) fixe un objectif de taux APR ou de prix. Si la valeur du collatéral augmente suffisamment, un arbitragiste achète la position à ce prix fixe et vend le collatéral sur le marché ouvert pour réaliser un profit. Si les taux d’emprunt augmentent, un nouvel investisseur peut reprendre la position avec une prime plutôt que d’en ouvrir une nouvelle.

Donc, le protocole ne garantit pas la sortie. La sortie dépend du fait que quelqu’un d’autre trouve la transaction suffisamment attrayante pour la prendre.

C’est la partie que je n’avais pas envisagée : les conditions dans lesquelles un levier veut le plus sortir—un prix du collatéral en baisse ou un marché sous tension—pourraient être précisément celles où un arbitragiste n’a aucune hausse à capter et où un nouvel investisseur n’a aucune raison de reprendre une position perdante. Le mécanisme pourrait fonctionner au mieux exactement quand vous en avez le moins besoin, et se faire discret exactement quand vous en auriez besoin.

Le Smart Unwind n’est pas encore en direct non plus, donc tout ceci n’est pas encore un comportement observé ; c’est uniquement ce que la conception implique.

Un mécanisme de sortie qui dépend de l’incitation de quelqu’un d’autre résout-il vraiment l’illiquidité des positions à terme fixe, ou fait-il simplement déplacer le même problème vers la personne qu’il faut trouver de l’autre côté ?

#termmax @TermMax

J’ai dépassé l’étiquette de « prêt à taux fixe » de TermMax pour voir ce qui se passe réellement en dessous.

Le produit ressemble moins à un pool de prêt avec un APY fixe et ressemble davantage à un marché onchain de revenus fixes. Son FT est un token de type obligation à coupon zéro : les prêteurs l’achètent en dessous de sa valeur nominale et le rachètent au pair à l’échéance, avec un rendement fixé à l’entrée. Cela change ma façon de voir le produit : le taux fixe n’est pas seulement un paramètre d’un pool de prêt. Il est intégré dans une créance limitée dans le temps.

En janvier, le même modèle à taux fixe s’est étendu au-delà des collatéraux natifs de la crypto pour inclure des titres tokenisés, avec le lancement d’emprunts à taux fixe sur les actions tokenisées d’Ondo Global Markets.

Un taux fixe élimine l’incertitude sur le taux sur la durée. Il n’élimine pas le besoin de refinancer lorsque la période arrive à échéance. TermMax propose déjà un rollover en un clic, soit vers une échéance fixe ultérieure, soit vers les marchés à taux variable de Morpho : le protocole a donc explicitement conçu pour cette étape de refinancement. Ce qui est bien documenté, c’est l’architecture ; ce qui manque, ce sont des données sur la façon dont ce parcours se comporte lorsque de nombreuses positions doivent se renouveler simultanément sous contrainte.

Avec plus de 90 M$ de TVL sur 10 chaînes EVM et le TGE du $TMX fixé au 25 août, c’est la partie que je surveillerais ensuite.

#termmax @TermMax

Je m’attendais à ce que les « contrôles d’éligibilité » derrière Dusk Trade soient quelque chose conçu spécifiquement pour le trading. Un module de conformité fixé à la couche d’échange, comme la plupart des courtiers intègrent la KYC directement dans la plateforme.

Mais ce n’est pas ce qu’il y a en dessous.

La couche d’identité sur laquelle Dusk Trade s’appuie s’appelle Citadel, et elle n’a pas été pensée à l’origine comme une fonctionnalité de trading. Dusk l’a lancée en janvier 2023 en tant que protocole de KYC/identité à connaissance nulle : prouver que vous détenez un justificatif valide sans révéler son contenu, puis réutiliser cette preuve entre différents services plutôt que de resoumettre vos données à chaque fois.

Ce calendrier change la manière dont je lis « contrôles d’éligibilité » dans la documentation. On a moins l’impression qu’il s’agit d’une conformité sur mesure construite pour un seul produit, et davantage celle d’un principe d’identité qui existait avant le produit qui l’utilise.

Le point intéressant, c’est que Citadel a été conçu pour des prestataires de services au-delà d’un simple scénario de trading. Dusk l’a décrit comme une couche d’identité que les entreprises peuvent exploiter pour vérifier si quelqu’un remplit ses critères, sans prendre la garde de toutes les données d’identité sous-jacentes.

« Un contrôle d’éligibilité conçu pour un produit et une couche d’identité conçue pour survivre au produit sont deux types d’infrastructure différents, même lorsque les utilisateurs vivent les deux comme “prouvant qui vous êtes”. »

Ce que j’aimerais voir concrètement : un justificatif prouvé via Citadel et accepté par un autre prestataire de services en dehors de Dusk Trade — la preuve que transforme « principe d’identité partagé » d’une description d’architecture en réutilisation interservices démontrée.

#dusk $DUSK @Dusk

J’ai compris que « Dusk s’associe avec Chainlink » voulait dire le pitch habituel. Un pont. Des tokens qui circulent entre chaînes. La traditionnelle histoire d’interopérabilité que chaque projet finit par annoncer.

C’est une partie de l’histoire, mais pas la plus importante.

Annoncé en novembre, l’accord associe Chainlink CCIP — la couche d’interopérabilité — aux titres tokenisés de NPEX, avec une contrepartie facile à passer sous silence : Chainlink DataLink devient l’oracle de données onchain exclusif de NPEX. Pas un des multiples flux de prix. Le flux exclusif. Le même accord permet aussi à DUSK elle-même de passer nativement d’Ethereum à Solana via la norme CCT de Chainlink, ce qui donne aussi au token l’histoire du pont.

Neuf mois plus tard, c’est cette partie-là qu’il faut distinguer. CCIP permet à un actif de circuler à travers les écosystèmes. DataLink fournit les données de marché de NPEX dont le système récepteur peut se fier. L’un parle de la portée. L’autre, de qui a le droit d’être cru. Toute chaîne qui consomme ces données de NPEX construit à partir de la même source officielle de données de marché.

Je ne pense pas que ce soit automatiquement un défaut. Les marchés réglementés dépendent déjà de sources de données de marché faisant autorité. Mais cela signifie que, ici, la composabilité inter-chaînes n’est pas une infrastructure entièrement neutre. C’est une composabilité construite autour d’une source exclusive des données de marché officielles de NPEX, quel que soit l’endroit où ces données seront lues ensuite.

« Être capable de faire circuler un actif entre les chaînes et être la source exclusive de ses données de marché officielles sont deux formes de pouvoir différentes, même quand un seul accord en confère les deux. »

Ce que j’aimerais vraiment savoir, neuf mois plus tard : que se passe-t-il sur les autres chaînes si cette source exclusive de données de NPEX devient indisponible ou fait l’objet d’un litige, et est-ce que « composable » signifie discrètement « dépendant d’une seule ligne exclusive qui revient à NPEX ».

#dusk $DUSK @Dusk

Je pensais que la tokenisation et l’émission native étaient essentiellement deux façons de déposer un actif on-chain. La page de comparaison de Dusk a changé ce cadrage. Ce ne sont pas deux degrés de la même chose. Ce sont deux architectures entièrement différentes.

Selon la définition même de Dusk, la tokenisation émet un token représentant un actif ou une créance sur celui-ci, tandis que l’actif sous-jacent peut rester rattaché aux processus de garde, d’enregistrement et de règlement qui étaient déjà en place hors chaîne. Le token est une représentation, pas l’actif sous-jacent lui-même. L’émission native supprime cette couche : l’actif existe on-chain en tant que tel, et son cycle de vie—émission, transfert, service, règlement—n’a pas besoin d’un enregistrement distinct quelque part pour faire le lien avec une source de référence ailleurs.

Le hic, c’est qu’un token peut encore dépendre d’un autre système pour rester la véritable source de vérité. Si cet enregistrement hors chaîne accuse du retard ou tombe en panne, la garantie du token n’est aussi solide que la réconciliation qui la sous-tend.

C’est là que tout devient conditionnel. La comparaison de Dusk indique que l’émission native peut réduire la dépendance à des couches distinctes de garde et d’enregistrement, « selon la structure juridique ». Cette réserve fait l’essentiel du travail dans cette thèse. Le cas d’efficacité ne vient pas du seul fait que la technologie existe. Il dépend du fait que la structure juridique permette réellement au registre on-chain de porter ce poids, plutôt que de rester juste une autre copie de la source réelle.

« Un token qui représente un actif et un actif qui existe en tant que token sont deux promesses différentes, même lorsque les deux sont commercialisés comme de la tokenisation. »

Ce que j’aimerais en réalité voir avant d’affirmer que c’est du “vrai” : une sécurité réglementée où l’enregistrement faisant foi réside on-chain, et non une couche de règlement fonctionnant en parallèle avec un registre qui conserve encore le dernier mot.

#dusk $DUSK @Dusk

Je me suis surpris à regarder l’explorateur du testnet de DuskEVM, et le chiffre qui saute aux yeux — 845 113 transactions contre 282 adresses de portefeuille — est presque celui sur lequel il ne faut pas se concentrer. Cela fait à peu près 3 000 transactions par adresse : un ratio qui en dit moins sur l’adoption que le titre ne le suggère.

Les deux transactions les plus récentes affichaient une valeur de 0 DUSK : frais payés, sans valeur native transférée. Le flux le plus récent était étiqueté comme un dépôt L1→L2. Ce n’est pas la preuve de ce que ressemblent les autres 845K transactions, mais c’est suffisant pour me faire arrêter de lire ce chiffre comme un seul nombre. Ce que l’explorateur montre d’abord, en réalité, c’est l’activité réseau : la chaîne qui traite des transactions. Qu’il s’agisse d’une activité économique, ou de la façon dont une valeur change réellement de mains pour une raison donnée, est une question distincte que le simple nombre de transactions ne peut pas trancher à lui seul.

Cette distinction compte, parce que Dusk positionne au final cette infrastructure pour des actifs financiers réglementés — exactement ce que le plan de Dusk visant à faire entrer 300M€ d’actifs NPEX onchain devra éventuellement permettre de démontrer. Une chaîne très sollicitée, et une chaîne qui transporte un volume réel de règlement, peuvent produire une page de statistiques au visuel identique.

« L’activité réseau n’est pas la même chose que l’activité financière, même quand les deux se résument à un seul chiffre sur un explorateur. »

Ce que j’observerais réellement comme signal du passage de l’activité réseau à l’usage financier : quelle part représente une valeur économique effective réglée, une fois que NPEX nous aura fourni quelque chose de concret à quoi la comparer.

#dusk $DUSK @Dusk

Le propre texte de Dusk sur Hedger met la génération de preuves côté client à moins de 2 secondes. Lisez-le deux fois avant que ça ne s’installe. C’est assez rapide pour que « confidentiel doit forcément être plus lent » cesse de ressembler à une hypothèse sûre. J’ai donc creusé pour comprendre ce qui est réellement prouvé aussi vite. Le testnet public de DuskEVM est en ligne depuis décembre, et il y a quelques jours, la Dusk Foundation l’a ouvert aux tests Solidity et Hardhat — c’est la mise à jour dont je lisais en fait. La phrase qui m’a arrêté : l’éligibilité est vérifiée avant l’accès ou le transfert. Je pensais au départ que c’était la partie de conformité la plus intéressante. Je l’ai laissée ouverte dans un onglet pendant que je prenais mon café, je suis revenu, je l’ai relue et je me suis rendu compte que ce n’était pas ça. Dusk dit que les données des participants, les soldes et les montants de transfert peuvent rester chiffrés. C’est vraiment ça qui m’a accroché : l’écart entre prouver qu’on est autorisé et révéler ce qu’on transporte une fois qu’on l’est. L’étape d’éligibilité est conforme à la documentation : elle est clairement définie, pas juste une allégation de conformité vague. Je n’ai malgré tout pas trouvé d’exemple concret de ce qu’un réviseur autorisé voit réellement quand ce parcours d’audit est utilisé. J’ai relu la documentation deux fois. Quelques jours après l’ouverture de Solidity/Hardhat, je me demandais si cet exemple apparaît à mesure que ça mûrit, ou si « auditabilité » reste simplement le mot que personne n’a encore besoin de démontrer — ici ou sur n’importe quelle chaîne qui fait la même promesse.

#dusk $DUSK @Dusk

J’ai ouvert le graphique de BABY ce soir pour voir combien de jours il restait avant le déblocage, et ce qui n’a pas particulièrement attiré l’attention, ce n’est pas le compte à rebours.

10 août. Cinq jours restants. 136,11 M de tokens, environ 1,43 M$, 1,2 % de l’offre, principalement destiné à l’équipe, aux conseillers et aux investisseurs des premiers tours — les mêmes chiffres que n’importe qui qui suit déjà le dossier connaît.

Ce que je n’avais en réalité pas regardé, c’étaient les sept jours qui précèdent.

En ce moment, BABY baisse d’environ 10,3 % cette semaine. Le prix tourne autour de 0,0105 $, la capitalisation boursière est proche de 45 M$, et le titre sous-performe le marché crypto plus large, qui, lui, est essentiellement stable sur la même période.

Ma première lecture était : d’accord, c’est forcément lié à des ventes liées au déblocage qui commencent tôt.

Peut-être pas. Il peut s’agir de conditions plus larges du marché qui n’ont rien à voir avec le 10 août. Je n’ai pas de moyen de distinguer « des gens qui devancent le déblocage » de « BABY qui passe une mauvaise semaine, comme le reste ».

Quoi qu’il en soit, les tokens qui atterrissent dans ces portefeuilles le 10 août arrivent à un prix déjà en baisse de 10 % par rapport à la position d’il y a une semaine.

Celui qui a vendu cette semaine a vendu pendant cette chute. Celui qui reçoit le déblocage vend dans ce qu’il reste après.

Deux côtés des mêmes cinq jours, qui absorbent différentes moitiés du mouvement.

Je ne sais pas si ce schéma se vérifie cette fois-ci. Rien de ce que j’ai lu ne détaille quelle part des déblocages passés de Babylon était déjà intégrée avant, versus ce qui a été réagi après.

Si le prix avait déjà bougé avant que le déblocage n’ait lieu, que révèle encore le jour même du déblocage ?

@BabylonLabs_io #baby $BABY