比特发发发

#dusk $DUSK Ces derniers temps, je calcule un compte de $DUSK : si j’achète maintenant 10 000 unités de DUSK pour exécuter moi-même un Provisioner, ou si je confie la même somme en délégation aux cinq nœuds les mieux classés, de combien l’écart de rendement attendu sera-t-il au bout de trois ans ?
D’abord, regardons l’exécution en solo. Le seuil du Provisioner pour @Dusk est de 1 000 DUSK, mais pour être sélectionné de façon stable par le comité, il faut en pratique au moins 5 000 à 10 000 DUSK mis en garantie. Le coût du serveur est de 250/mois ; sur trois ans, cela fait 250/mois, 3 ans, soit 9 000. En plus, il y a la fluctuation du prix du DUSK : si le prix baisse de 30 % à partir d’aujourd’hui, ton capital se contractera plus que le gain de rendement sur trois ans. Mais si le DUSK augmente, les revenus du nœud que tu exécutes te reviennent entièrement, sans commission prélevée.
Ensuite, la délégation. Dans le mécanisme de délégation de #dusk, le Provisioner prélève une commission — actuellement, les nœuds en tête prélèvent généralement 5 % à 10 %. Sur trois ans, l’effet de la capitalisation peut faire que cette commission « mange » jusqu’à 20 % à 30 % du rendement total. Mais l’avantage, c’est que : tu n’as pas à gérer l’exploitation et la maintenance du serveur, tu n’as pas à surveiller les Soft Penalty, et tu n’as pas à t’inquiéter des fluctuations du réseau pouvant entraîner un échec de signature. Tu achètes une tranquillité d’esprit.
Mais il y a encore un autre facteur : le Schedule d’émission du DUSK. Si, au cours des trois prochaines années, le taux d’inflation du DUSK diminue progressivement (c’est la tendance de la plupart des chaînes PoS), la récompense par bloc du Provisioner baissera, mais la part des revenus provenant des frais de transaction augmentera. Les revenus de frais sont directement liés au volume de transactions de titres sur NPEX — si une tokenisation de titres de 200 M€+ finit vraiment par fonctionner, la hausse des frais pourrait largement dépasser les pertes dues à la baisse de l’inflation.
Donc, la conclusion de ce calcul dépend d’une hypothèse clé : crois-tu que l’activité économique réelle sur DUSK continuera de croître ? Si tu y crois, exécute toi-même ; si tu n’y crois qu’à moitié, délègue. @Dusk

#dusk $DUSK Aujourd’hui, je lis le document sur le modèle de transactions au @Dusk . Je pensais au départ que Dusk était une « blockchain de confidentialité » — toutes les transactions seraient anonymes par défaut, comme Monero ou Zcash. En fait, dans DuskDS, deux modèles de transactions tournent en parallèle : Moonlight est public et basé sur un système de comptes ; Phoenix est masqué, basé sur un modèle UTXO + preuves à divulgation nulle (zero-knowledge). Les deux modèles utilisent le même token $DUSK et passent par le même contrat Transfer.
Dès le début, cette conception m’a semblé contradictoire : pourquoi une blockchain de confidentialité garderait-elle un modèle public ? En y réfléchissant, je me rends compte que la présence de Moonlight sert justement à la conformité. Dans la finance traditionnelle, lors des transactions, les exigences de la réglementation imposent de pouvoir consulter les soldes des comptes et l’historique des transactions. Sur une blockchain totalement privée, les auditeurs ne peuvent même pas consulter les écritures, ce qui empêche de franchir les barrières de conformité. Moonlight fournit une expérience transparente semblable à celle d’un compte bancaire traditionnel — adresse de compte, solde, et historique des transactions.
Phoenix emprunte une autre voie : modèle UTXO + preuves à divulgation nulle. Le montant des transactions et les participants peuvent être cachés, mais l’auditeur qui possède la View Key peut néanmoins consulter ce qui a été fait. C’est comme des livres de comptabilité d’entreprise : à l’extérieur, on publie un résumé des rapports annuels ; les auditeurs, eux, avec la clé, peuvent voir les détails.
Je fais une analogie : ce n’est pas comme s’il n’y avait qu’une seule route où l’on choisit soit « tout transparent », soit « tout anonyme », mais plutôt comme un immeuble qui a à la fois une salle de réunion vitrée et une salle de discussion insonorisée. Pour la divulgation externe et les déclarations de conformité, on utilise la salle vitrée (Moonlight) ; pour les négociations commerciales et les règlements entre institutions, on utilise la salle insonorisée (Phoenix). Dans le même immeuble, différents contextes donnent accès à différentes pièces.
Cependant, les deux modèles ajoutent aussi de la complexité. Les utilisateurs doivent transférer manuellement des comptes entre Moonlight et Phoenix pour DUSK, et il n’y a pas encore d’acheminement automatique. Si un dApp ne supporte que Moonlight, les utilisateurs détenant des actifs masqués via Phoenix doivent d’abord effectuer un transfert inter-modèles : c’est une étape supplémentaire, et une transaction en plus avec du gas.
Donc, en regardant le système de comptes associé à #dusk , mon intérêt ne porte pas seulement sur « y a-t-il de la confidentialité », mais aussi sur ce que les développeurs et les utilisateurs privilégient réellement dans l’usage quotidien, et sur la question de savoir si la friction liée aux transferts inter-modèles peut être absorbée au niveau du wallet. L’efficacité de circulation de $DUSK dépend, au final, du coût de basculement entre ces deux modèles. @Dusk

#dusk $DUSK Aujourd’hui, j’ai démonté le protocole d’accord (SA) de @Dusk , et je suis bloqué sur un mot : « committee-based ». Beaucoup de chaînes PoS utilisent un mécanisme de comité, mais le SA de Dusk — Succinct Attestation — suit une approche en trois étapes : proposition, vérification, approbation, avec à chaque fois des provisioners tirés au hasard différents qui exécutent l’étape.
Première étape : un provisioner crée et diffuse un bloc candidat. Deuxième étape : un comité de vérification examine la validité du bloc. Troisième étape : un autre comité d’approbation confirme le résultat de la vérification et finalise finalement le bloc. À première vue, cela ajoute une étape, mais cette étape sépare la « vérification » de la « confirmation du résultat de la vérification ».
Je comprends l’intention de conception ici : si la vérification et l’approbation sont faites par les mêmes personnes, alors le résultat de la vérification devient déjà une conclusion finale, sans contre-pouvoir. En séparant en deux étapes, le comité d’approbation doit non seulement regarder le bloc, mais aussi vérifier si le comité de vérification a réellement fait son travail. C’est comme ajouter une couche de contrôle qualité à la couche de consensus.
Cette conception impose aussi une contrainte implicite : les comités sont tirés au hasard, en fonction de la quantité mise en jeu (le stake). Pour un attaquant, vouloir contrôler une étape exige de contrôler simultanément une grande quantité de stake, et en plus d’être choisi au hasard dans le même comité. Probabilistement, c’est bien plus difficile que de contrôler un simple groupe de vérification.
Mais le coût du consensus en étapes, c’est la latence. Chaque étape supplémentaire ajoute une autre ronde de communication. Comment le SA de Dusk peut conserver une confirmation à faible latence dans des scénarios de transactions financières à haute fréquence, je n’ai pas encore trouvé suffisamment de données dans la documentation publique.
En regardant la couche de consensus de #dusk , je vais continuer à suivre l’intervalle entre la production des blocs et leur finalisation, la fréquence de rotation des comités et le taux de forks observé dans le réseau réel. En tant qu’actif de mise (stake), DUSK, en déterminant directement les hypothèses de sécurité du consensus, détermine le type de risques auxquels les stakers sont exposés. #dusk @Dusk

#dusk $DUSK Aujourd’hui, je parcours des documents sur la coopération entre @Dusk et NPEX. Au début, je me suis dit que ce n’était qu’un énième communiqué : « une plateforme d’échange traditionnelle veut mettre quelque chose “on-chain” ». Mais en arrivant aux chiffres précis, je l’ai pris au sérieux. NPEX est une bourse de valeurs enregistrée aux Pays-Bas, placée sous la réglementation européenne. Elle a confirmé un volume d’émission de plus de 200 millions d’euros et une base d’investisseurs de plus de 20 000 personnes. Ce n’est pas une simple lettre d’intention du type « nous envisageons d’explorer la blockchain », mais une mise en conformité concrète, soutenue par un volume d’émission réel.
NPEX opère un marché privé réglementé : émission, accès des investisseurs, exécution des transactions, divulgation d’informations, règlement… Autant d’étapes qui imposent déjà des exigences de conformité mûries. Ce que fournit Dusk n’est pas « simplement publier des codes d’actions sur la blockchain », mais un ensemble complet de workflows : l’identité des investisseurs est validée par Citadel via des preuves à divulgation nulle de connaissance ; les transactions sont exécutées de façon confidentielle on-chain, tout en étant auditées par les régulateurs ; et le règlement s’appuie sur la finalité déterministe de SBA pour synchroniser paiements et coupons.
Je fais une analogie : ce n’est pas comme remplacer l’afficheur du hall d’une bourse par un écran électronique. C’est plutôt comme déménager tout le hall de trading, la chambre de compensation et le bureau d’enregistrement dans le même bâtiment, avec des droits d’accès différents selon les étages. Les investisseurs peuvent voir leurs positions, le régulateur dispose des données nécessaires, mais les passants ne voient aucun détail transactionnel.
Mais cela ne veut pas dire que tous les maillons sont déjà finalisés. La coopération de NPEX est encore à l’étape d’exploration : du « faisable techniquement » à « l’approbation réglementaire », puis à « de vrais utilisateurs qui échangent on-chain »—il reste encore un long parcours de conformité. Dans les informations publiques, je n’ai d’ailleurs pas trouvé de calendrier précis ni d’avancement de lancement. Cela implique que le marché doit garder de la patience vis-à-vis du récit RWA associé à $DUSK .
En observant la mise en œuvre du RWA de #dusk , je ne vais pas me contenter de ne regarder que le titre « 200 millions d’euros ». Ce qu’il faut vraiment suivre, c’est le moment du premier lancement d’une émission on-chain, le processus d’escalade du volume de 0 à 1, ainsi que la réponse concrète des autorités de régulation à cette architecture de confidentialité couplée à la conformité. $DUSK , en tant que gas et token de mise, verra sa valeur dépendre ultimement du fait que ces workflows d’actifs tournent réellement. #dusk @Dusk

#dusk $DUSK Récemment, j’ai reconstitué une fois de plus l’itinéraire de conformité de @Dusk et j’ai constaté que la différence la plus fondamentale avec la plupart des chaînes publiques n’est pas l’architecture technique, mais le fait qu’au départ, « la finance réglementée » a été positionnée comme produit. Mais il y a une logique que l’on simplifie facilement à l’excès : avoir un cadre de conformité ne veut pas dire qu’il existe déjà des actifs conformes en circulation sur la chaîne.$SNDKB
Les documents de Dusk mentionnent à répétition des cas d’usage de finance institutionnelle, et indiquent qu’ils prennent en charge les transactions confidentielles tout en satisfaisant aux exigences d’audit. Le modèle de confidentialité de Phoenix utilise des preuves à divulgation nulle (zéro connaissance) : il peut fournir à l’autorité de régulation des divulgations sélectives sans exposer les détails des transactions. C’est une base de conformité au niveau technique. Mais l’écart entre la conformité technique et la conformité judiciaire est beaucoup plus grand que beaucoup ne l’imaginent.
Pour un véritable déploiement des RWA (actifs réels tokenisés) on-chain, il ne faut pas seulement résoudre la confidentialité on-chain. L’émission des actifs, la garde (custodie) et la compensation : chaque étape doit être raccordée au système juridique existant. Par exemple, pour une obligation ou un fonds tokenisé, qui a le droit d’émettre ? Qui détient l’actif sous-jacent en garde ? Les enregistrements on-chain peuvent-ils servir de preuve de droits devant un tribunal ? Les réponses à ces questions ne se trouvent pas dans le livre blanc, mais dans les mémos de régulation et la pratique judiciaire. L’équipe de Dusk dispose d’implantations dans des endroits comme le Luxembourg et échange avec des institutions financières traditionnelles ; mais entre les échanges, la coopération et le fait que les actifs soient réellement tokenisés et mis en circulation on-chain, il y a encore un long chemin.$SPCXB
Et à l’heure actuelle, je n’ai pas encore vu de cas publics à grande échelle de RWA émis et échangés sur Dusk. Le stock de réserves techniques lié à la conformité mérite d’être salué, mais ce qui prouve la valeur finale, c’est l’échelle réelle des actifs on-chain et la fréquence des transactions.
Donc, quand j’observe maintenant les progrès de la conformité de DUSK, je n’assimile pas « conformité de positionnement » à « existence d’actifs déjà conformes ». Je m’intéresse surtout à : y a-t-il des institutions titulaires de licences qui ont émis des actifs sur Dusk ? des autorités de régulation ont-elles explicitement reconnu l’efficacité des enregistrements on-chain ? et quelle est l’échelle et la fréquence des transactions des RWA on-chain ? La conformité n’est pas un questionnaire à choix unique : c’est une liste de contrôle qui doit être validée point par point.#dusk @Dusk

#dusk $DUSK La récompense n’est pas calculée selon un APR fixe : elle dépend du fait d’être tiré au sort, puis si, une fois tiré, vous complétez correctement l’émission des blocs et le vote à temps. Le montant mis en jeu détermine la probabilité d’être tiré, tandis que le taux d’uptime détermine si, après avoir été tiré, vous pouvez encaisser. Pour une même position, un nœud stable et un nœud qui « tremble » de temps en temps : la partie de la différence annualisée qui en résulte existe réellement. $SNDKB
Ce qu’il faut surtout anticiper, ce sont les pénalités. Le traitement des manquements par le protocole ne se résume pas à « ne pas recevoir d’argent cette fois-ci » : des absences répétées font passer le staking dans un état de suspension. Pendant la période de suspension, vous ne participez ni à la production de blocs ni à la génération de récompenses ; il faut ensuite attendre de nouveau de remplir les conditions pour revenir dans l’ensemble des candidats. En cas de situation grave, une partie du capital est également déduite. Cela n’a rien à voir avec « déposer des pièces pour qu’elles génèrent des intérêts tranquillement » : c’est une expérience totalement différente. $SPCXB
Du coup, le chiffre 1000 DUSK doit aussi être relu autrement. C’est le minimum requis pour un staking direct, ce n’est pas le départ du rendement. Pour ceux dont la position est petite, tenter d’atteindre le seuil n’est pas forcément rentable : faire tourner un nœud implique que le serveur, les mises à jour de version, le monitoring et la récupération après incidents deviennent vos coûts quotidiens. Si vous externalisez cela à un pool tiers, vous échangez contre ses propres règles de retrait, son mode de garde et des risques liés aux contrats, qui ne sont pas les règles du réseau principal.
Je vais maintenant décomposer les récompenses de staking en trois niveaux : combien le protocole distribue au total (récompenses de blocs et répartition des frais), combien je devrais théoriquement recevoir (proportion du stake et probabilité d’être tiré), et combien je vais réellement manquer (temps hors ligne, suspension, pénalités, et cette partie des récompenses qui nécessite une revendication séparée). Les deux premiers niveaux déterminent le plafond, le troisième détermine ce que vous recevez réellement.
La conception du staking de DUSK est favorable aux participants de long terme, mais c’est plutôt comme un travail qui exige d’être en ligne, pas comme un certificat de dépôt. @Dusk

#termmax première opération : le FT à terme de 90 jours a expiré à TermMax. 1 000 USDC ont été déposés, 1 021,25 en sont sortis : aucun centime d’intérêt n’a été perdu, ni remise au moment de la livraison physique, ni étape nécessitant mon accord manuel. Franchement, c’est vraiment satisfaisant… et le problème est arrivé juste après.
Le jour où l’argent est revenu dans mon portefeuille, j’ai voulu en refaire un à l’identique. Résultat : la cotation du marché pour la même durée avait déjà chuté à 6,2 %. Pendant la période de blocage, j’ai bien échappé aux variations de taux d’intérêt flottants, en haut comme en bas… mais je ne pouvais pas éviter celui-ci : après l’échéance, il faut réentrer au prix du jour. C’est le risque de réinvestissement. Les revenus à taux fixe ne le font pas disparaître : ils le repoussent, simplement, et le font exploser le jour même de l’échéance.$SNDKB
Une couche plus fine encore : il y a aussi la question du rythme. Mettre tout le capital sur une seule date d’échéance revient à parier sur l’estimation des taux à un seul moment. Désormais, je passe à trois opérations, chacune avec une échéance décalée d’un mois : chaque mois a un montant qui revient, et au moment de la revalorisation, je ne suis pas obligé de tout miser d’un seul coup au plus bas.$SPCXB
Il vaut aussi la peine de regarder les prix sur le marché secondaire près de la date d’échéance. Plus un FT approche de son échéance, plus son prix colle à la valeur nominale, et plus la volatilité est faible ; à l’inverse, pour ceux qui veulent gagner sur l’écart de prix au secondaire, plus on avance dans le temps, moins on a de “viande” à grignoter. Si on doit vraiment sortir plus tôt, il faut chercher de la liquidité au milieu de la période d’existence, plutôt que d’attendre les deux dernières semaines pour se battre avec la valeur nominale et gagner de l’espace.
En une phrase : le taux fixe de TermMax verrouille le coût sur cette durée, pas votre rendement sur l’année à venir. Pour lisser les fluctuations de la courbe de taux, il faut des paliers de maturité, pas verrouiller un seul ticket pour plus longtemps.
#TermMax @TermMax

#termmax La barre de levier en un clic de TermMax ne semble reposer que sur deux variables : le multiplicateur de levier et le taux d’intérêt fixe.
J’ai récemment recalculé, et j’ai constaté que la part qui ronge réellement le rendement ne se trouve dans aucun de ces deux chiffres.
En réalité, le levier en un clic derrière, c’est une chaîne d’actions : emprunter des stablecoins, les échanger contre un actif en collatéral, puis les y re-déposer comme collatéral. Le protocole te l’assemble de façon atomique, mais les frictions de marché à chaque étape restent.
Lors de l’échange, il y a du slippage.
L’emprunt, il faut bien que quelqu’un soit disposé à payer ce montant à ce taux.
Lors du dénouement (closing), il faut aussi retransformer l’actif collatéral en stablecoin, puis encore une fois subir du slippage.
Ces trois coûts peuvent être négligeables pour de petites positions, mais ils sont décisifs pour les grandes.
Un scénario de “bad trade” assez courant fonctionne comme suit :
On voit un rendement du sous-jacent PT de 10 %, des frais d’emprunt de 6 %, un spread de 4 %, puis on multiplie par trois, et l’APY anticipé monte directement à une dizaine.
Ensuite, en pratique, à l’ouverture et à la sortie, chaque échange subit par exemple 0,5 % de slippage, soit 1 % au total sur l’aller-retour. Avec un levier x3, ce 1 % est amplifié jusqu’à 3 % sur tes fonds propres.
Ton spread de 4 % n’a même pas commencé à “courir” qu’il a déjà fondu une grosse partie.
Et s’il faut ajuster la position en cours de route, rembourser partiellement, ou changer de maturité (changer de terme), à chaque fois il faut repayer.
C’est aussi pour cela que je trouve que la V2 qui “déplie” les ordres à prix limite est plus concrète que la promesse publicitaire de “taux d’intérêt fixe”.
Avec les ordres à prix limite, tu n’es pas obligé d’accepter passivement le prix offert par la pool à l’instant T. Pour les grosses positions, tu peux les découper, laisser s’exécuter progressivement, et fixer ton propre prix.
Le prix à payer, c’est l’attente—et l’attente a un coût. C’est pourquoi TermMax doit faire en sorte que les fonds non exécutés continuent à capter le rendement du sous-jacent pendant la période d’attente ; sinon, pour les gros capitaux, les ordres à prix limite deviennent un fardeau.
Le Dashboard unifié, c’est la même logique. Sans visibilité sur ton exposition totale sur plusieurs chaînes et plusieurs maturités, tu ne peux pas juger s’il faut ou non ajouter encore une position.
Donc, pour évaluer aujourd’hui une stratégie de levier, je ne regarde pas le spread nominal : je ne regarde qu’un seul chiffre : $SPCXB .
Du moment où j’ouvre jusqu’au moment où je clôture, combien de fois vais-je payer des coûts de friction ?
Une stratégie qui en paie trois fois et une stratégie qui en paie dix fois : même si sur le papier le spread est identique, les résultats réels sont très différents.
Le “taux fixe” résout le prix de “l’argent emprunté”.
Mais il ne résout pas le prix “des échanges” lors des entrées/sorties.
Et ce dernier est souvent plus cher. $SNDKB
#TermMax @TermMax

#dusk Sous le mode Phoenix, le chemin de transfert des actifs n’est pas visible à l’extérieur ; seule une preuve à connaissance nulle (ZK) permet de vérifier la légitimité. Cela est faisable au sein d’une juridiction unique — par exemple, si l’AFM néerlandaise reconnaît ce mécanisme de preuve, l’institution peut alors fonctionner de manière conforme dans le cadre de l’AFM.$SNDKB
Mais la RWA, dans son essence, implique des flux transfrontaliers d’actifs. Un titre émis sur DUSK peut être détenu par des acteurs répartis dans l’UE, à Singapour, à Hong Kong et aux États-Unis. Chaque juridiction a sa propre définition de la « preuve de conformité acceptable », et les critères d’acceptation de la preuve ZK en tant que preuve juridique diffèrent aussi. L’AMF (SEC) américaine adopte pour l’instant une attitude assez prudente vis-à-vis des actifs à confidentialité en chaîne, et les cadres de la MAS et de la SFC évoluent également.$SPCXB
Cela signifie que, pour la couche de conformité de @Dusk , il faut en réalité satisfaire simultanément les exigences de plusieurs juridictions, qui peuvent entrer en conflit. Par exemple, le GDPR de l’UE exige la minimisation des données, mais certaines réglementations anti-blanchiment dans d’autres juridictions exigent un parcours de transaction complet et traçable — techniquement, ces deux exigences sont contradictoires ; ce n’est pas un simple réglage de paramètres qui permet de résoudre le problème.
Le défi plus concret est le suivant : lorsqu’une transaction transfrontalière de RWA déclenche un contrôle réglementaire, quelle autorité de la juridiction est habilitée à exiger le déchiffrement ? Si plusieurs juridictions présentent des demandes en même temps, comment établir l’ordre de priorité ? Ces questions ne figurent pas dans le livre blanc, mais elles se révéleront lors de la première transaction réelle d’une institution transfrontalière.
Je ne dis pas que ces problèmes n’ont pas de solution ; je dis que leurs solutions ne se trouvent pas dans la couche protocolaire, mais dans la couche juridique. DUSK a besoin non seulement de conformité technique, mais aussi de créer des précédents juridiques dans les principales juridictions. La première institution disposée à se prouver à elle-même auprès des régulateurs en utilisant des preuves ZK n’assume pas seulement des risques techniques : elle porte aussi des risques juridiques.
Le moment où ce précédent apparaîtra, plus que n’importe quelle mise à niveau technique, déterminera la vitesse d’adoption par $DUSK .
#dusk @Dusk

#termmax Deux choses « liées au temps » sont vraiment celles qui déterminent tes résultats dans un marché en extrême volatilité.
@TermMax Les liquidations ont deux types de déclencheurs : le LTV de la position qui atteint un seuil, ou l’emprunteur qui n’a pas remboursé à l’échéance. Dans le premier cas, cela dépend du prix fourni par l’oracle ; dans le second, du moment de l’échéance. Cela signifie que la sécurité de ta position ne dépend pas seulement de la valeur de la garantie, mais aussi de « la capacité du système à refléter le prix réel à temps » et de « si tu as effectué le remboursement au bon moment, juste avant le jour d’échéance ».$SNDKB
Concernant le maillon des oracles, j’ai toujours pensé que c’était un point de risque sous-estimé. Quand le marché chute par gaps, si la mise à jour du prix est en retard, ta position peut encore sembler « sûre » sur le papier, alors qu’en réalité elle est déjà en situation d’insolvabilité ; quand les cotations rattrapent leur retard, il est souvent trop tard pour exécuter la liquidation de manière posée. Le taux fixe peut verrouiller le coût, mais ne peut pas verrouiller le manque créé par le retard de l’alimentation des prix.
L’échéance, elle, représente une autre pression temporelle. Ne pas rembourser à temps fait entrer la position dans la fenêtre de liquidation : autrement dit, même si le marché ne chute pas, tu as seulement manqué le créneau de remboursement, et le traitement se déclenche quand même. La « certitude » des taux fixes repose sur le fait que « tu tiens tes engagements à l’heure ». Dès que la ligne de temps se brise, cette certitude s’effondre aussi.$SPCXB
Je vois #TermMax : il traitera le temps comme une dimension de risque parallèle au prix. La fréquence et la fiabilité des mises à jour de l’oracle, s’il y a une marge opérationnelle suffisante autour de la date d’échéance, et si, dans des conditions extrêmes, l’alimentation du prix et la liquidation arrivent à suivre le gap. Tout cela n’apparaît pas dans l’APY, mais c’est ce qui décide si ce chiffre peut réellement être tenu.
Un taux fixe verrouille la volatilité du prix, mais ne verrouille pas l’écoulement du temps. La vraie gestion des risques, c’est de faire les comptes du taux, mais aussi de préserver les deux lignes de temps : la date d’échéance et la mise à jour des prix.#TermMax @TermMax

#dusk $DUSK Quand j’ai examiné le mécanisme de production de blocs de DUSK, j’ai constaté qu’il est assez différent de la PoS que je connaissais. Ce n’est pas l’ensemble des nœuds de staking qui participe au découpage des blocs : à chaque tour, on tire un comité, et seuls les nœuds sélectionnés ont le droit de produire des blocs et de voter pour confirmer. Au début, je me suis dit que cela serait moins efficace. Puis j’ai compris que l’intention de conception était en fait de préserver les deux aspects à la fois : une production de blocs rapide, tout en assurant une participation suffisamment large pour la confirmation finale, sans laisser la décision reposer sur une poignée de nœuds.
Cela me fait penser au système de tirage au sort des jurés. Dans ce système, tous les citoyens inscrits ne sont pas tenus de se rendre au tribunal ; pour chaque affaire, on tire au hasard un groupe de personnes pour constituer le jury. Seuls ceux qui ont été tirés au sort endossent la responsabilité de ce jugement ; ceux qui ne sont pas tirés ne participent pas cette fois-ci, mais peuvent l’être lors d’un prochain tirage. Le consensus par comité de DUSK suit la même logique : tous les nœuds en staking constituent le bassin de candidats, et à chaque tour on sélectionne aléatoirement une partie pour former le comité. Seuls eux sont responsables, pour ce tour, de la production et de la confirmation des blocs. $SPCXB
Cette analogie s’arrête là : le tirage des jurés sert à la représentativité et à l’équité, tandis que le mécanisme de sélection de DUSK vise à résoudre un problème technique — comment concilier vitesse et sécurité après l’augmentation de la taille du réseau. Les objectifs de départ ne sont donc pas les mêmes. Par rapport à la compétition de puissance de calcul (minage) pour produire des blocs sur BTC, DUSK n’a pas besoin que tout le réseau se précipite pour calculer des hashes. Et par rapport à certains PoS où l’ensemble des validateurs est fixe, le comité de DUSK est renouvelé dynamiquement ; en théorie, cela réduit le risque de verrouillage durable du droit de produire des blocs. $SNDKB
Ce que je veux clarifier ensuite, c’est le lien précis entre la probabilité d’être sélectionné et la quantité de staking : à quelle fréquence les petits stakers — ceux qui détiennent des montants modestes — sont-ils réellement tirés au sort ? J’ai l’intention de rechercher des paramètres plus détaillés, puis de mettre à jour mes conclusions. #dusk @Dusk

#termmax Après avoir réexaminé le positionnement produit de TermMax, j’ai réalisé que le taux fixe ne résout pas vraiment la question « comment obtenir le rendement le plus élevé », mais plutôt celle de la transformation des fonds on-chain : de cotations qui changent en permanence vers un coût financier qu’on peut planifier à l’avance.
Le taux variable convient aux fonds flexibles, mais il n’est pas adapté aux stratégies nécessitant une gestion à long terme. Le coût que l’emprunteur voit aujourd’hui peut changer nettement quelques jours plus tard, si le taux d’utilisation augmente. #TermMax traite ce type d’incertitude en précisant une date d’échéance et un prix de financement fixe, afin que les utilisateurs puissent calculer dès l’ouverture de position combien d’intérêts ils devront payer dans le pire des cas.$SNDKB
Cette certitude a de la valeur pour la rotation des stablecoins, les stratégies de rendement et la gestion des actifs on-chain. Les institutions ou utilisateurs professionnels ne cherchent généralement pas seulement le plus haut APR ; ils se préoccupent surtout de savoir si les flux de trésorerie peuvent être anticipés, quand les dettes arrivent à échéance, et si le rendement et les coûts se situent sur le même intervalle de temps. Ce que le marché du taux fixe apporte, c’est, fondamentalement, un calendrier des fonds plus clair.
Mais le fait qu’un produit soit calculable ne signifie pas que le risque disparaît automatiquement.@TermMax Il faut encore faire face à des problèmes de sécurité des smart contracts, de prix des oracles, de volatilité des collatéraux, d’efficacité de la liquidation et de liquidité à l’échéance. Si un marché venait à perdre soudainement la liquidité de son collatéral, même si le taux de l’emprunt est déjà verrouillé, le processus de liquidation pourrait tout de même générer une pression sur les créances douteuses.$SPCXB
Je pense que pour évaluer si TermMax atteint réellement la maturité, on ne peut pas se contenter de regarder un instant donné du volume de lock. Le plus important est de savoir si la demande d’emprunts actifs est continue, si des transactions stables se forment sur différentes échéances, si les fonds à l’échéance peuvent être réglés sans encombre, et si le protocole maintient un fonctionnement normal en période de marché très volatile.
Un autre indicateur facilement négligé : le taux de réutilisation. Si, après l’expiration d’un prêt, l’utilisateur choisit de nouveau une nouvelle échéance, cela montre que le taux fixe répond bien à un besoin réel ; si les fonds ne font que rester temporairement pendant la période d’incitation, la croissance ne vient pas forcément du produit lui-même.
Les emprunts on-chain ressemblent par le passé davantage à un hôtel où l’on renégocie le prix chaque jour, et TermMax veut plutôt proposer un contrat de location où le prix et la date de départ sont écrits à l’avance. La valeur d’un contrat n’est pas d’être toujours le moins cher, mais de permettre aux deux parties de savoir exactement ce qui devra être payé à l’avenir.@TermMax

#dusk $DUSK Je pense que pour évaluer la future valeur de Dusk, on ne doit pas se contenter de regarder la mise en ligne sur le réseau principal ou les variations de prix à court terme : il faut aussi voir s’il peut établir une chaîne complète de circulation d’actifs. Pour les jetons ordinaires, l’émission, le transfert et la négociation sont déjà assez mûrs ; mais pour des actifs réglementés comme des parts immobilières, des obligations, des certificats de fonds, etc., l’entrée dans la blockchain rend les choses beaucoup plus complexes. Comment confirmer l’origine des actifs, vérifier l’éligibilité des détenteurs, protéger la confidentialité des transactions, et déterminer qui a le pouvoir de geler ou de corriger en cas de litige : tout cela nécessite un support clair de la couche réseau sous-jacente.$SPCXB
La direction de Dusk s’inscrit justement dans ce type de scénarios. Elle regroupe, sur la même feuille de route, le règlement final, les preuves de confidentialité et l’environnement de développement EVM. En théorie, cela permet aux institutions de continuer à utiliser les outils Solidity, tout en obtenant des capacités de confidentialité et de conformité plus adaptées aux actifs financiers. Cet assemblage a plus de sens qu’une simple course à des TPS plus élevés : en pratique, ce qui intéresse vraiment les institutions financières, ce n’est pas tant le nombre de transferts ordinaires traités par seconde, mais plutôt la traçabilité des transactions, la clarté des droits, et la détermination du règlement.$SNDKB
Mais avoir la bonne trajectoire ne signifie pas que l’application est déjà mature. DuskEVM doit encore être validé via des tests sur testnet, et les capacités liées à Dusk Trade doivent passer de la phase de construction à un fonctionnement stable. Entre la plateforme d’émission d’actifs et les modules d’échange, il faut résoudre des problèmes tels que l’identité, les listes blanches, la cartographie d’actifs entre couches, le paiement des frais et les mécanismes de rollback en cas d’échec. Si un maillon est flou, les institutions peuvent décider d’abandonner l’usage à cause des risques opérationnels.
C’est pourquoi je vais décomposer l’avancement des applications de Dusk en trois indicateurs d’observation. D’abord, est-ce que les actifs réels peuvent boucler le cycle de l’émission jusqu’au règlement ? Ensuite, est-ce que les transactions confidentielles peuvent concilier audit et supervision réglementaire ? Enfin, est-ce que des équipes Solidity classiques peuvent s’intégrer sans augmenter de manière significative les coûts de développement ? Ce n’est que lorsque ces trois points se concrétiseront progressivement qu’il sera possible de transformer le récit technique en un besoin du réseau. Selon vous, le premier domaine que Dusk parviendra à dépasser sera-t-il celui des obligations, des fonds, ou d’autres types d’actifs ?
#dusk @Dusk

#termmax Beaucoup de gens découvrent pour la première fois un accord à taux fixe et font l’erreur la plus fréquente : dès que la page affiche un chiffre précis, la valeur de la position ne changerait pas pendant toute la durée de détention. Mais après avoir étudié @TermMax , on constate que « revenu fixe » et « prix fixe » sont en réalité deux choses totalement différentes. Le premier décrit les flux de trésorerie selon des conditions convenues et détenus jusqu’à l’échéance ; le second dépend de l’instant où vous sortez et de la profondeur du marché à ce moment-là.$SNDKB
Prenons l’exemple de FT : c’est plus proche d’un titre à zéro-coupon on-chain avec une date d’échéance clairement définie. L’utilisateur achète à un prix inférieur à la valeur nominale à l’échéance. Si la dette concernée est normalement remboursée et que le règlement se déroule correctement, le détenteur peut alors récupérer des actifs selon les règles à l’échéance. L’écart entre le prix d’achat et la valeur de rachat constitue le rendement attendu. L’avantage de cette structure, c’est qu’elle évite de devoir deviner tous les jours si le taux du pool d’emprunt-prêt va varier : le montant d’actifs récupérables à l’avenir est relativement plus facile à estimer.
Le problème, c’est que les détenteurs ne resteront pas forcément jusqu’à l’échéance. Supposons que les taux d’intérêt du marché augmentent soudainement : un FT nouvellement émis ou récemment négocié pourrait offrir un rendement plus attractif. Alors, si l’ancien FT veut être vendu à l’avance, il pourrait nécessiter une baisse de prix. À l’inverse, si les taux baissent, le rendement initialement verrouillé peut devenir plus précieux. Ainsi, #TermMax fixe la règle d’échéance, mais n’élimine pas la volatilité des prix en cours de route.
Il faut aussi tenir compte de la liquidité. Le même FT peut afficher un bon rendement à l’échéance « sur le papier », mais si la profondeur d’ordres est faible, une vente d’un volume un peu plus important peut consommer successivement plusieurs niveaux de prix. Le prix final d’exécution, le slippage et les frais, additionnés, peuvent réduire nettement un rendement qui semblait au départ séduisant. Plus la durée est longue, plus il est probable qu’un besoin de liquidités survienne en cours de route et que les taux évoluent.$SPCXB
C’est pourquoi, lorsque j’évalue une opportunité à taux fixe avec TermMax, je sépare « conserver jusqu’à l’échéance » et « sortir à l’avance » en deux scénarios. Pour le premier, je me concentre sur la qualité de la garantie, le mécanisme de liquidation et le chemin de remboursement à l’échéance ; pour le second, sur l’écart acheteur-vendeur, la profondeur des ordres et le slippage que l’on peut raisonnablement supporter. Ce n’est que si vous avez clarifié les deux voies que le taux affiché sur la page devient un fondement décisionnel, et non un chiffre accrocheur destiné à faire oublier les risques. En réalité, un taux fixe apporte surtout de la planification, pas une garantie de tous les résultats.@TermMax

Je consulte aujourd’hui la documentation de DuskEVM de @Dusk . Je pensais au départ que c’était simplement une porte d’entrée pour les développeurs Solidity. La vraie question à clarifier, c’est que déplacer un contrat depuis l’écosystème Ethereum vers ailleurs ne signifie pas pour autant transférer l’application complète. DuskEVM s’occupe de l’exécution, DuskDS gère la finalisation. Cette trajectoire est proche, côté outils, de l’écosystème EVM, mais au niveau de l’état sous-jacent, des règles de gaz et des interfaces de confidentialité, l’équivalence n’est pas parfaite.
Un équipe qui utilise déjà Hardhat ou Foundry se concentre surtout sur les scripts de déploiement, la vérification du timing, l’abonnement aux événements et les mécanismes de rollback. Le fait que la compilation des contrats réussisse ne veut pas dire que les oracles, les indexeurs et les portefeuilles frontaux peuvent être réutilisés directement. Si un contrat Solidity doit lire des données on-chain ou déclencher des fonctions de confidentialité, il faut comprendre les frontières entre DuskVM et Phoenix. Sinon, l’application pourra peut-être fonctionner, mais la structure des coûts et les performances ne seront absolument pas celles qu’on avait en tête.
Pour donner une analogie : c’est comme installer dans un magasin un système de caisse compatible avec le siège. L’interface en façade ne change pas, mais l’inventaire du dépôt et les données des membres suivent encore une autre procédure. Le caissier voit un écran familier, tandis que la comptabilité et la réconciliation en arrière-plan doivent être entièrement repensées. La migration des développeurs n’est pas un simple copier-coller : il faut revalider chaque couche de dépendances.
L’initiative officielle insiste sur le fait que DuskEVM peut prendre en charge la chaîne d’outils Ethereum : c’est une direction cohérente. Mais ce qu’il faut vraiment observer, c’est s’il y a des développeurs prêts à continuer à déployer, et s’il est possible de localiser rapidement la source d’un échec de contrat—DuskEVM, DuskDS, ou encore un composant de pont. Ajouter un chemin d’exécution, c’est ajouter une couche de complexité opérationnelle. Pour une équipe de développement, le plus coûteux n’est souvent pas le gas, mais le temps de résolution des problèmes.
Donc, en regardant l’avancement de l’écosystème de #dusk , je ne vais pas assimiler “compatibilité EVM” à “les développeurs sont déjà là”. Pour DUSK, les indicateurs les plus critiques sont le nombre de contrats actifs, le taux de tentatives de déploiement et la stabilité du RPC. Ouvrir une entrée n’est que la première étape : c’est la capacité à conserver les gens grâce à l’expérience des outils et au dépannage qui rend difficile le démarrage à froid de l’écosystème. #dusk @Dusk $DUSK

#dusk $DUSK Récemment, j’ai consulté la documentation de développement des créateurs de Dusk et j’ai constaté qu’elle est devenue beaucoup plus complète qu’il y a un an. Les tutoriels de déploiement du réseau de test, les exemples de contrats de confidentialité et les instructions de démarrage des nœuds sont mieux organisés et plus clairs qu’avant. Bien qu’il reste encore un écart par rapport à l’expérience développeur des chaînes les plus performantes, la direction est bonne. Pour savoir si une blockchain peut faire mûrir un écosystème, l’expérience liée à la documentation et aux outils compte bien plus que de nombreuses campagnes marketing.
J’ai participé à plusieurs événements du réseau de test de la communauté Dusk. Honnêtement, au début, il n’y avait pas beaucoup de participants, mais ceux qui sont restés se consacrent majoritairement à une étude sérieuse de la confidentialité et de la RWA. Dans les discussions de la communauté, on entend rarement des gens crier tous les jours pour « faire monter le panier » ; on parle davantage du modèle de billets de confidentialité, de la conception de conformité et des possibilités de partenariats avec des institutions. Ce genre d’ambiance est au contraire de plus en plus rare dans le marché actuel.
Les détenteurs de DUSK doivent réfléchir à une chose : la prime de ce projet ne vient pas de l’enthousiasme du marché à court terme, mais de sa capacité à devenir une infrastructure de base conforme à la confidentialité. Le cycle de validation des infrastructures est long : il peut ne pas se passer grand-chose pendant un an ou deux, mais une fois que des institutions commencent à y accéder, le fossé concurrentiel devient bien plus profond que celui des projets purement DeFi.
L’écosystème développeur est essentiel dans ce processus. Les partenariats avec des institutions ne suffisent pas : il faut aussi que des développeurs tiers soient prêts à construire des wallets, des outils et des interfaces front-end sur Dusk. Des détails comme la qualité et la complétude de la documentation, les incitations du réseau de test, la stabilité des nœuds, déterminent si les développeurs vont rester. Beaucoup de chaînes échouent justement à cause de ces aspects invisibles.
En ce moment, en regardant les progrès de Dusk, je m’intéresse davantage à son activité développeur, à la fréquence des mises à jour des versions, et à la mesure dans laquelle les retours de la communauté sont pris en compte. Ce n’est pas aussi stimulant que les variations de prix de DUSK, mais c’est plus proche de la valeur intrinsèque du projet. Un écosystème ne se construit pas en une journée, mais on peut constater chaque jour un peu de différence.
Un projet qui cherche à optimiser en continu la documentation et les outils indique au moins que l’équipe pense sur le long terme. Je préférerais voir la documentation de développement dans six mois
#dusk @Dusk $DUSK

#dusk L’année dernière, quand le règlement européen MiCA a été tranché, dans le milieu, les critiques allaient bon train : on disait que c’était des menottes pour l’industrie crypto. À l’époque, je me suis moqué moi aussi, en me disant que c’était encore la vieille Europe qui s’ingérait. Puis je me suis calmé et j’ai compris le vrai sens de cette affaire : pour la première fois, le texte a mis noir sur blanc « quels types de chaînes, quels types d’actifs peuvent entrer sur un marché conforme de l’UE ». Sans autorisation, dehors.
@Dusk est une équipe néerlandaise, avec des racines européennes ; dès le départ, elle n’avait pas l’intention de contourner la réglementation. Leurs arbitrages de pile technique suivent quasiment la liste de contrôle MiCA, en la cochant : confidentialité audit-able (en correspondance avec les exigences AML), finalité à la seconde près (en correspondance avec les clauses de risque de règlement), couche d’identité Citadel (en correspondance avec la diligence raisonnable des émetteurs), performances au niveau institutionnel (en correspondance avec les standards des infrastructures de marché). Cette posture de « rendre le devoir à l’avance », on la voit assez rarement dans le style américain du « on fait d’abord, on modifiera quand on sera poursuivi ». $AKE
$DUSK est parie clairement sur quelque chose : une fois que le couloir de conformité de l’UE sera ouvert, les banques traditionnelles, les courtiers et les gestionnaires d’actifs, lorsqu’ils alloueront des actifs numériques, choisiront en priorité « des routiers qui ont le permis », plutôt que des chauffards sans permis. Le poste est plutôt bien verrouillé : à court terme, rien n’explose, mais à long terme, c’est un fossé défensif.
Bien sûr, il y a aussi un coût. Le chemin de la conformité implique un rythme d’itération plus lent, des fonctionnalités plus conservatrices au moment du déploiement, et moins de célébrations façon meme par les petits investisseurs. #dusk ne te donnera très probablement pas des sensations façon « x10 d’un coup en une nuit » : ce qu’il prépare, c’est un slow bull sur dix ans.
De mon côté, j’aime particulièrement ce genre de projet « travail ingrat et lourd », pas parce que c’est garanti rentable, mais parce que la logique narrative tient debout. Dans la crypto, on ne peut pas faire que du casino : il faut aussi des gens qui construisent sérieusement les infrastructures, même si c’est plus lent.
Quant à savoir si tout cela finira par se concrétiser, il faudra voir le mainnet, la liste des institutions partenaires, et s’ils tiennent la première vague de « troupes régulières » après la mise en œuvre de MiCA. Les variables sont nombreuses : ne mise pas tout au même endroit. $SPCXB
DYOR, ce n’est pas un conseil en investissement : protégez votre capital. Selon vous, entre la chaîne conforme et la chaîne sauvage, qui rira à la fin à l’avenir ?
#dusk @Dusk

#dusk $DUSK Quand on examine le récit de conformité de Dusk, on calcule toujours une note.
Ce n’est pas TPS.
Ce n’est pas non plus le prix unitaire du gas.
Il s’agit plutôt du coût réel de bout en bout, depuis l’émission jusqu’à la circulation, d’un actif réglementé—tout reste sur la chaîne.
La logique de conception de @Dusk est la suivante : utiliser DuskDS comme couche de règlement, Citadel pour gérer l’identité, Phoenix pour protéger la confidentialité, et la divulgation sélective pour répondre aux exigences d’audit. On dirait que chaque module résout une partie des problèmes.
Mais le problème n’est pas isolé.
Imaginons qu’une institution doive émettre une obligation privée sur la chaîne.
D’abord, les investisseurs doivent passer le KYC et obtenir un certificat Citadel. Qui délivre ce certificat ? Quel est le coût de stockage en chaîne ? À l’expiration de la validité du certificat, faut-il le renouveler ? Et si le renouvellement échoue, que devient l’actif ?
Ensuite, la cession d’obligations doit vérifier la qualification du destinataire. À chaque transfert, il faut appeler l’interface de vérification de Citadel : combien d’interactions on-chain cela implique-t-il, et quelle quantité de gas cela consomme-t-il ? Si le transfert est refusé, comment l’état on-chain est-il annulé (rollback) ?
Plus en aval, à un moment donné, le régulateur peut exiger de voir la structure des détenteurs. L’émetteur doit générer une viewing key et l’autoriser : cette autorisation est-elle permanente ou temporaire ? Peut-elle être limitée de façon précise à certaines transactions, ou à une période donnée ?
Enfin, en cas de défaut de paiement ou de litige, les actifs on-chain peuvent-ils être gelés judiciairement ou transférés de force ? Quelles permissions le smart contract doit-il réserver pour cela ? Ces permissions risquent-elles d’entrer en conflit avec la « décentralisation » ?
Je additionne donc le gas, le stockage, la vérification et les coûts liés aux litiges de ces étapes, puis je les compare aux frais d’intermédiation de la finance traditionnelle, aux coûts d’audit et au temps de compensation.
#dusk doit permettre aux institutions de mettre réellement leurs actifs sur la chaîne : pas seulement prouver que « c’est faisable techniquement », mais prouver que « une fois fait, c’est moins cher, plus rapide et plus sûr ».
Si les coûts on-chain sont plus élevés, la seule raison serait la transparence et l’auditable. Mais Phoenix masque les transactions : où est la transparence ? La divulgation sélective est-elle assez flexible ? Après divulgation, qui vérifie que les données n’ont pas été falsifiées ?
C’est pourquoi, à présent, je regarde une institution qui adopte l’approche de bout en bout, et je ne me limite pas à « a-t-elle des fonctions de conformité ».
Je veux plutôt surveiller le coût total end-to-end d’un processus complet : de l’authentification d’identité, à l’émission des actifs, en passant par la validation des transferts jusqu’à la divulgation d’audit—tout se fait sur la chaîne—et combien de temps et de frais cela fait gagner par rapport à une solution hors-chaîne. $BTC

#dusk @Dusk

La première fois que j’ai vu le schéma de l’architecture de DUSK, j’ai eu une question : pourquoi faut-il deux machines virtuelles ? DuskVM exécute des contrats natifs, tandis que DuskEVM exécute des contrats compatibles avec Ethereum — est-ce que cela n’ajoute pas de complexité ? Mais en approfondissant, j’ai découvert que cette conception vise en réalité à résoudre un problème très concret : le compromis entre sécurité et performance.
DuskVM est la machine virtuelle native de DUSK : elle s’exécute directement au niveau de la couche de consensus et peut accéder à toutes les fonctionnalités sous-jacentes, comme les preuves à connaissance nulle, les transactions de confidentialité, le protocole Phoenix, etc. Et DuskEVM repose sur OP Stack : il exécute des contrats intelligents de type Ethereum, mais le règlement final est assuré par DuskDS. La différence clé est la suivante : dans DuskVM, les contrats sont directement liés à la sécurité du consensus de DUSK, tandis que dans DuskEVM, les contrats dépendent d’une couche de pont externe.
Cela conduit à une répartition très intéressante : les actifs sensibles (par exemple les jetons RWA, les actifs soumis à conformité) doivent être placés sur DuskVM, car ils ont besoin d’exploiter directement les fonctionnalités de confidentialité et de conformité de DUSK ; tandis que les applications DeFi ordinaires (par exemple un échange décentralisé, des protocoles de prêt) peuvent être sur DuskEVM, car les développeurs n’ont qu’à migrer du code Ethereum existant, sans avoir à réécrire les contrats.
J’ai vérifié les retours des développeurs : déployer un clone d’Uniswap V2 sur DuskEVM ne nécessite que d’environ 20 lignes de code modifiées (principalement pour adapter les paramètres réseau). En revanche, pour développer à partir de zéro sur DuskVM, il faut des centaines de lignes. Mais les transactions sur DuskVM sont plus rapides (en moyenne 1,5 seconde pour produire un bloc) et ne nécessitent pas de frais de pont. En pratique, c’est donc un choix entre efficacité de développement et performance.
Un autre point à surveiller concerne l’isolement de sécurité. Les données de DuskVM et de DuskEVM sont physiquement séparées : les contrats de DuskEVM ne peuvent pas accéder directement à l’état de confidentialité de DuskVM. Cela permet d’éviter des attaques du type « flash loan » via des vulnérabilités d’accès transversal entre couches. Lors de l’audit de sécurité officiel de DUSK en septembre 2025, l’accent a été mis sur les tests d’appels entre VM ; il a été constaté que tous les appels doivent passer par une « passerelle sandbox ». Cette passerelle vérifie les autorisations et le type de l’appelant, afin d’empêcher l’infiltration de code malveillant. $BTC
Mais à mon avis, cette double architecture comporte aussi des risques potentiels : si la logique de pont entre les deux VM présente une faille, elle pourrait être exploitée. Par exemple, un attaquant pourrait falsifier un appel de contrat DuskEVM afin de consommer les ressources de DuskVM.
#dusk @Dusk $DUSK

#TradFi晒单 Revoir que la volatilité implicite de $SNDKB a déjà été amortie, mais que le biais (skew) des options sur l’action SanDisk reste à un niveau élevé : cela signifie que le marché valorise fortement le risque de queue. J’ai choisi d’utiliser SNDKB en remplacement de l’action pour un premier essai en position à découvert (stratégie de “gauche”), car les warrants ne présentent pas le risque de liquidité lié à l’impossibilité de couper les pertes après un krach des actions américaines pendant la nuit. Ainsi, le sizing de la position peut être contrôlé avec précision. Aujourd’hui, j’ai constitué une position d’essai de 2 %. Si, dans les deux semaines, le cours de l’action SanDisk arrive à tenir ses plus bas précédents, la décote de SNDKB se resserrera davantage ; à ce moment-là, j’ajouterai. La condition, c’est que les perturbations de l’offre d’ASIC et de CXMT ne s’aggravent pas. Vous prenez SNDKB comme un outil de couverture, ou bien vous le regardez uniquement dans une logique de direction ?