Muzamil Abbas⁷⁵ 穆扎米尔_阿巴斯

#dusk $DUSK @Dusk
Je parcourais l’approche de Dusk en matière de tokenisation des actifs de sécurité et un détail n’arrêtait pas d’attirer mon attention. La plupart des transferts sur blockchain semblent instantanés de l’extérieur. Les actifs se déplacent, les soldes changent, et la transaction est considérée comme terminée. Mais les actifs réglementés ne fonctionnent pas toujours ainsi.

Dans le modèle Zedger de Dusk, un transfert n’est pas automatiquement considéré comme complet dès qu’il est envoyé. Le destinataire doit d’abord l’accepter explicitement. Tant que cela ne se produit pas, le montant transféré doit encore être comptabilisé correctement. Cela peut sembler relever d’un petit choix de conception, mais il résout un problème étonnamment difficile.

J’ai commencé à réfléchir à des situations où une partie d’une transaction est prête avant l’autre. Peut-être que l’expéditeur a déjà initié le transfert, mais que le destinataire ne l’a pas encore approuvé. Les systèmes crypto traditionnels se concentrent généralement sur le fait de déplacer la valeur aussi vite que possible. Dusk semble, lui, se concentrer davantage sur le suivi des responsabilités pendant la période comprise entre l’initiation et le règlement.

Ce que je trouve intéressant, c’est que cet état intermédiaire est traité comme faisant partie du processus plutôt que comme une exception. Le système conserve la trace de la propriété et des soldes pendant qu’il attend l’étape d’approbation finale.

Pour les titres tokenisés et les actifs réglementés, cela ressemble beaucoup à la manière dont les flux de travail financiers réels fonctionnent. La question est de savoir si, à mesure que la tokenisation se développe, davantage de systèmes blockchain devront éventuellement adopter une logique de règlement similaire.

#dusk $DUSK @Dusk
Je pense que la confidentialité devient bien plus utile lorsque vous pouvez comprendre clairement ce qui est réellement dissimulé.

C’est une des raisons pour lesquelles la conception de Dusk se distingue pour moi. Dans Phoenix, le livre blanc sépare les sorties en types transparents et obfusqués. Ainsi, la confidentialité n’est pas traitée comme un simple interrupteur où tout disparaît. Certaines informations peuvent rester visibles, tandis que d’autres détails sont protégés.

Zedger pousse cette idée plus loin avec la tokenisation pour la sécurité. Les changements de solde du compte peuvent être conservés en mémoire privée, tandis qu’une racine de Sparse Merkle Segment Trie est révélée publiquement. Cela permet au système de disposer d’un élément vérifiable sans divulguer en soi les informations sous-jacentes du compte.

Pour moi, cette distinction est importante. Un système de confidentialité ne consiste pas uniquement à cacher des données. Il a aussi besoin d’une frontière claire entre ce que le réseau peut vérifier publiquement et ce qui reste privé pour l’utilisateur concerné.

C’est là que l’approche de Dusk devient intéressante. Confidentialité et transparence ne sont pas nécessairement des opposés. La vraie question est de savoir si le protocole peut faire fonctionner les deux ensemble sans exposer des informations qui n’ont pas besoin d’être publiques.

#dusk $DUSK @Dusk
Je réfléchissais à la manière dont la plupart des discussions sur la crypto traitent encore la confidentialité comme quelque chose qui appartient à une chaîne spécifique. Si vous voulez de la confidentialité, vous déplacez des actifs là-bas. Si vous avez besoin de conformité ou d’autres fonctionnalités, vous allez ailleurs. Cette séparation m’a toujours semblé un peu limitante.

Ce qui a retenu mon attention avec DUSK, c’est l’idée que la confidentialité peut devenir une partie du workflow lui-même plutôt qu’une destination. Le réseau a été conçu autour de transactions confidentielles, de preuves à divulgation nulle (zero-knowledge) et de structures capables de prendre en charge des actifs réglementés sans exposer publiquement chaque détail. Au lieu de forcer les utilisateurs à choisir entre transparence et confidentialité, l’objectif semble être de faire coexister les deux dans le même environnement, selon ce que la situation exige.

Cela me paraît plus pratique que le débat habituel entre chaîne privée et chaîne publique. L’activité financière réelle est rarement unidimensionnelle. Différents participants ont besoin de différents niveaux de visibilité, et un système capable de s’adapter à cela peut être plus utile que celui construit autour d’une seule règle pour tout le monde.

La question est de savoir si le marché finira par valoriser la confidentialité comme une infrastructure plutôt qu’une fonctionnalité de niche rattachée à une blockchain particulière.

#dusk $DUSK @Dusk
Je repense davantage à l’approche de Dusk pour mettre des données de marché en chaîne, et un point me gêne sans cesse

Faire entrer un prix sur une blockchain, c’est un problème
Déterminer quel prix mérite d’y figurer, c’en est un autre

Pour un actif liquide, plusieurs marchés actifs peuvent fournir une référence raisonnable, car il y a suffisamment d’activité de négociation pour comparer

Mais un titre faiblement négocié, c’est différent

Une seule petite transaction peut faire bouger le prix affiché, alors que le dernier prix négocié ne reflète peut-être pas ce que quelqu’un pourrait réellement vendre pour l’actif

Si ce chiffre devient une partie d’un flux de travail onchain, la source des données devient soudain aussi importante que l’infrastructure qui la transporte

Cela me fait voir le rôle de Dusk sous un angle différent

La question intéressante pour moi n’est pas simplement de savoir si des données de prix peuvent être mises en chaîne

C’est la manière dont le système gère les désaccords entre sources, les prix périmés, la faible liquidité ou les transactions inhabituelles

Il doit y avoir un moyen d’évaluer la qualité des données plutôt que de simplement enregistrer ce qui arrive en premier

J’aimerais voir comment cela fonctionne dans la pratique, à travers des actifs réglementés moins liquides, surtout lorsque des sources différentes produisent des valorisations légèrement différentes

Parce qu’à ce stade, la vraie question devient simple

Qui a le dernier mot sur ce qui constitue réellement un “vrai” prix ?

#dusk $DUSK @Dusk
Je réfléchissais un peu différemment à la conception post-négociation de Dusk après avoir lu le matériel sur le cycle de vie. Je pensais auparavant que la conformité programmable consistait surtout à s’assurer qu’une transaction est autorisée avant qu’elle n’ait lieu. Mais la question la plus difficile semble commencer après la transaction, lorsque la détention, les droits de vote, l’éligibilité aux dividendes et le statut de conformité doivent rester corrects.

Cela rend l’idée d’une conformité programmable assez utile, mais aussi légèrement inconfortable. Le code peut appliquer une règle de manière cohérente. Il ne peut pas savoir automatiquement quoi faire lorsque la situation réelle derrière cette règle change, ou ne correspond pas aux hypothèses sur lesquelles elle a été construite. Si l’éligibilité d’un détenteur change, ou si une condition réglementaire nécessite une exception, il faut un mécanisme pour gérer cet état plutôt que de se contenter de faire confiance à la logique initiale.

C’est là que je trouve que Dusk est plus intéressant que la simple tokenisation d’un actif. Le token lui-même est presque la couche la plus facile. Le problème le plus difficile, c’est de maintenir le registre exact à mesure que les transactions continuent. Mais je me demande encore quel est le rôle de la couche de dérogation. Qui est réellement de confiance pour intervenir lorsque les règles codées produisent un résultat erroné, et comment empêcher cette autorité de devenir le point le plus faible d’un système autrement programmable ?

#TermMax
J’ai réfléchi récemment à la structure de maturité de TermMax d’une manière un peu différente. Au début, je voyais surtout les durées fixes comme un moyen de rendre les coûts d’emprunt plus faciles à comprendre. Puis je me suis demandé ce qui se passe quand le sentiment du marché change rapidement et que, soudainement, tout le monde veut des maturités plus courtes.

Cela semble être un test de résistance plus utile que de simplement demander si les marchés à terme fixe fonctionnent dans des conditions normales. Si les emprunteurs deviennent mal à l’aise à l’idée d’immobiliser du capital plus longtemps, la demande pourrait basculer vers des durées plus courtes en même temps. Les prêteurs pourraient aussi réagir, surtout s’ils commencent à s’attendre à de meilleurs taux ailleurs. La courbe de tarification doit alors s’ajuster, et c’est là que TermMax m’intrigue davantage.

Le design à ordres par fourchette rend cela intéressant, car la liquidité n’est pas nécessairement offerte à une seule maturité ou un seul taux. Un teneur de marché peut exprimer des conditions différentes sur une plage, mais cela ne signifie pas automatiquement que la liquidité restera attractive lorsque les préférences changent brusquement. Il subsiste une dépendance à la rapidité avec laquelle les participants mettent à jour leurs ordres et à la profondeur disponible autour des maturités que les acteurs préfèrent soudainement.

C’est la partie que je veux observer. Pas seulement de savoir si TermMax a de la liquidité, mais comment cette liquidité se comporte lorsque les utilisateurs, collectivement, modifient leur préférence de temps. Le marché réévalue-t-il de façon fluide, ou bien les maturités plus courtes deviennent-elles surchargées pendant que les plus longues sont laissées de côté ?
#termmax @TermMax

#TermMax
Ces derniers temps, j’ai commencé à envisager différemment les ordres à plage de TermMax. Au début, je les ai traités comme une autre façon pour les market makers de fournir de la liquidité et de gagner grâce au prêt. Mais plus je réfléchis à la courbe de tarification, plus cela ressemble à une manière d’exprimer une vision des taux.

Un market maker n’a pas besoin d’offrir de la liquidité à un seul moment. Avec un ordre à plage, il peut définir comment les conditions évoluent sur un intervalle, ce qui signifie que sa liquidité peut refléter l’endroit où il est à l’aise pour participer. Si je pense que la demande d’emprunt restera forte seulement jusqu’à un certain taux, je peux façonner ma courbe autour de cette hypothèse plutôt que d’accepter n’importe quel taux qui apparaît.

L’Ordre à Plage à Deux Voies rend le tout encore plus intéressant, car les courbes d’emprunt et de prêt peuvent se trouver à l’intérieur du même ordre. Cela donne à la fourniture de liquidité une impression plus proche de la prise de position sur les taux, plutôt que du simple fait de déposer du capital et d’attendre.

Cela dit, je suis curieux de la qualité d’exécution. Une courbe sur le papier ne veut pas dire grand-chose si l’activité du marché reste en dehors de celle-ci, ou si l’évolution des conditions rend la vision des taux rapidement caduque. Je voudrais observer à quelle vitesse ces plages se remplissent, à quelle fréquence les market makers les ajustent, et si cette flexibilité se traduit, avec le temps, par une meilleure efficacité du capital.
#termmax @TermMax

Je lisais cette semaine quelques anciens rapports d’exploit liés à des ponts, et je me suis retrouvé à penser à quelque chose qui met un peu mal à l’aise. Quand un pont est piraté, les gens parlent généralement du smart contract, de l’ensemble des validateurs, ou du montant qui a été volé. Mais après avoir regardé suffisamment de cas, il semble que le pont révèle souvent quelque chose de plus grand que simplement un bug dans le pont lui-même.

Un pont se situe entre des systèmes qui ne se font pas naturellement confiance. De ce fait, il dépend généralement d’un certain groupe de validateurs, de signataires multisig de relayeurs, ou d’opérateurs, pour vérifier ce qui s’est passé sur une autre chaîne. Sur le papier, cela peut sembler assez décentralisé. En pratique, une quantité surprenante de confiance peut quand même se retrouver concentrée entre les mains d’une poignée de personnes ou de processus opérationnels.

C’est à cette partie que je reviens sans cesse. Un piratage de pont ne montre pas seulement où le code a échoué. Parfois, il met en évidence la manière dont des humains ont fini par faire partie du modèle de sécurité, même si les utilisateurs pensaient que tout était imposé par la chaîne elle-même. La blockchain est peut-être décentralisée, mais le chemin qui la relie à un autre réseau peut introduire des hypothèses très différentes.

Je ne dis pas que chaque conception de pont a les mêmes faiblesses. Certaines s’améliorent clairement. Pourtant, chaque fois que j’évalue aujourd’hui un système inter-chaînes, je passe moins de temps à me demander comment les actifs bougent et plus de temps à me demander qui, au final, est réellement digne de confiance lorsque quelque chose tourne mal. Est-ce qu’on améliore vraiment la façon de réduire cette dépendance, ou est-ce qu’on fait surtout qu’on la dissimule derrière une infrastructure plus complexe ?
#dusk $DUSK @Dusk

#TermMax
J’ai regardé comment TermMax gère les positions à taux fixe, et la structure FT, XT et GT est probablement la partie que je comprends désormais différemment. Au début, je pensais que le fait de scinder une position à taux fixe en jetons distincts était surtout une façon plus propre de représenter la même dette. Après avoir creusé un peu plus les mécanismes, je commence à voir pourquoi la séparation compte.

FT représente le principal, tandis que XT isole la composante des intérêts, et GT est davantage lié à la partie échéance de la position. Ce que je trouve utile ici, c’est qu’une position de dette à taux fixe ne doit plus se comporter comme un seul actif indivisible. Différentes parties de l’exposition économique peuvent potentiellement être traitées séparément, selon ce que l’utilisateur souhaite réellement détenir ou négocier.

Mais il y a un arbitrage que je continue de penser. Une modularité accrue peut créer davantage de façons de gérer l’exposition, mais elle peut aussi rendre la tarification et la liquidité plus difficiles à comprendre, surtout si chaque jeton développe sa propre profondeur de marché. J’aimerais voir dans quelle mesure ces composantes s’échangent de façon cohérente et si la séparation améliore réellement l’efficacité du capital dans un usage réel, plutôt que de simplement bien paraître au niveau du protocole.

Je continue de surveiller cela de près. Le fait de décomposer la dette à taux fixe en éléments plus petits crée-t-il vraiment de meilleurs marchés, ou déplace-t-on simplement la complexité ailleurs ?
#termmax @TermMax

J’ai récemment réfléchi à DuskEVM sous un angle légèrement différent : pas seulement au coût d’une transaction, mais à la prévisibilité de ce coût quand on développe quelque chose de réglementé.

Le point intéressant, c’est que les frais ne sont pas vraiment un simple chiffre. Ils dépendent de deux couches de tarification : d’un côté les coûts d’exécution, de l’autre les coûts de disponibilité des données. C’est dans cette seconde couche que la prévision peut devenir moins simple.

Imaginez une application financière qui traite des milliers de transactions similaires. Si l’exécution reste relativement stable mais que le composant de disponibilité des données varie avec les conditions du réseau, les frais moyens que vous aviez anticipés au début du mois peuvent ne pas correspondre à ceux que vous payez réellement. Pour un utilisateur normal, une petite différence peut à peine avoir d’importance. En revanche, pour un produit réglementé avec des budgets fixes, des exigences de reporting et des modèles de coûts stricts, l’incertitude répétée peut devenir un problème opérationnel.

C’est pourquoi je pense que la prévisibilité des frais mérite davantage d’attention dans les discussions autour de DuskEVM. La question n’est pas seulement de savoir si les transactions sont bon marché. Il s’agit de savoir si une application peut estimer de manière fiable ses coûts de transaction avant de faire évoluer son activité.

Pour la finance réglementée, la prévisibilité peut être presque aussi importante que le montant absolu des frais lui-même. C’est un test de conception intéressant pour Dusk
#dusk $DUSK @Dusk

#termmax @TermMax
J’ai continué à regarder l’ordre à double fourchette (Two-Way Range Order) de TermMax et, au début, j’ai pensé que ce n’était qu’une autre façon de passer des ordres de prêt ou d’emprunt flexibles. Après avoir creusé le fonctionnement de ces deux courbes, je suis moins convaincu que ce soit aussi simple.

La position peut porter à la fois une courbe d’emprunt et une courbe de prêt. Cela ressemble à un petit choix de conception, mais cela change la façon dont je pense la liquidité. Au lieu de décider à l’avance que mon capital doit être placé d’un seul côté, je fixe en fait des conditions pour les deux directions. Si un côté est exécuté, la position prend ce rôle, tandis que l’autre côté peut rester disponible selon ses propres règles de tarification.

La partie que j’essaie encore de comprendre, c’est l’écart (spread). Un écart plus large entre les courbes d’emprunt et de prêt paraît séduisant sur le papier, mais cela ne signifie pas automatiquement de meilleurs rendements. La probabilité d’exécution (fill probability), l’utilisation, les conditions de collatéral et la rapidité avec laquelle le marché évolue entre ces plages devraient jouer un rôle majeur.

Du coup, la vraie question n’est pas tant de savoir si ces deux courbes sont “ingénieuses”, mais plutôt à quel point elles sont utilisées efficacement dans des marchés réels. Je voudrais observer la répartition des exécutions dans le temps avant de décider dans quelle mesure cet avantage est réellement significatif.
#TermMax

Je remarque constamment que la plupart des discussions autour des partenariats DUSK se concentrent sur NPEX, mais je pense que l’histoire la plus importante réside dans le schéma qui se dessine autour de celui-ci. Quand des noms comme Cordial Systems, 21X et NPEX apparaissent dans la même conversation au sein d’un écosystème, on a l’impression que ce n’est pas simplement une relation commerciale unique, mais plutôt un test visant à déterminer si un même modèle d’infrastructure peut servir plusieurs marchés réglementés.

Ce qui m’intéresse, c’est que chaque participant opère à un endroit différent du paysage des valeurs mobilières numériques, tout en étant confronté à des défis similaires. Les registres de propriété doivent rester exacts après chaque transaction. Les droits de vote, l’éligibilité aux dividendes et le statut de conformité doivent évoluer en continu à mesure que les actifs changent de mains. Comme DUSK le souligne souvent, l’émission de tokens n’est qu’un début. Le vrai défi est de maintenir des registres corrects tout au long du cycle de vie de l’actif.

C’est pourquoi je m’intéresse au réseau grandissant de partenaires plutôt qu’à une annonce isolée. Si plusieurs acteurs de marchés réglementés explorent la même infrastructure, est-ce un signal que l’industrie converge vers un modèle partagé de post-marché ?
#dusk $DUSK @Dusk

#dusk $DUSK @Dusk
Je reviens sans cesse à une question simple : quand les gens disent qu’une transaction est privée, qu’est-ce qu’ils protègent exactement ? La plupart des discussions se concentrent sur la transaction elle-même, mais je pense que certains des risques de confidentialité les plus intéressants apparaissent aux alentours.

Imaginez deux utilisateurs réalisant des transferts confidentiels via Dusk. Les montants, les identités et les détails de la transaction peuvent rester cachés, mais des schémas temporels, la fréquence d’activité des portefeuilles, ou encore les moments où des fonds entrent et sortent d’un environnement confidentiel peuvent toujours révéler des signaux utiles. Pas assez pour tout divulguer, mais parfois suffisamment pour réduire les possibilités. La confidentialité est souvent considérée comme une fonctionnalité unique, alors qu’en pratique, elle ressemble davantage à une chaîne où même la cryptographie la plus robuste peut dépendre de liens comportementaux plus faibles.

C’est une des raisons pour lesquelles je trouve DUSK intéressant. Le défi ne consiste pas seulement à garder les données confidentielles pendant une transaction. Il s’agit aussi de réduire l’information qui fuit avant et après que cette transaction se produit. Un système peut réussir à protéger le contenu, tout en laissant les utilisateurs exposer involontairement le contexte à travers leurs propres habitudes.

Plus j’y pense, plus la confidentialité commence à ressembler moins à une case technique à cocher et davantage à un problème de coordination permanent entre la conception du protocole et le comportement humain. Si l’infrastructure confidentielle continue de s’améliorer, le prochain grand défi en matière de confidentialité viendra-t-il du réseau lui-même, ou des schémas que les utilisateurs laissent derrière eux ?

J’ai remarqué quelque chose d’intéressant dans la campagne actuelle de Binance Square. Beaucoup de gens ne se concentrent que sur les récompenses, mais le classement est fortement influencé par le volume de trading éligible généré grâce aux spectateurs.

C’est pourquoi je surveille de près $DUSK . Le projet construit une infrastructure axée sur la confidentialité pour la finance réglementée, tandis que la campagne récompense une activité de marché réelle plutôt qu’un simple engagement. Les volumes Spot et Futures éligibles sont comptabilisés, ce qui rend la participation davantage liée à un comportement de trading concret.

Je serai en direct aujourd’hui pour parler de $DUSK et de l’activité de marché autour de la campagne. Si vous souhaitez suivre les événements, rejoignez le live et participez à la discussion sur les opportunités de trading à venir et la croissance de l’écosystème.

#dusk $DUSK @Dusk
J’ai commencé à me demander quelque chose qui est rarement mentionné lorsque l’on parle de confidentialité on-chain : combien d’autres transactions se trouvent réellement autour des vôtres ?

Cela peut sembler être un petit détail, mais la confidentialité ne se produit pas en vase clos. Si une transaction privée se trouve au sein d’une foule très réduite, il peut y avoir moins de possibilités pour dissimuler son lien avec l’activité environnante. À mesure que la foule grandit, le nombre de candidats possibles augmente aussi. C’est l’intuition de base derrière l’ensemble d’anonymat.

Imaginez 10 personnes qui quittent la même pièce. S’il n’y en a qu’une qui transporte un certain colis, deviner devient facile. Mettez 1000 personnes dans la pièce et la même observation devient beaucoup moins utile. La technologie n’a pas changé magiquement, mais l’incertitude, elle, a évolué.

Cela rend l’activité réseau intéressante dans la discussion sur la confidentialité autour de Dusk. Phoenix est conçu pour préserver la confidentialité des détails des transactions, mais le résultat global en matière de confidentialité peut encore dépendre du nombre d’utilisateurs et de transactions qui participent au système.

Donc, je ne jugerais pas la confidentialité uniquement en demandant si un protocole cache des données. Je demanderais aussi quelle quantité d’activité réelle entoure ces données dissimulées.

Si l’adoption augmente, la foule qui s’agrandit devient-elle, à son tour, une ressource de confidentialité pour les utilisateurs de Dusk ?

#dusk $DUSK @Dusk
Je me suis surpris à penser à un simple transfert l’autre jour. Sur la plupart des réseaux, la transaction a soit suffisamment de solde et une signature valide, soit elle échoue. La décision est principalement technique. Mais que se passe-t-il lorsque le réseau doit aussi décider, avant même que la transaction soit autorisée, si elle peut l’être ?

C’est cette question qui m’a entraîné plus profondément dans Dusk. Si la logique de conformité fait partie de la couche de transaction, un transfert n’est plus seulement un moyen de déplacer de la valeur d’une adresse à une autre. Il commence à vérifier des conditions avant le règlement. Qui reçoit l’actif ? Est-il éligible ? Le transfert satisfait-il encore aux exigences associées à cet actif ?

Ce que je trouve intéressant, c’est que cela modifie l’endroit où se situe la complexité. Au lieu que la conformité soit gérée après coup par des institutions, une partie de cette responsabilité se rapproche du réseau lui-même. Cela paraît efficace, mais cela crée aussi un défi différent. Les règles changent. Les juridictions changent. Des actifs qui semblent identiques en surface peuvent comporter des restrictions différentes en dessous.

Imaginez un émetteur mettant à jour une exigence qui affecte les transferts futurs sans modifier l’actif lui-même. La transaction semble toujours simple pour l’utilisateur, mais la logique qui la sous-tend devient bien plus compliquée.

Cela me fait me demander si le plus grand test pour l’infrastructure blockchain réglementée est la vitesse des transactions, ou la capacité à maintenir ces règles invisibles gérables pendant qu’elles continuent d’évoluer.

#dusk $DUSK @Dusk
J’ai longtemps supposé que les actions tokenisées deviendraient grand public dès lors que quelqu’un aurait résolu la partie émission. Ces derniers temps, je n’en suis plus aussi sûr.

Créer un token qui représente une part, c’est une étape. Mais suivre tout ce qui se passe ensuite ressemble à de vrais défis. Chaque transaction peut influencer qui est autorisé à voter, qui a droit à un dividende, qui apparaît sur les registres des actionnaires, et si la détention respecte toujours les exigences réglementaires.

Pensez à une action qui change de mains des centaines de fois au cours de quelques mois. La transaction elle-même peut prendre quelques secondes, mais tous les droits attachés à cet actif doivent être transférés correctement, à chaque fois. S’il ne serait-ce qu’une partie de ce processus devient incertaine, le token existe toujours, mais le système qui l’entoure commence à perdre en crédibilité.

C’est pourquoi je trouve la partie « post-trade » plus intéressante que la tokenisation elle-même. Un marché n’est pas seulement constitué d’acheteurs et de vendeurs qui échangent des actifs. C’est un ensemble d’enregistrements de permissions d’obligations et d’historiques de propriété qui doivent rester exacts à mesure que les participants entrent et sortent.

Ce qui a attiré mon attention avec Dusk, c’est sa focalisation sur cette couche moins visible. Beaucoup de projets parlent de mettre des actifs « on-chain ». Il y en a moins qui semblent se concentrer sur la préservation de tout ce qui donne à ces actifs leur signification une fois la transaction terminée.

Si les actions tokenisées passent à l’échelle à l’échelle mondiale, quel problème sera le plus difficile : créer l’actif ou en maintenir l’ensemble du cycle de vie ?