Binance Square
하은
49 Publications

하은

8 Suivis
24 Abonnés
20 J’aime
Publications
·
--
Le site officiel « confirmation d’une émission de plus de 300 millions d’euros » n’est pas un montant de transaction Sur le site officiel de Dusk, il est indiqué « plus de 300 millions d’euros d’émission confirmée ». C’est un repère important, mais il est très facile de le réécrire en « 300 millions d’euros sont déjà finalisés sur la chaîne », « un TVL a déjà été constitué » ou encore « des revenus ont déjà été générés ». Le choix de mots du site officiel est « confirmed issuance » : l’interprétation la plus sûre est donc un volume d’émission déjà confirmé, et il ne faut pas l’étendre à la transaction, au règlement ou aux positions actives. Un actif passe de l’émission confirmée à la formation de sa valeur de marché par plusieurs étapes : émission effective, souscription des investisseurs, livraison des fonds, transactions sur le marché secondaire et services pendant la période de détention. À chaque étape, les chiffres peuvent être différents. Si l’on assimile directement le volume le plus en amont à l’issue la plus en aval, le lecteur ne saura plus si Dusk prouve l’offre d’actifs, ou s’il prouve déjà une utilisation continue. Je vais répartir les données suivantes en quatre colonnes : volume d’émission confirmée, volume réellement déployé/constaté on-chain, montant des souscriptions déjà réglées, transactions sur le marché secondaire et activité des détenteurs. Plus ces quatre chiffres sont proches, plus la conversion est solide ; plus l’écart est grand, plus il faut expliquer où se situent les blocages. La signification des indicateurs du site officiel est d’offrir à Dusk un point de départ concret pour l’entrée dans des actifs réels, et non de permettre de « rendre son devoir » pour toutes les étapes ultérieures en avance. Garder les termes d’origine, qui peuvent sembler prudents, permet en réalité de donner une place claire à chaque nouvelle avancée. Il faut aussi harmoniser la date d’évaluation des actifs et la manière de présenter la devise. L’émission confirmée peut être calculée selon la valeur nominale, l’ampleur visée ou le montant promis ; tandis que la transaction correspond à l’action de marché réellement réalisée. Les deux ne peuvent pas être additionnés directement par nature. À l’avenir, si le site officiel définit et met à jour chaque indicateur, les lecteurs pourront distinguer les nouveaux éléments, les ajustements de volume et la véritable conversion, sans compter deux fois le même actif. @Dusk_Foundation $DUSK #dusk
Le site officiel « confirmation d’une émission de plus de 300 millions d’euros » n’est pas un montant de transaction
Sur le site officiel de Dusk, il est indiqué « plus de 300 millions d’euros d’émission confirmée ». C’est un repère important, mais il est très facile de le réécrire en « 300 millions d’euros sont déjà finalisés sur la chaîne », « un TVL a déjà été constitué » ou encore « des revenus ont déjà été générés ». Le choix de mots du site officiel est « confirmed issuance » : l’interprétation la plus sûre est donc un volume d’émission déjà confirmé, et il ne faut pas l’étendre à la transaction, au règlement ou aux positions actives.
Un actif passe de l’émission confirmée à la formation de sa valeur de marché par plusieurs étapes : émission effective, souscription des investisseurs, livraison des fonds, transactions sur le marché secondaire et services pendant la période de détention. À chaque étape, les chiffres peuvent être différents. Si l’on assimile directement le volume le plus en amont à l’issue la plus en aval, le lecteur ne saura plus si Dusk prouve l’offre d’actifs, ou s’il prouve déjà une utilisation continue.
Je vais répartir les données suivantes en quatre colonnes : volume d’émission confirmée, volume réellement déployé/constaté on-chain, montant des souscriptions déjà réglées, transactions sur le marché secondaire et activité des détenteurs. Plus ces quatre chiffres sont proches, plus la conversion est solide ; plus l’écart est grand, plus il faut expliquer où se situent les blocages. La signification des indicateurs du site officiel est d’offrir à Dusk un point de départ concret pour l’entrée dans des actifs réels, et non de permettre de « rendre son devoir » pour toutes les étapes ultérieures en avance. Garder les termes d’origine, qui peuvent sembler prudents, permet en réalité de donner une place claire à chaque nouvelle avancée.
Il faut aussi harmoniser la date d’évaluation des actifs et la manière de présenter la devise. L’émission confirmée peut être calculée selon la valeur nominale, l’ampleur visée ou le montant promis ; tandis que la transaction correspond à l’action de marché réellement réalisée. Les deux ne peuvent pas être additionnés directement par nature. À l’avenir, si le site officiel définit et met à jour chaque indicateur, les lecteurs pourront distinguer les nouveaux éléments, les ajustements de volume et la véritable conversion, sans compter deux fois le même actif.
@Dusk $DUSK #dusk
·
--
Voir la traduction
把panic改成结构化错误,保护的是整个节点而不只是一笔坏交易 我判断一段密码学代码是否成熟,会特别看它怎样面对错误输入。能够正确处理正常数据只是第一步;面对截断、畸形或故意构造的数据时,是返回一个可分类错误,还是直接panic让进程展开,决定了攻击影响会停在一笔请求,还是扩大到整个服务。Dusk本周为Phoenix Core的错误逐项补齐到Dusk Bytes结果的映射,并把可达的unwind路径替换成结构化错误,这属于典型的“失败也要可控”。 结构化错误的价值不只是日志更好看。节点收到一份无效数据后,可以根据错误类型拒绝、计数、限速或标记来源;钱包则能告诉用户是长度错误、解密失败还是格式不支持。如果所有异常都变成同一个崩溃,运维系统只能看到进程退出,既无法区分恶意输入与普通损坏,也容易在自动重启后重复触发同一问题。 更值得注意的是错误映射必须完整。底层库新增一个错误分支,上层若用通配符草率处理,可能把本应拒绝的情况吞掉,或把内部细节暴露给外部。较稳妥的做法是枚举Phoenix Core每个可达错误,定义对应的Dusk Bytes结果,并用测试确认没有路径越过边界触发panic。对不可信输入,还要先做长度与格式检查,再进入昂贵的解密或曲线运算。 当然,“不崩溃”不等于输入有效,也不意味着旧的Phoenix交易重新开放。Boreas之后,主网已在指定边界停止接受新的Phoenix交易,但节点仍需保留历史解码与执行能力,才能同步和重放旧区块。 所以我认为@Dusk_Foundation 这次错误处理加固,真正保护的是网络的故障半径。金融基础设施无法保证永远看不到坏数据,却可以保证坏数据只得到一个明确拒绝,而不会把无关用户一起拖下线。 @Dusk_Foundation $DUSK #dusk
把panic改成结构化错误,保护的是整个节点而不只是一笔坏交易

我判断一段密码学代码是否成熟,会特别看它怎样面对错误输入。能够正确处理正常数据只是第一步;面对截断、畸形或故意构造的数据时,是返回一个可分类错误,还是直接panic让进程展开,决定了攻击影响会停在一笔请求,还是扩大到整个服务。Dusk本周为Phoenix Core的错误逐项补齐到Dusk Bytes结果的映射,并把可达的unwind路径替换成结构化错误,这属于典型的“失败也要可控”。

结构化错误的价值不只是日志更好看。节点收到一份无效数据后,可以根据错误类型拒绝、计数、限速或标记来源;钱包则能告诉用户是长度错误、解密失败还是格式不支持。如果所有异常都变成同一个崩溃,运维系统只能看到进程退出,既无法区分恶意输入与普通损坏,也容易在自动重启后重复触发同一问题。

更值得注意的是错误映射必须完整。底层库新增一个错误分支,上层若用通配符草率处理,可能把本应拒绝的情况吞掉,或把内部细节暴露给外部。较稳妥的做法是枚举Phoenix Core每个可达错误,定义对应的Dusk Bytes结果,并用测试确认没有路径越过边界触发panic。对不可信输入,还要先做长度与格式检查,再进入昂贵的解密或曲线运算。

当然,“不崩溃”不等于输入有效,也不意味着旧的Phoenix交易重新开放。Boreas之后,主网已在指定边界停止接受新的Phoenix交易,但节点仍需保留历史解码与执行能力,才能同步和重放旧区块。

所以我认为@Dusk 这次错误处理加固,真正保护的是网络的故障半径。金融基础设施无法保证永远看不到坏数据,却可以保证坏数据只得到一个明确拒绝,而不会把无关用户一起拖下线。

@Dusk $DUSK #dusk
·
--
NPEX n’apporte pas seulement une série de chiffres sur la taille des actifs Quand on voit la collaboration entre Dusk et NPEX, beaucoup de gens remarquent d’abord les montants : NPEX prévoit de faire inscrire plus de 200 millions d’euros d’actifs en chaîne grâce à Dusk, et la page d’accueil de Dusk indique en plus un volume d’émission confirmé par des institutions dépassant 300 millions d’euros. Mais ce qui m’intéresse davantage, ce sont les significations distinctes de ces chiffres, plutôt que de les additionner directement pour créer un chiffre de communication plus grand. NPEX est une plateforme de négociation réglementée par l’Autorité néerlandaise des marchés financiers. Elle dispose des qualifications liées aux services de MTF, de courtage et de financement participatif, et s’appuie sur une base d’investisseurs existante de plus de 20 000 personnes. Ce qu’elle peut apporter, c’est son réseau de l’émetteur vers les investisseurs, son expérience d’exploitation de marché, ainsi que ses responsabilités d’accès et de divulgation. Dusk, de son côté, apporte une autre partie : l’infrastructure on-chain nécessaire pour des titres programmables, une divulgation sélective, l’exécution des règles de négociation et un règlement déterministe. Ces deux rôles ne peuvent pas se substituer l’un à l’autre. Un réseau technique ne se voit pas automatiquement attribuer une licence pour exploiter un marché simplement parce qu’il a écrit une logique de conformité, et une institution agréée n’obtient pas non plus naturellement un cycle de vie efficace pour les actifs numériques du simple fait qu’elle a des clients. La valeur de la coopération réside précisément dans le fait de relier l’autorisation et la capacité de distribution de la finance réelle à la capacité de propriété et de règlement on-chain. Je n’écrirai pas non plus par erreur « émission confirmée » comme si elle était déjà inscrite en chaîne, ni comme un TVL en temps réel, ni comme un volume de transactions déjà généré. Cela indique d’abord qu’il existe une intention d’approvisionnement d’actifs de niveau institutionnel et une voie de mise en œuvre ; ensuite, il faudra encore examiner la structure juridique de chaque produit, le rythme d’émission, l’éligibilité des investisseurs et les conditions de négociation. Pour Dusk, ce qui mérite vraiment d’être suivi n’est pas de savoir si les chiffres peuvent encore augmenter, mais si ces plans traversent progressivement l’ensemble du processus : émission, détention, opérations sur la société, puis transactions sur le marché secondaire. Concrètement pour NPEX, je voudrais surtout voir un cas d’actif qui passe de l’annonce à la première souscription, puis à la première cession ou au premier versement d’intérêts. Ce scénario continu permet de valider simultanément les trois volets : l’exploitation agréée, la distribution des investisseurs et le règlement de Dusk, ce qui explique mieux les capacités déjà véritablement connectées des deux parties que l’ajout d’un autre nom de collaboration. @Dusk_Foundation $DUSK #dusk
NPEX n’apporte pas seulement une série de chiffres sur la taille des actifs

Quand on voit la collaboration entre Dusk et NPEX, beaucoup de gens remarquent d’abord les montants : NPEX prévoit de faire inscrire plus de 200 millions d’euros d’actifs en chaîne grâce à Dusk, et la page d’accueil de Dusk indique en plus un volume d’émission confirmé par des institutions dépassant 300 millions d’euros. Mais ce qui m’intéresse davantage, ce sont les significations distinctes de ces chiffres, plutôt que de les additionner directement pour créer un chiffre de communication plus grand.

NPEX est une plateforme de négociation réglementée par l’Autorité néerlandaise des marchés financiers. Elle dispose des qualifications liées aux services de MTF, de courtage et de financement participatif, et s’appuie sur une base d’investisseurs existante de plus de 20 000 personnes. Ce qu’elle peut apporter, c’est son réseau de l’émetteur vers les investisseurs, son expérience d’exploitation de marché, ainsi que ses responsabilités d’accès et de divulgation. Dusk, de son côté, apporte une autre partie : l’infrastructure on-chain nécessaire pour des titres programmables, une divulgation sélective, l’exécution des règles de négociation et un règlement déterministe.

Ces deux rôles ne peuvent pas se substituer l’un à l’autre. Un réseau technique ne se voit pas automatiquement attribuer une licence pour exploiter un marché simplement parce qu’il a écrit une logique de conformité, et une institution agréée n’obtient pas non plus naturellement un cycle de vie efficace pour les actifs numériques du simple fait qu’elle a des clients. La valeur de la coopération réside précisément dans le fait de relier l’autorisation et la capacité de distribution de la finance réelle à la capacité de propriété et de règlement on-chain.

Je n’écrirai pas non plus par erreur « émission confirmée » comme si elle était déjà inscrite en chaîne, ni comme un TVL en temps réel, ni comme un volume de transactions déjà généré. Cela indique d’abord qu’il existe une intention d’approvisionnement d’actifs de niveau institutionnel et une voie de mise en œuvre ; ensuite, il faudra encore examiner la structure juridique de chaque produit, le rythme d’émission, l’éligibilité des investisseurs et les conditions de négociation. Pour Dusk, ce qui mérite vraiment d’être suivi n’est pas de savoir si les chiffres peuvent encore augmenter, mais si ces plans traversent progressivement l’ensemble du processus : émission, détention, opérations sur la société, puis transactions sur le marché secondaire.

Concrètement pour NPEX, je voudrais surtout voir un cas d’actif qui passe de l’annonce à la première souscription, puis à la première cession ou au premier versement d’intérêts. Ce scénario continu permet de valider simultanément les trois volets : l’exploitation agréée, la distribution des investisseurs et le règlement de Dusk, ce qui explique mieux les capacités déjà véritablement connectées des deux parties que l’ajout d’un autre nom de collaboration.
@Dusk $DUSK #dusk
·
--
Perte de votre portefeuille : la propriété ne peut pas disparaître avec les phrases mnémoniques La self-custody est souvent résumée par « celui qui détient la clé privée détient les actifs », mais cette formule appliquée telle quelle à des titres réglementés pose des problèmes concrets. Les titres représentent des droits juridiques qui continuent d’exister ; le fait de changer d’appareil, que le portefeuille soit endommagé ou que des clés soient perdues ne devrait pas faire évaporer automatiquement et définitivement les actions et les créances obligataires. La restauration des droits doit s’inscrire dans un modèle opérationnel. Mais le mécanisme de restauration ne peut pas se réduire à une réinitialisation du support client. Si une plateforme peut transférer les actifs vers une nouvelle adresse sur la seule base d’un e-mail, un attaquant pourrait aussi emprunter le même chemin pour s’emparer d’une position légitime. Un processus complet nécessite au minimum une nouvelle vérification d’identité, la mise en gel des anciens justificatifs, une période d’attente ou d’opposition, la liaison du nouveau portefeuille, et un enregistrement pouvant être confirmé conjointement par l’émetteur, les lieux de négociation et les auditeurs. Les exigences de confidentialité impliquent aussi que toutes ces preuves ne peuvent pas être rendues publiques. La Citadel de Dusk, la divulgation sélective et les flux de travail d’actifs contrôlés constituent une piste technique pour « prouver qu’on est toujours le détenteur légitime, sans divulguer toutes les données d’identité ». En fin de compte, qui approuve le rétablissement du droit, comment une restauration erronée peut être annulée, et si l’ancien portefeuille peut encore voter ou percevoir des revenus doivent être déterminés par les arrangements concrets du produit et du droit. La blockchain fournit un état certain, mais elle ne peut pas deviner ce qui arrive aux personnes dans le monde réel. Le processus de restauration devrait idéalement inclure une période d’attente et des rappels multi-canal. Les détenteurs légitimes disposent ainsi de temps pour empêcher une demande usurpée, et l’émetteur peut vérifier s’il existe des transactions non réglées. Mais l’attente ne peut pas être prolongée indéfiniment : si les actifs doivent être transférés ou rachetés rapidement, le mécanisme de restauration lui-même créerait alors un nouveau risque de liquidité. C’est pourquoi, pour moi, l’expérience de l’investisseur de @Dusk_Foundation ne se limite pas à la facilité de connexion initiale au portefeuille. Je veux surtout voir des exercices de restauration en cas de perte, de changement de liaison et de litige. La self-custody adaptée à des actifs financiers de long terme n’est pas celle qui refuse la restauration à tout jamais : c’est celle qui impose des barrières, fournit des preuves, et n’expose pas l’identité complète d’une personne à des observateurs non concernés. Une fois la restauration terminée, les droits de vote, de transfert et de perception des revenus de l’ancienne adresse devraient aussi s’arrêter simultanément, afin d’éviter qu’un même droit se retrouve contrôlé par deux entrées distinctes. @Dusk_Foundation $DUSK #dusk
Perte de votre portefeuille : la propriété ne peut pas disparaître avec les phrases mnémoniques

La self-custody est souvent résumée par « celui qui détient la clé privée détient les actifs », mais cette formule appliquée telle quelle à des titres réglementés pose des problèmes concrets. Les titres représentent des droits juridiques qui continuent d’exister ; le fait de changer d’appareil, que le portefeuille soit endommagé ou que des clés soient perdues ne devrait pas faire évaporer automatiquement et définitivement les actions et les créances obligataires. La restauration des droits doit s’inscrire dans un modèle opérationnel.

Mais le mécanisme de restauration ne peut pas se réduire à une réinitialisation du support client. Si une plateforme peut transférer les actifs vers une nouvelle adresse sur la seule base d’un e-mail, un attaquant pourrait aussi emprunter le même chemin pour s’emparer d’une position légitime. Un processus complet nécessite au minimum une nouvelle vérification d’identité, la mise en gel des anciens justificatifs, une période d’attente ou d’opposition, la liaison du nouveau portefeuille, et un enregistrement pouvant être confirmé conjointement par l’émetteur, les lieux de négociation et les auditeurs. Les exigences de confidentialité impliquent aussi que toutes ces preuves ne peuvent pas être rendues publiques.

La Citadel de Dusk, la divulgation sélective et les flux de travail d’actifs contrôlés constituent une piste technique pour « prouver qu’on est toujours le détenteur légitime, sans divulguer toutes les données d’identité ». En fin de compte, qui approuve le rétablissement du droit, comment une restauration erronée peut être annulée, et si l’ancien portefeuille peut encore voter ou percevoir des revenus doivent être déterminés par les arrangements concrets du produit et du droit. La blockchain fournit un état certain, mais elle ne peut pas deviner ce qui arrive aux personnes dans le monde réel.

Le processus de restauration devrait idéalement inclure une période d’attente et des rappels multi-canal. Les détenteurs légitimes disposent ainsi de temps pour empêcher une demande usurpée, et l’émetteur peut vérifier s’il existe des transactions non réglées. Mais l’attente ne peut pas être prolongée indéfiniment : si les actifs doivent être transférés ou rachetés rapidement, le mécanisme de restauration lui-même créerait alors un nouveau risque de liquidité.

C’est pourquoi, pour moi, l’expérience de l’investisseur de @Dusk ne se limite pas à la facilité de connexion initiale au portefeuille. Je veux surtout voir des exercices de restauration en cas de perte, de changement de liaison et de litige. La self-custody adaptée à des actifs financiers de long terme n’est pas celle qui refuse la restauration à tout jamais : c’est celle qui impose des barrières, fournit des preuves, et n’expose pas l’identité complète d’une personne à des observateurs non concernés. Une fois la restauration terminée, les droits de vote, de transfert et de perception des revenus de l’ancienne adresse devraient aussi s’arrêter simultanément, afin d’éviter qu’un même droit se retrouve contrôlé par deux entrées distinctes.

@Dusk $DUSK #dusk
·
--
Une licence ECSP, à faire passer successivement par trois portes d’état Dusk prévoit d’utiliser l’ECSP comme nouvel axe d’activité, mais pour savoir où mène cette démarche, il ne faut pas se contenter des deux mots « licence ». La première porte correspond au dépôt de demande : cela signifie que l’équipe a déjà choisi la voie réglementaire et prépare les documents. La deuxième porte est l’autorisation officielle de l’autorité de régulation : cela veut dire que le demandeur a passé les contrôles correspondants. La troisième porte, seulement, permet d’exploiter dans le périmètre de la licence : les produits de l’entreprise, l’accès des investisseurs et les processus de la plateforme peuvent enfin fonctionner concrètement. Les trois portes renvoient à trois catégories de preuves entièrement différentes. Au stade de la demande, il faut voir les éléments de soumission officiels ; au stade de l’autorisation, il faut vérifier l’enregistrement ou la décision de la régulation ; au stade de l’exploitation, il faut constater l’ouverture de la plateforme, le lancement de produits conformes et les résultats de financement réels. Les annonces du projet peuvent expliquer l’orientation, mais ne peuvent pas remplacer les enregistrements publics ; obtenir l’autorisation atteste la capacité d’exploitation, mais ne peut pas remplacer la première opération. Réduire ces trois niveaux à une seule phrase « Dusk possède l’ECSP » ferait perdre le « calibrage » de la progression à venir. Même une fois entré dans l’exploitation, le périmètre de la licence doit être vérifié point par point : quel entité juridique détient la licence, quelles régions et quels outils sont couverts, quels rôles la plateforme assume (distribution, mise en relation, ou autre), et comment la protection des investisseurs se concrétise. Les prêts, les actions et les obligations ne correspondent pas au même workflow ; et l’exécution on-chain ne peut pas automatiquement élargir les frontières de la licence. Ainsi, la route @Dusk_Foundation mérite surtout d’être suivie non pas comme un titre ponctuel, mais comme une chaîne de preuves continue : la demande est confirmée, l’autorisation est consultable, le produit est utilisable, le financement peut aboutir, les revenus peuvent être rapportés. L’usage actuel du Gas et des mises en gage de $DUSK peut exister séparément ; les usages additionnels apportés par l’ECSP, eux, doivent être calculés seulement après que des transactions déclenchées par une activité réelle auront eu lieu. En gardant les portes d’état, on n’amoindrit pas l’élan de l’équipe, et on n’inscrit pas trop tôt dans les résultats le futur en construction. Les quatre niveaux d’état devraient aussi chacun indiquer une date et une source de preuve, afin d’éviter qu’anciennes annonces soient reprises indéfiniment comme si elles constituaient de nouveaux progrès. Tant que la chronologie publique reste cohérente, la communauté peut elle-même juger de la vitesse d’avancement. @Dusk_Foundation $DUSK #dusk
Une licence ECSP, à faire passer successivement par trois portes d’état

Dusk prévoit d’utiliser l’ECSP comme nouvel axe d’activité, mais pour savoir où mène cette démarche, il ne faut pas se contenter des deux mots « licence ». La première porte correspond au dépôt de demande : cela signifie que l’équipe a déjà choisi la voie réglementaire et prépare les documents. La deuxième porte est l’autorisation officielle de l’autorité de régulation : cela veut dire que le demandeur a passé les contrôles correspondants. La troisième porte, seulement, permet d’exploiter dans le périmètre de la licence : les produits de l’entreprise, l’accès des investisseurs et les processus de la plateforme peuvent enfin fonctionner concrètement.

Les trois portes renvoient à trois catégories de preuves entièrement différentes. Au stade de la demande, il faut voir les éléments de soumission officiels ; au stade de l’autorisation, il faut vérifier l’enregistrement ou la décision de la régulation ; au stade de l’exploitation, il faut constater l’ouverture de la plateforme, le lancement de produits conformes et les résultats de financement réels. Les annonces du projet peuvent expliquer l’orientation, mais ne peuvent pas remplacer les enregistrements publics ; obtenir l’autorisation atteste la capacité d’exploitation, mais ne peut pas remplacer la première opération. Réduire ces trois niveaux à une seule phrase « Dusk possède l’ECSP » ferait perdre le « calibrage » de la progression à venir.

Même une fois entré dans l’exploitation, le périmètre de la licence doit être vérifié point par point : quel entité juridique détient la licence, quelles régions et quels outils sont couverts, quels rôles la plateforme assume (distribution, mise en relation, ou autre), et comment la protection des investisseurs se concrétise. Les prêts, les actions et les obligations ne correspondent pas au même workflow ; et l’exécution on-chain ne peut pas automatiquement élargir les frontières de la licence.

Ainsi, la route @Dusk mérite surtout d’être suivie non pas comme un titre ponctuel, mais comme une chaîne de preuves continue : la demande est confirmée, l’autorisation est consultable, le produit est utilisable, le financement peut aboutir, les revenus peuvent être rapportés. L’usage actuel du Gas et des mises en gage de $DUSK peut exister séparément ; les usages additionnels apportés par l’ECSP, eux, doivent être calculés seulement après que des transactions déclenchées par une activité réelle auront eu lieu. En gardant les portes d’état, on n’amoindrit pas l’élan de l’équipe, et on n’inscrit pas trop tôt dans les résultats le futur en construction.

Les quatre niveaux d’état devraient aussi chacun indiquer une date et une source de preuve, afin d’éviter qu’anciennes annonces soient reprises indéfiniment comme si elles constituaient de nouveaux progrès. Tant que la chronologie publique reste cohérente, la communauté peut elle-même juger de la vitesse d’avancement.

@Dusk $DUSK #dusk
·
--
Je pensais que je comprenais “la tokenisation des actifs” trop simplement, jusqu’à ce que je demande qui est le véritable registre final. Auparavant, je pensais qu’une entreprise n’avait qu’à transformer des actions ou des obligations en Tokens sur une blockchain : une fois la tokenisation faite, c’était bon. En relisant récemment les documents de Dusk sur les PME et l’émission native, j’ai compris que le vrai problème — c’est la difficulté : si les soldes on-chain, le registre des émetteurs et les droits juridiques existent en même temps, en cas de conflit, quelle version fait foi ? La tokenisation traditionnelle consiste souvent à ajouter une correspondance numérique à côté de l’actif existant. Le système hors chaîne continue de déterminer l’admissibilité des investisseurs, les registres de propriété, les dividendes et les rachats ; le Token on-chain sert à distribuer ou transférer. Tant que les deux côtés restent constamment cohérents, cette approche peut fonctionner. Mais dès qu’il y a un mauvais transfert, un retard dans le registre ou une injonction du tribunal, il faut alors faire une réconciliation supplémentaire et établir quelle entrée fait autorité. L’émission native vise à faire partager par davantage de cycles de vie un même état contrôlé : l’admissibilité est vérifiée avant la souscription ou le transfert, la relation entre l’émission et la détention est mise à jour en synchronisation, et les dividendes, le vote, les restrictions et la compensation reposent sur le même actif.@Dusk_Foundation apporte confidentialité, divulgation sélective, règlement déterministe et règles programmables, mais la technologie elle-même ne donne pas automatiquement l’autorisation aux émetteurs, ni n’attribue d’effet juridique aux Tokens. Cette différence se traduit très concrètement pour l’utilisateur. Le détenteur doit savoir s’il reçoit de véritables droits sous-jacents, un miroir de droits hors chaîne, ou seulement des titres destinés à un usage interne de la plateforme. L’émetteur, lui, doit expliquer comment corriger les erreurs, comment l’actif est mis fin, et qui peut — légalement — geler ou réactiver. Sans ces réponses, le “native” n’est qu’une méthode de frappe plus avancée. Désormais, pour juger si une émission est vraiment “on-chain”, je raisonne à partir du moment de sortie : lors du rachat à l’échéance, les fonds arrivent-ils, l’actif est-il désenregistré et la trace du détenteur peut-elle se boucler en une seule fois ? En cas de litige, peut-on aussi retrouver le responsable en suivant la même règle ?$DUSK peut fournir l’infrastructure pour l’émission native ; ce qui détermine si elle devient un véritable instrument financier, c’est si l’état on-chain peut être reconnu collectivement — par la loi, l’exploitation et les participants. Donc, la prochaine fois que je verrai un nouvel actif arriver, je chercherai d’abord comment le registre fait foi, comment s’exerce le pouvoir de correction et comment les entreprises agissent ; si ces trois points ne sont pas clairs, le token n’est qu’une ombre de l’actif. @Dusk_Foundation $DUSK #dusk
Je pensais que je comprenais “la tokenisation des actifs” trop simplement, jusqu’à ce que je demande qui est le véritable registre final.

Auparavant, je pensais qu’une entreprise n’avait qu’à transformer des actions ou des obligations en Tokens sur une blockchain : une fois la tokenisation faite, c’était bon. En relisant récemment les documents de Dusk sur les PME et l’émission native, j’ai compris que le vrai problème — c’est la difficulté : si les soldes on-chain, le registre des émetteurs et les droits juridiques existent en même temps, en cas de conflit, quelle version fait foi ?

La tokenisation traditionnelle consiste souvent à ajouter une correspondance numérique à côté de l’actif existant. Le système hors chaîne continue de déterminer l’admissibilité des investisseurs, les registres de propriété, les dividendes et les rachats ; le Token on-chain sert à distribuer ou transférer. Tant que les deux côtés restent constamment cohérents, cette approche peut fonctionner. Mais dès qu’il y a un mauvais transfert, un retard dans le registre ou une injonction du tribunal, il faut alors faire une réconciliation supplémentaire et établir quelle entrée fait autorité.

L’émission native vise à faire partager par davantage de cycles de vie un même état contrôlé : l’admissibilité est vérifiée avant la souscription ou le transfert, la relation entre l’émission et la détention est mise à jour en synchronisation, et les dividendes, le vote, les restrictions et la compensation reposent sur le même actif.@Dusk apporte confidentialité, divulgation sélective, règlement déterministe et règles programmables, mais la technologie elle-même ne donne pas automatiquement l’autorisation aux émetteurs, ni n’attribue d’effet juridique aux Tokens.

Cette différence se traduit très concrètement pour l’utilisateur. Le détenteur doit savoir s’il reçoit de véritables droits sous-jacents, un miroir de droits hors chaîne, ou seulement des titres destinés à un usage interne de la plateforme. L’émetteur, lui, doit expliquer comment corriger les erreurs, comment l’actif est mis fin, et qui peut — légalement — geler ou réactiver. Sans ces réponses, le “native” n’est qu’une méthode de frappe plus avancée.

Désormais, pour juger si une émission est vraiment “on-chain”, je raisonne à partir du moment de sortie : lors du rachat à l’échéance, les fonds arrivent-ils, l’actif est-il désenregistré et la trace du détenteur peut-elle se boucler en une seule fois ? En cas de litige, peut-on aussi retrouver le responsable en suivant la même règle ?$DUSK peut fournir l’infrastructure pour l’émission native ; ce qui détermine si elle devient un véritable instrument financier, c’est si l’état on-chain peut être reconnu collectivement — par la loi, l’exploitation et les participants.

Donc, la prochaine fois que je verrai un nouvel actif arriver, je chercherai d’abord comment le registre fait foi, comment s’exerce le pouvoir de correction et comment les entreprises agissent ; si ces trois points ne sont pas clairs, le token n’est qu’une ombre de l’actif.

@Dusk $DUSK #dusk
·
--
Voir la traduction
转走GT时,转移的究竟是资产还是债务 普通NFT转账,接收方得到的是一件资产;GT转账则不能只看“谁拥有它”。这枚ERC-721内部记录抵押品与FT债务,所有权改变的同时,未完成的还款责任、到期日和清算风险也会跟着仓位移动。 最容易出现的是估值错觉。假设GT里锁着价值较高的抵押,钱包若只展示抵押总额,用户可能把它当净资产。实际上应先扣除未偿债务,再考虑抵押能否释放、距离LLTV还有多少空间,以及到期前需要准备哪种资产。 接收方还要面对时间差。仓位创建时的APR已经确定,但GT转手时,外部利率、抵押价格和剩余期限可能完全不同。原持有人觉得值得退出,不代表新持有人接手后仍有相同风险回报,转让价格必须重新反映这张资产负债表。 若未来形成GT二级市场,我希望@termmax 在确认前展示抵押数量、FT债务、净值估算、到期日和关闭路径。双方都能独立复算,GT的可转移性才会变成仓位流动性,而不是把未读懂的债务移动到另一个钱包。能够转走凭证只是技术完成,接收方看清并接受责任才是金融交割。 定价时还要把剩余期限带回模型。同一抵押和债务规模,离到期十天与离到期半年,资金安排和退出空间完全不同。GT交易若只围绕抵押净值报价,却不给时间责任定价,接手方很可能低估真正成本。 因此一笔GT转让的合理回执,应同时记录转让价、当时净值、剩余期限和个人还款计划。日后即使市场变化,也能分清收益来自抵押行情、债务变化还是买入折价,而不是把所有结果混成“NFT涨跌”。 @termmax #TermMax
转走GT时,转移的究竟是资产还是债务

普通NFT转账,接收方得到的是一件资产;GT转账则不能只看“谁拥有它”。这枚ERC-721内部记录抵押品与FT债务,所有权改变的同时,未完成的还款责任、到期日和清算风险也会跟着仓位移动。

最容易出现的是估值错觉。假设GT里锁着价值较高的抵押,钱包若只展示抵押总额,用户可能把它当净资产。实际上应先扣除未偿债务,再考虑抵押能否释放、距离LLTV还有多少空间,以及到期前需要准备哪种资产。

接收方还要面对时间差。仓位创建时的APR已经确定,但GT转手时,外部利率、抵押价格和剩余期限可能完全不同。原持有人觉得值得退出,不代表新持有人接手后仍有相同风险回报,转让价格必须重新反映这张资产负债表。

若未来形成GT二级市场,我希望@TermMax 在确认前展示抵押数量、FT债务、净值估算、到期日和关闭路径。双方都能独立复算,GT的可转移性才会变成仓位流动性,而不是把未读懂的债务移动到另一个钱包。能够转走凭证只是技术完成,接收方看清并接受责任才是金融交割。

定价时还要把剩余期限带回模型。同一抵押和债务规模,离到期十天与离到期半年,资金安排和退出空间完全不同。GT交易若只围绕抵押净值报价,却不给时间责任定价,接手方很可能低估真正成本。

因此一笔GT转让的合理回执,应同时记录转让价、当时净值、剩余期限和个人还款计划。日后即使市场变化,也能分清收益来自抵押行情、债务变化还是买入折价,而不是把所有结果混成“NFT涨跌”。

@TermMax #TermMax
·
--
Pourquoi la courbe des ordres est plus intéressante que « le rendement le plus élevé » Le rendement le plus élevé ne vous dit que la portion la plus chère de la courbe ; c’est toute la courbe qui vous indique combien de fonds le marché est prêt à payer pour quel prix. Si un ordre ne présente que de très petites quantités qui restent à un APR élevé, le prendre comme représentatif de l’ensemble du marché conduit facilement à surestimer les opportunités réelles. Le Range Order de @termmax lie le taux d’intérêt et la quantité : le teneur de marché ne se contente pas de soumettre un taux annualisé, il détermine quelles conditions s’appliquent à différentes profondeurs de liquidité. À mesure que les ordres se remplissent, les fonds suivants peuvent tomber sur une autre tranche de taux. Pour les prêteurs, cela exprime une compensation du risque ; pour les emprunteurs, cela met directement en évidence le coût marginal de l’augmentation de la taille. Je préfère comprendre un marché sain des échéances comme une courbe « épaisse », capable d’être alimentée en continu, plutôt que des pics qui se rafraîchissent sans cesse sur la page d’accueil. Pour évaluer, on peut poser trois questions : le taux élevé couvre-t-il une quantité significative, est-ce que les cotations se rétablissent après la transaction, et les courbes de plusieurs teneurs de marché se chevauchent-elles pour créer de la concurrence. Si toutes les réponses sont non, le rendement le plus élevé ressemble davantage à un échantillon isolé. Si TermMax peut transformer un taux fixe en véritable marché dépend du fait que la courbe puisse supporter des transactions continues, plutôt que de n’apparaître qu’occasionnellement avec un chiffre suffisamment accrocheur. On peut aussi observer si un APR élevé est rapidement rempli, ou s’il reste longtemps sans demande. Le premier cas peut indiquer que la demande est réelle et que la capacité est limitée ; le second peut signifier que les conditions de risque ou les échéances ne sont pas particulièrement appréciées. Une capture d’écran ne conserve qu’un instant ; c’est la trajectoire de l’exécution qui montre si cette portion de courbe est validée par le marché. En mettant ensemble le prix, la quantité et le temps, un rendement élevé obtient son contexte. @termmax #TermMax
Pourquoi la courbe des ordres est plus intéressante que « le rendement le plus élevé »

Le rendement le plus élevé ne vous dit que la portion la plus chère de la courbe ; c’est toute la courbe qui vous indique combien de fonds le marché est prêt à payer pour quel prix. Si un ordre ne présente que de très petites quantités qui restent à un APR élevé, le prendre comme représentatif de l’ensemble du marché conduit facilement à surestimer les opportunités réelles.

Le Range Order de @TermMax lie le taux d’intérêt et la quantité : le teneur de marché ne se contente pas de soumettre un taux annualisé, il détermine quelles conditions s’appliquent à différentes profondeurs de liquidité. À mesure que les ordres se remplissent, les fonds suivants peuvent tomber sur une autre tranche de taux. Pour les prêteurs, cela exprime une compensation du risque ; pour les emprunteurs, cela met directement en évidence le coût marginal de l’augmentation de la taille.

Je préfère comprendre un marché sain des échéances comme une courbe « épaisse », capable d’être alimentée en continu, plutôt que des pics qui se rafraîchissent sans cesse sur la page d’accueil. Pour évaluer, on peut poser trois questions : le taux élevé couvre-t-il une quantité significative, est-ce que les cotations se rétablissent après la transaction, et les courbes de plusieurs teneurs de marché se chevauchent-elles pour créer de la concurrence. Si toutes les réponses sont non, le rendement le plus élevé ressemble davantage à un échantillon isolé. Si TermMax peut transformer un taux fixe en véritable marché dépend du fait que la courbe puisse supporter des transactions continues, plutôt que de n’apparaître qu’occasionnellement avec un chiffre suffisamment accrocheur.

On peut aussi observer si un APR élevé est rapidement rempli, ou s’il reste longtemps sans demande. Le premier cas peut indiquer que la demande est réelle et que la capacité est limitée ; le second peut signifier que les conditions de risque ou les échéances ne sont pas particulièrement appréciées. Une capture d’écran ne conserve qu’un instant ; c’est la trajectoire de l’exécution qui montre si cette portion de courbe est validée par le marché. En mettant ensemble le prix, la quantité et le temps, un rendement élevé obtient son contexte.

@TermMax #TermMax
·
--
La coopération avec Chainlink doit être découpée en trois éléments différents Dans les annonces de partenariat, on voit souvent apparaître Chainlink. Beaucoup de gens traduisent alors directement cela par « Dusk dispose désormais d’un oracle ». Mais CCIP, DataLink et Data Streams ne résolvent pas le même problème. Les regrouper sous un seul logo, c’est manquer l’endroit précis où ce partenariat touche réellement les flux d’actifs réglementés. DataLink s’adresse à la diffusion de données côté institutions : l’objectif est d’apporter des données financières existantes à la blockchain de manière vérifiable ; Data Streams est plus proche de la livraison de données à faible latence et convient aux applications qui doivent mettre à jour rapidement les prix ou l’état du marché ; CCIP gère quant à lui les messages et les transferts d’actifs entre chaînes, permettant à l’émetteur de configurer des chemins de connexion entre plusieurs réseaux. L’un s’occupe de la source des données, l’autre de la fraîcheur, le troisième de la communication inter-chaînes : si l’un des trois manque, les deux autres ne peuvent pas le compenser automatiquement. Pour l’émetteur, le plus critique n’est pas « est-ce que c’est inter-chaînes », mais « vers où », « combien on peut transférer à chaque fois », « en cas d’anomalie, qui peut mettre en pause », et « qui contrôle la mise à niveau du contrat ». Les documents officiels mentionnent des limites de débit et un contrôle des mises à jour : ces réglages apparemment prudents sont en réalité des dispositifs de sécurité dont les institutions ont besoin. Quand des données erronées, une congestion de la chaîne cible ou un risque lié aux clés surviennent, le système doit pouvoir limiter l’impact, plutôt que continuer à exécuter sans conditions. Le service de données doit aussi répondre à la question du temps. À quel moment la valorisation des titres est-elle calculée ? Si les données sources arrivent en retard, faut-il utiliser la valeur précédente ou suspendre les transactions ? Que faire des ordres déjà exécutés après correction des données ? Tout cela ne peut pas être décidé automatiquement par le simple fait que « l’oracle est connecté ». L’application Dusk doit intégrer, dans ses règles, le horodatage des données, la fréquence de mise à jour et les seuils d’invalidité, afin de savoir quand il est possible de continuer à exécuter. Je vais classer les avancées de @Dusk_Foundation avec Chainlink selon la force des preuves : signer un partenariat n’est qu’un signal faible ; le fait que le service soit utilisable dans un environnement de test constitue un signal plus fort ; et la dépendance d’actifs réels à ces données ou à des messages inter-chaînes pour effectuer la compensation, c’est la preuve directe. La prochaine chose qui mérite d’être rendue publique n’est donc pas un nom de plus pour un partenariat, mais d’où proviennent les données d’une transaction, quand elles sont mises à jour, comment gérer l’échec inter-chaînes et finalement qui confirme le tout. Tant que cette chaîne de preuves est complète, Chainlink pourra passer de simple liste d’infrastructure à une partie du workflow de marché de Dusk. $DUSK #dusk
La coopération avec Chainlink doit être découpée en trois éléments différents

Dans les annonces de partenariat, on voit souvent apparaître Chainlink. Beaucoup de gens traduisent alors directement cela par « Dusk dispose désormais d’un oracle ». Mais CCIP, DataLink et Data Streams ne résolvent pas le même problème. Les regrouper sous un seul logo, c’est manquer l’endroit précis où ce partenariat touche réellement les flux d’actifs réglementés.

DataLink s’adresse à la diffusion de données côté institutions : l’objectif est d’apporter des données financières existantes à la blockchain de manière vérifiable ; Data Streams est plus proche de la livraison de données à faible latence et convient aux applications qui doivent mettre à jour rapidement les prix ou l’état du marché ; CCIP gère quant à lui les messages et les transferts d’actifs entre chaînes, permettant à l’émetteur de configurer des chemins de connexion entre plusieurs réseaux. L’un s’occupe de la source des données, l’autre de la fraîcheur, le troisième de la communication inter-chaînes : si l’un des trois manque, les deux autres ne peuvent pas le compenser automatiquement.

Pour l’émetteur, le plus critique n’est pas « est-ce que c’est inter-chaînes », mais « vers où », « combien on peut transférer à chaque fois », « en cas d’anomalie, qui peut mettre en pause », et « qui contrôle la mise à niveau du contrat ». Les documents officiels mentionnent des limites de débit et un contrôle des mises à jour : ces réglages apparemment prudents sont en réalité des dispositifs de sécurité dont les institutions ont besoin. Quand des données erronées, une congestion de la chaîne cible ou un risque lié aux clés surviennent, le système doit pouvoir limiter l’impact, plutôt que continuer à exécuter sans conditions.

Le service de données doit aussi répondre à la question du temps. À quel moment la valorisation des titres est-elle calculée ? Si les données sources arrivent en retard, faut-il utiliser la valeur précédente ou suspendre les transactions ? Que faire des ordres déjà exécutés après correction des données ? Tout cela ne peut pas être décidé automatiquement par le simple fait que « l’oracle est connecté ». L’application Dusk doit intégrer, dans ses règles, le horodatage des données, la fréquence de mise à jour et les seuils d’invalidité, afin de savoir quand il est possible de continuer à exécuter.

Je vais classer les avancées de @Dusk avec Chainlink selon la force des preuves : signer un partenariat n’est qu’un signal faible ; le fait que le service soit utilisable dans un environnement de test constitue un signal plus fort ; et la dépendance d’actifs réels à ces données ou à des messages inter-chaînes pour effectuer la compensation, c’est la preuve directe. La prochaine chose qui mérite d’être rendue publique n’est donc pas un nom de plus pour un partenariat, mais d’où proviennent les données d’une transaction, quand elles sont mises à jour, comment gérer l’échec inter-chaînes et finalement qui confirme le tout. Tant que cette chaîne de preuves est complète, Chainlink pourra passer de simple liste d’infrastructure à une partie du workflow de marché de Dusk. $DUSK #dusk
·
--
Voir la traduction
MLTV和LLTV不是两个重复参数 TermMax市场同时出现MLTV与LLTV时,最容易产生的误解是:两者都与贷款价值比有关,只记较高的清算线就够了。实际上,一个负责限制仓位如何开始,另一个负责决定仓位何时被处置。两者之间的距离,就是系统为价格波动留下的缓冲区。@termmax #TermMax 缓冲区多大才合适,也没有脱离资产特性的统一答案。高波动抵押品、相关性不稳定的债务组合以及流动性较差的资产,都需要更谨慎的起始LTV。用户若只为了多借一点把仓位推到MLTV附近,相当于用很少的价格空间交换更高的资金使用率。行情平稳时看不出差别,波动到来后,反应时间会迅速缩短。 站在风险参数设置者的位置,“MLTV和LLTV不是两个重复参数”至少需要三步检验:先核对MLTV起点的原始记录,再追踪LLTV触发线经过完整生命周期后的变化,最后查看是否出现缓冲不足。如果只保留关于“MLTV和LLTV不是两个重复参数”的成功交易,结论会高估产品;若部分清算后恢复健康能在不同日期、不同规模和较差市场环境中复现,判断才更接近稳定。这里还要把名义收益与实际资产分开,把等待、滑点、费用和失败后的处理逐项计入,尤其不能让LLTV触发线掩盖尾部结果。经过这套检验,风险参数设置者得到的不只是一篇关于“MLTV和LLTV不是两个重复参数”的观点,而是一套以后仍能使用的决策标准。 评估TermMax市场时,我会把MLTV、LLTV、预言机与抵押品流动性放在一起看。参数不是越宽松越友好,也不是越保守越先进;关键在于缓冲是否与资产风险匹配,以及触发清算后能否找到足够执行者。固定期限解决的是成本规划,MLTV和LLTV共同回答的是:这份规划能不能在价格变化中活到最后。
MLTV和LLTV不是两个重复参数

TermMax市场同时出现MLTV与LLTV时,最容易产生的误解是:两者都与贷款价值比有关,只记较高的清算线就够了。实际上,一个负责限制仓位如何开始,另一个负责决定仓位何时被处置。两者之间的距离,就是系统为价格波动留下的缓冲区。@TermMax #TermMax

缓冲区多大才合适,也没有脱离资产特性的统一答案。高波动抵押品、相关性不稳定的债务组合以及流动性较差的资产,都需要更谨慎的起始LTV。用户若只为了多借一点把仓位推到MLTV附近,相当于用很少的价格空间交换更高的资金使用率。行情平稳时看不出差别,波动到来后,反应时间会迅速缩短。

站在风险参数设置者的位置,“MLTV和LLTV不是两个重复参数”至少需要三步检验:先核对MLTV起点的原始记录,再追踪LLTV触发线经过完整生命周期后的变化,最后查看是否出现缓冲不足。如果只保留关于“MLTV和LLTV不是两个重复参数”的成功交易,结论会高估产品;若部分清算后恢复健康能在不同日期、不同规模和较差市场环境中复现,判断才更接近稳定。这里还要把名义收益与实际资产分开,把等待、滑点、费用和失败后的处理逐项计入,尤其不能让LLTV触发线掩盖尾部结果。经过这套检验,风险参数设置者得到的不只是一篇关于“MLTV和LLTV不是两个重复参数”的观点,而是一套以后仍能使用的决策标准。

评估TermMax市场时,我会把MLTV、LLTV、预言机与抵押品流动性放在一起看。参数不是越宽松越友好,也不是越保守越先进;关键在于缓冲是否与资产风险匹配,以及触发清算后能否找到足够执行者。固定期限解决的是成本规划,MLTV和LLTV共同回答的是:这份规划能不能在价格变化中活到最后。
·
--
Voir la traduction
Hedger为什么同时需要同态加密和零知识证明 零知识证明可以告诉外部“这次计算符合规则”,却不必然说明执行计算的系统从未看过原始数据;同态加密允许在密文上处理信息,却还需要一种方式向别人证明结果确实正确。把两者分开理解,就能看出Hedger并非简单给EVM交易套一层隐藏效果,而是在解决计算保密与结果可信这两个不同问题。 Hedger位于DuskEVM,官方设计使用基于椭圆曲线ElGamal的同态加密,并结合零知识证明。以一笔受限证券转让为例,系统可以在不公开余额和完整持仓的情况下检查资产是否足够,再证明转让满足规则;市场参与者不必看到交易双方的底牌,授权审计角色仍可获得业务所需证据。对机构来说,这种“可核验但不围观”比绝对匿名更接近现实需求。 官方材料还给出轻量电路浏览器端低于2秒的表现,并把机密资产持有、转让与未来混淆订单簿列为能力方向。这个数字说明团队重视用户体验,但不能直接外推到所有设备和复杂证券。身份、地区、额度、白名单和多项证明叠加后,生成时间、Gas与失败恢复都需要真实负载检验。 @Dusk_Foundation 要让Hedger从密码学方案变成市场模块,还必须说明披露治理:谁能申请查看、可以看哪些字段、权限多久失效、访问是否留痕。技术保护数据,制度决定技术何时打开边界。$DUSK #dusk 若能同时守住计算过程的机密、结果的正确以及审查权限的克制,Hedger才真正解决了受监管金融最难兼顾的三件事。 开发者工具也需要跟上。合约编写者应能明确选择哪些变量保持密文、哪些结果公开、哪些证明交给特定角色,并在审计时还原这套选择。否则,隐私能力越强,错误配置越难被普通代码审查发现。
Hedger为什么同时需要同态加密和零知识证明

零知识证明可以告诉外部“这次计算符合规则”,却不必然说明执行计算的系统从未看过原始数据;同态加密允许在密文上处理信息,却还需要一种方式向别人证明结果确实正确。把两者分开理解,就能看出Hedger并非简单给EVM交易套一层隐藏效果,而是在解决计算保密与结果可信这两个不同问题。

Hedger位于DuskEVM,官方设计使用基于椭圆曲线ElGamal的同态加密,并结合零知识证明。以一笔受限证券转让为例,系统可以在不公开余额和完整持仓的情况下检查资产是否足够,再证明转让满足规则;市场参与者不必看到交易双方的底牌,授权审计角色仍可获得业务所需证据。对机构来说,这种“可核验但不围观”比绝对匿名更接近现实需求。

官方材料还给出轻量电路浏览器端低于2秒的表现,并把机密资产持有、转让与未来混淆订单簿列为能力方向。这个数字说明团队重视用户体验,但不能直接外推到所有设备和复杂证券。身份、地区、额度、白名单和多项证明叠加后,生成时间、Gas与失败恢复都需要真实负载检验。

@Dusk 要让Hedger从密码学方案变成市场模块,还必须说明披露治理:谁能申请查看、可以看哪些字段、权限多久失效、访问是否留痕。技术保护数据,制度决定技术何时打开边界。$DUSK #dusk 若能同时守住计算过程的机密、结果的正确以及审查权限的克制,Hedger才真正解决了受监管金融最难兼顾的三件事。

开发者工具也需要跟上。合约编写者应能明确选择哪些变量保持密文、哪些结果公开、哪些证明交给特定角色,并在审计时还原这套选择。否则,隐私能力越强,错误配置越难被普通代码审查发现。
·
--
Voir la traduction
传统浮动借贷的路径很直接:把资产存进池子,利率随利用率持续变化,借款人和出借人只能接受未来成本或收益的不确定。TermMax换了一条路径:先选择期限,再通过订单形成固定利率,成交后把债权、期限价值与抵押仓位映射到相应凭证,用户可以围绕到期现金流做计划。 被移除的是利率每天变化带来的预算焦虑,新增加的是期限、市场深度和提前退出依赖。浮动池通常随时可以按池子条件进出,固定期限资产若想提前离开,需要有人承接FT或使用协议提供的退出路径。哪条路更好,取决于用户更怕利率波动,还是更需要随时流动。 限价单与Range Order解决的是不同问题:前者强调用户控制,后者强调连续深度。二者组合比单独争论哪种模式更优更接近市场实际。 判断订单曲线定价时,我先把市场深度视为弱信号,再看实际成交是否形成直接证据,最后等Range Order留下连续结果。缺失的决定性一层,仍然是利率。 订单曲线定价能否成立,要看成交率、加权利率、滑点与订单复用;未成交订单、有限深度与整笔资金的加权成本仍是不能省略的反证。 @termmax #TermMax
传统浮动借贷的路径很直接:把资产存进池子,利率随利用率持续变化,借款人和出借人只能接受未来成本或收益的不确定。TermMax换了一条路径:先选择期限,再通过订单形成固定利率,成交后把债权、期限价值与抵押仓位映射到相应凭证,用户可以围绕到期现金流做计划。

被移除的是利率每天变化带来的预算焦虑,新增加的是期限、市场深度和提前退出依赖。浮动池通常随时可以按池子条件进出,固定期限资产若想提前离开,需要有人承接FT或使用协议提供的退出路径。哪条路更好,取决于用户更怕利率波动,还是更需要随时流动。

限价单与Range Order解决的是不同问题:前者强调用户控制,后者强调连续深度。二者组合比单独争论哪种模式更优更接近市场实际。

判断订单曲线定价时,我先把市场深度视为弱信号,再看实际成交是否形成直接证据,最后等Range Order留下连续结果。缺失的决定性一层,仍然是利率。

订单曲线定价能否成立,要看成交率、加权利率、滑点与订单复用;未成交订单、有限深度与整笔资金的加权成本仍是不能省略的反证。

@TermMax #TermMax
·
--
Zoom à trois couches S20 --> Pour un utilisateur ordinaire, connecter un wallet n’est qu’un petit geste : la page détecte le wallet, demande un compte, puis l’utilisateur signe une transaction. Mais si chaque application Dusk devait réimplémenter ce processus, les utilisateurs feraient face à des modes d’autorisation différents, et les développeurs devraient maintenir du code répété. En parallèle, l’équipe du wallet aurait aussi du mal à assurer la compatibilité avec chaque point d’entrée. Un problème qui semble relever du front-end finit alors par devenir un frein à l’expansion de l’écosystème. Dusk Connect cherche à standardiser cette étape. L’officiel le présente comme un SDK léger permettant de connecter un wallet pour les applications DuskDS, tout en ouvrant également un aperçu du nouveau Dusk Wallet pour les développeurs. Avec Forge pour construire des contrats, l’application dispose enfin d’un chemin continu d’outils, du contrat jusqu’aux interactions avec le wallet. Ce n’est pas aussi spectaculaire que les preuves de confidentialité, mais cela détermine directement si les développeurs peuvent transformer des capacités fondamentales en produit utilisable par des personnes ordinaires. En allant plus loin, la couche de connexion standard va aussi impacter les applications institutionnelles. La découverte de comptes, les demandes d’autorisation, la signature et la prise en charge des wallets sur plusieurs plateformes—sans interface unifiée—rendent les processus de conformité, la traçabilité des autorisations et le support client encore plus fragmentés. Pourtant, la standardisation implique aussi que la conception de l’interface doit être stable, que les messages d’autorisation doivent être clairs, et que, lorsqu’un wallet rencontre un incident, on puisse identifier qui en est responsable. C’est pourquoi je regarde Dusk Connect : pas seulement la vitesse d’intégration, mais aussi s’il réduit le travail de “recréer des roues” pour chaque application, tout en aidant les utilisateurs à comprendre plus clairement ce qu’ils autorisent. Quand l’infrastructure mûrit, elle n’ajoute souvent pas une fonction grandiose : elle fait simplement en sorte que l’action la plus banale reste identique à chaque point d’entrée.@Dusk_Foundation $DUSK #dusk
Zoom à trois couches S20 -->
Pour un utilisateur ordinaire, connecter un wallet n’est qu’un petit geste : la page détecte le wallet, demande un compte, puis l’utilisateur signe une transaction. Mais si chaque application Dusk devait réimplémenter ce processus, les utilisateurs feraient face à des modes d’autorisation différents, et les développeurs devraient maintenir du code répété. En parallèle, l’équipe du wallet aurait aussi du mal à assurer la compatibilité avec chaque point d’entrée. Un problème qui semble relever du front-end finit alors par devenir un frein à l’expansion de l’écosystème.

Dusk Connect cherche à standardiser cette étape. L’officiel le présente comme un SDK léger permettant de connecter un wallet pour les applications DuskDS, tout en ouvrant également un aperçu du nouveau Dusk Wallet pour les développeurs. Avec Forge pour construire des contrats, l’application dispose enfin d’un chemin continu d’outils, du contrat jusqu’aux interactions avec le wallet. Ce n’est pas aussi spectaculaire que les preuves de confidentialité, mais cela détermine directement si les développeurs peuvent transformer des capacités fondamentales en produit utilisable par des personnes ordinaires.

En allant plus loin, la couche de connexion standard va aussi impacter les applications institutionnelles. La découverte de comptes, les demandes d’autorisation, la signature et la prise en charge des wallets sur plusieurs plateformes—sans interface unifiée—rendent les processus de conformité, la traçabilité des autorisations et le support client encore plus fragmentés. Pourtant, la standardisation implique aussi que la conception de l’interface doit être stable, que les messages d’autorisation doivent être clairs, et que, lorsqu’un wallet rencontre un incident, on puisse identifier qui en est responsable.

C’est pourquoi je regarde Dusk Connect : pas seulement la vitesse d’intégration, mais aussi s’il réduit le travail de “recréer des roues” pour chaque application, tout en aidant les utilisateurs à comprendre plus clairement ce qu’ils autorisent. Quand l’infrastructure mûrit, elle n’ajoute souvent pas une fonction grandiose : elle fait simplement en sorte que l’action la plus banale reste identique à chaque point d’entrée.@Dusk $DUSK #dusk
·
--
En terminant cinq tâches, j’ai au contraire retenu “la date d’échéance” Je n’étais venu(e) que pour faire un Booster. Résultat : après avoir répondu aux cinq questions, ce qui est resté dans mon esprit n’est pas A, B, A, C, A… mais “date d’échéance”, ces trois mots. @termmax Avec un prêt à taux fixe et à durée fixe, la plus grande différence avec les pools de liquidités variables qu’on voit d’habitude, c’est qu’avant d’emprunter, on connaît déjà le coût et aussi le jour exact auquel il faut régler la dette. #TermMax J’ai refait les étapes de l’activité : d’abord, préparer au moins 2 points Alpha avec un wallet sans clé de Binance ; au moment de l’inscription, 2 points sont déduits. Ensuite : suivre le compte officiel sur X, transférer/retweeter la publication de la mission, terminer l’apprentissage, rejoindre Discord, et connecter TermMax V2. Après que les cinq barres sont passées au vert, ne fermez pas la page : la création sur la Place fait partie d’une autre ligne. Les 500 premiers en chinois se partagent 150 000 TMX, clôture le 22 août à 07:59 (UTC+8). Du 24 août à 11:00 au 25 août à 07:59, il faudra encore revenir pour vérification. La conception des échéances chez TermMax m’a fait penser aux relevés de carte de crédit : le taux est important, mais la date l’est tout autant. Les coûts fixes aident à établir un budget, mais ils ne préparent pas à la place l’argent nécessaire pour rembourser ; si le collatéral baisse, le risque de liquidation ne disparaît pas non plus parce que le taux est fixe. Une fois qu’on a compris ça, en étudiant ensuite des documents comme FT, GT, la logique devient claire. Je vais mettre à la fois la date d’échéance et la fenêtre de vérification dans mon calendrier. L’un gère la position produit, l’autre gère l’éligibilité à l’activité : oublier l’un ou l’autre, c’est vraiment douloureux. Un Booster, ça se fait en quelques minutes. La vraie valeur, c’est de commencer à utiliser les échéances, et pas seulement de regarder l’APY pour un emprunt on-chain.
En terminant cinq tâches, j’ai au contraire retenu “la date d’échéance”

Je n’étais venu(e) que pour faire un Booster. Résultat : après avoir répondu aux cinq questions, ce qui est resté dans mon esprit n’est pas A, B, A, C, A… mais “date d’échéance”, ces trois mots. @TermMax Avec un prêt à taux fixe et à durée fixe, la plus grande différence avec les pools de liquidités variables qu’on voit d’habitude, c’est qu’avant d’emprunter, on connaît déjà le coût et aussi le jour exact auquel il faut régler la dette. #TermMax

J’ai refait les étapes de l’activité : d’abord, préparer au moins 2 points Alpha avec un wallet sans clé de Binance ; au moment de l’inscription, 2 points sont déduits. Ensuite : suivre le compte officiel sur X, transférer/retweeter la publication de la mission, terminer l’apprentissage, rejoindre Discord, et connecter TermMax V2. Après que les cinq barres sont passées au vert, ne fermez pas la page : la création sur la Place fait partie d’une autre ligne. Les 500 premiers en chinois se partagent 150 000 TMX, clôture le 22 août à 07:59 (UTC+8). Du 24 août à 11:00 au 25 août à 07:59, il faudra encore revenir pour vérification.

La conception des échéances chez TermMax m’a fait penser aux relevés de carte de crédit : le taux est important, mais la date l’est tout autant. Les coûts fixes aident à établir un budget, mais ils ne préparent pas à la place l’argent nécessaire pour rembourser ; si le collatéral baisse, le risque de liquidation ne disparaît pas non plus parce que le taux est fixe. Une fois qu’on a compris ça, en étudiant ensuite des documents comme FT, GT, la logique devient claire.

Je vais mettre à la fois la date d’échéance et la fenêtre de vérification dans mon calendrier. L’un gère la position produit, l’autre gère l’éligibilité à l’activité : oublier l’un ou l’autre, c’est vraiment douloureux. Un Booster, ça se fait en quelques minutes. La vraie valeur, c’est de commencer à utiliser les échéances, et pas seulement de regarder l’APY pour un emprunt on-chain.
·
--
Voir la traduction
DuskEVM兼容的是工具,不是所有旧假设 “EVM兼容”很容易被读成旧合约复制粘贴即可上线。我原来也这么想,直到把排序、跨层消息、费用与最终性逐项拆开,才发现兼容只解决了开发入口的一部分。 DuskEVM让Solidity开发者可以使用熟悉的工具和接口,但应用运行在Dusk的分层架构里。合约能编译,不代表对公共内存池、区块字段、发送者身份和提现状态的旧假设仍然成立。 对于普通应用,这些差异可能是一笔交易卡住;对于证券应用,错误主体或错误最终状态会直接改变谁拥有资产。迁移验收应从“代码是否部署”升级为“业务语义是否保持”。 我会要求团队为个人账户、合约账户、跨层存取、网络切换和异常恢复分别测试,而不是拿一次成功交易代表全部。熟悉工具可以加速开始,差异清单才能保证安全结束。 判断“DuskEVM兼容的是工具,不是所有旧假设”不能只看顺利演示,还要看失败时状态是否清楚、责任是否有人接住、用户是否仍能安全退出。 所以 @Dusk_Foundation 的DuskEVM主网值得期待,但$DUSK #dusk 的真正门槛,是开发者能否用熟悉工具认真对待不熟悉的责任。
DuskEVM兼容的是工具,不是所有旧假设

“EVM兼容”很容易被读成旧合约复制粘贴即可上线。我原来也这么想,直到把排序、跨层消息、费用与最终性逐项拆开,才发现兼容只解决了开发入口的一部分。

DuskEVM让Solidity开发者可以使用熟悉的工具和接口,但应用运行在Dusk的分层架构里。合约能编译,不代表对公共内存池、区块字段、发送者身份和提现状态的旧假设仍然成立。

对于普通应用,这些差异可能是一笔交易卡住;对于证券应用,错误主体或错误最终状态会直接改变谁拥有资产。迁移验收应从“代码是否部署”升级为“业务语义是否保持”。

我会要求团队为个人账户、合约账户、跨层存取、网络切换和异常恢复分别测试,而不是拿一次成功交易代表全部。熟悉工具可以加速开始,差异清单才能保证安全结束。

判断“DuskEVM兼容的是工具,不是所有旧假设”不能只看顺利演示,还要看失败时状态是否清楚、责任是否有人接住、用户是否仍能安全退出。

所以 @Dusk 的DuskEVM主网值得期待,但$DUSK #dusk 的真正门槛,是开发者能否用熟悉工具认真对待不熟悉的责任。
·
--
Après la « mise en chaîne » d’un actif, qui émet la facture de l’intérêt Transformer une émission obligataire en Token sur chaîne n’est que le début. Ensuite, il faut encore gérer le registre des détenteurs, le calcul des intérêts, les dates de paiement, le traitement fiscal, ainsi que les cycles de gel et de dégel, et enfin le remboursement à l’échéance. Si ces actions d’entreprise reposent toujours sur une équipe qui exporte des données depuis la chaîne vers Excel, puis traite manuellement le tout dans un autre back-office, l’actif n’aura fait que changer d’enveloppe de transaction : son cycle de vie n’aura pas réellement migré. Ce qu’il faut surtout observer, c’est l’aspect de l’actif une fois entré dans l’exploitation quotidienne : enregistrement quotidien des détenteurs, calcul des coupons, vérification de la confidentialité, paiements et rapprochement d’audit. Ce n’est que lorsque les règles intègrent à l’avance le premier coupon et/ou les changements de détenteurs que l’équipe n’aura pas à improviser une explication après un incident. Plus les frontières sont claires, plus le service de l’actif devient une capacité du quotidien, et pas seulement une annonce de lancement. Je vais donc tester le récit natif de la génération de Dusk à travers les actions des entreprises : les règles peuvent-elles identifier des détenteurs éligibles tout en protégeant la confidentialité des investisseurs ? Le paiement peut-il s’exécuter selon un état déterminé ? L’examen d’autorisations peut-il fournir les preuves nécessaires. @Dusk_Foundation fournit une infrastructure ; elle n’exonère pas l’émetteur de sa responsabilité, mais permet de faire reposer cette responsabilité sur des registres plus uniformisés. $DUSK #dusk Le moment le plus convaincant pour un RWA, ce n’est pas de figurer en une le jour de l’émission, mais plutôt, six mois plus tard, lorsqu’il a effectué un coupon, un transfert et un audit, et que les trois parties arrivent toujours à retrouver exactement le même compte.
Après la « mise en chaîne » d’un actif, qui émet la facture de l’intérêt

Transformer une émission obligataire en Token sur chaîne n’est que le début. Ensuite, il faut encore gérer le registre des détenteurs, le calcul des intérêts, les dates de paiement, le traitement fiscal, ainsi que les cycles de gel et de dégel, et enfin le remboursement à l’échéance. Si ces actions d’entreprise reposent toujours sur une équipe qui exporte des données depuis la chaîne vers Excel, puis traite manuellement le tout dans un autre back-office, l’actif n’aura fait que changer d’enveloppe de transaction : son cycle de vie n’aura pas réellement migré.

Ce qu’il faut surtout observer, c’est l’aspect de l’actif une fois entré dans l’exploitation quotidienne : enregistrement quotidien des détenteurs, calcul des coupons, vérification de la confidentialité, paiements et rapprochement d’audit. Ce n’est que lorsque les règles intègrent à l’avance le premier coupon et/ou les changements de détenteurs que l’équipe n’aura pas à improviser une explication après un incident. Plus les frontières sont claires, plus le service de l’actif devient une capacité du quotidien, et pas seulement une annonce de lancement.

Je vais donc tester le récit natif de la génération de Dusk à travers les actions des entreprises : les règles peuvent-elles identifier des détenteurs éligibles tout en protégeant la confidentialité des investisseurs ? Le paiement peut-il s’exécuter selon un état déterminé ? L’examen d’autorisations peut-il fournir les preuves nécessaires. @Dusk fournit une infrastructure ; elle n’exonère pas l’émetteur de sa responsabilité, mais permet de faire reposer cette responsabilité sur des registres plus uniformisés. $DUSK #dusk Le moment le plus convaincant pour un RWA, ce n’est pas de figurer en une le jour de l’émission, mais plutôt, six mois plus tard, lorsqu’il a effectué un coupon, un transfert et un audit, et que les trois parties arrivent toujours à retrouver exactement le même compte.
·
--
Voir la traduction
机构要的不是匿名,而是不被竞争对手抄作业 把金融隐私理解成“隐藏违法交易”,其实忽略了最常见的商业需求。基金的建仓节奏、企业的供应商付款、做市商的库存和大客户的交易意图,本来就不该实时暴露给所有竞争者。传统金融有保密制度,搬到公开链后却可能变成任何人都能监控。 @Dusk_Foundation 提出的可编程隐私,想解决的正是这种矛盾。该公开的市场事实仍能验证,不该公开的交易细节受到保护;需要审计时,再向获得授权的一方进行选择性披露。Hedger通过同态加密和零知识证明支持机密EVM工作流,让隐私不是合约之外的装饰。 但我不会因此把它描述成“完全匿名”。地址行为、权限配置和应用设计仍可能泄露信息,审阅权由谁持有也需要治理。隐私技术真正成熟的标志,是项目愿意把保护范围与剩余风险都讲清楚。 进一步检验时,如果现有机构流程已经能低成本完成同一件事,迁移是否仍然值得?只有节省的时间、责任或风险足以覆盖改造成本,采用才会持续。,这样才能区分技术可用与业务可用。 所以 $DUSK #dusk 的潜在用户并不只是重视匿名的个人,更可能是无法接受商业策略被全网直播的机构。对它们来说,隐私不是额外福利,而是进入公共链之前必须解决的经营条件。
机构要的不是匿名,而是不被竞争对手抄作业

把金融隐私理解成“隐藏违法交易”,其实忽略了最常见的商业需求。基金的建仓节奏、企业的供应商付款、做市商的库存和大客户的交易意图,本来就不该实时暴露给所有竞争者。传统金融有保密制度,搬到公开链后却可能变成任何人都能监控。

@Dusk 提出的可编程隐私,想解决的正是这种矛盾。该公开的市场事实仍能验证,不该公开的交易细节受到保护;需要审计时,再向获得授权的一方进行选择性披露。Hedger通过同态加密和零知识证明支持机密EVM工作流,让隐私不是合约之外的装饰。

但我不会因此把它描述成“完全匿名”。地址行为、权限配置和应用设计仍可能泄露信息,审阅权由谁持有也需要治理。隐私技术真正成熟的标志,是项目愿意把保护范围与剩余风险都讲清楚。

进一步检验时,如果现有机构流程已经能低成本完成同一件事,迁移是否仍然值得?只有节省的时间、责任或风险足以覆盖改造成本,采用才会持续。,这样才能区分技术可用与业务可用。

所以 $DUSK #dusk 的潜在用户并不只是重视匿名的个人,更可能是无法接受商业策略被全网直播的机构。对它们来说,隐私不是额外福利,而是进入公共链之前必须解决的经营条件。
·
--
Bloquer les points d’entrée des attaques et éliminer les hypothèses erronées sont deux choses différentes AEGIS souligne elle-même une distinction très honnête : le fait que le chemin d’attaque principal soit verrouillé ne signifie pas que la cause racine a déjà été entièrement reconstruite. La chaîne de coûts de Phoenix peut être stoppée dès à présent, en empêchant l’emballement, l’arrêt de la chaîne et le vol via des remboursements grâce à des contrôles de cohérence et à l’affectation des champs ; un travail plus profond de clarification et de réorganisation de la conception relève toutefois d’une autre tâche. L’état de sécurité n’est donc pas simplement une question de « trou / pas de trou ». Je pense que ce type de formulation convient mieux aux infrastructures financières qu’un simple « le problème est résolu ». L’objectif de l’atténuation d’urgence est de réduire rapidement le risque réel, tandis que la réparation de la cause racine consiste à supprimer les hypothèses erronées partagées entre modules ; les deux diffèrent par leurs délais, leurs coûts de vérification et de migration. Les mélanger en une seule coche de « terminé » ferait perdre au marché une base pour juger le risque restant. Une bonne divulgation devrait expliquer séparément : si l’exploitation existante est désormais impossible, quels morceaux de code dépendent encore de l’ancienne structure, comment la future refonte sera vérifiée, et si la sémantique des transactions historiques est affectée. Ainsi, les utilisateurs ne paniqueront pas à cause des termes techniques, et ne seront pas apaisés par des slogans de sécurité trop simplistes. Je constate l’avancement de la sécurité pour @Dusk_Foundation : j’enregistrerai « exploit closure » et « root-cause closure » séparément. $DUSK , #dusk : ce qui mérite confiance, ce n’est pas de ne jamais reconnaître la dette technique, mais que chaque couche de dette ait un nom, un état, et des conditions de fin.
Bloquer les points d’entrée des attaques et éliminer les hypothèses erronées sont deux choses différentes
AEGIS souligne elle-même une distinction très honnête : le fait que le chemin d’attaque principal soit verrouillé ne signifie pas que la cause racine a déjà été entièrement reconstruite. La chaîne de coûts de Phoenix peut être stoppée dès à présent, en empêchant l’emballement, l’arrêt de la chaîne et le vol via des remboursements grâce à des contrôles de cohérence et à l’affectation des champs ; un travail plus profond de clarification et de réorganisation de la conception relève toutefois d’une autre tâche. L’état de sécurité n’est donc pas simplement une question de « trou / pas de trou ».
Je pense que ce type de formulation convient mieux aux infrastructures financières qu’un simple « le problème est résolu ». L’objectif de l’atténuation d’urgence est de réduire rapidement le risque réel, tandis que la réparation de la cause racine consiste à supprimer les hypothèses erronées partagées entre modules ; les deux diffèrent par leurs délais, leurs coûts de vérification et de migration. Les mélanger en une seule coche de « terminé » ferait perdre au marché une base pour juger le risque restant.
Une bonne divulgation devrait expliquer séparément : si l’exploitation existante est désormais impossible, quels morceaux de code dépendent encore de l’ancienne structure, comment la future refonte sera vérifiée, et si la sémantique des transactions historiques est affectée. Ainsi, les utilisateurs ne paniqueront pas à cause des termes techniques, et ne seront pas apaisés par des slogans de sécurité trop simplistes.
Je constate l’avancement de la sécurité pour @Dusk : j’enregistrerai « exploit closure » et « root-cause closure » séparément. $DUSK , #dusk : ce qui mérite confiance, ce n’est pas de ne jamais reconnaître la dette technique, mais que chaque couche de dette ait un nom, un état, et des conditions de fin.
·
--
Le point de bascule entre l’émission native et la tokenisation se cache dans « Qui est le grand livre final » En lisant le chapitre Native Issuance de Dusk, j’ai réduit la question à une phrase : le grand livre on-chain est-il le registre final des actifs, ou n’est-il qu’une image du système de registre off-chain ? En général, la tokenisation émet un token qui représente un actif ou un droit ; cela facilite la programmation et la composition. Mais la conservation (custodie), l’enregistrement ou le règlement peuvent encore dépendre de systèmes off-chain. Native Issuance conçoit la création, la cession, le service et le règlement de l’actif directement autour du grand livre on-chain. Les deux approches peuvent avoir de la valeur, mais la charge opérationnelle n’est pas du tout la même. Un token de type « image » doit garantir sur le long terme l’alignement entre les quantités on-chain, les actifs off-chain, l’historique des détenteurs et les droits juridiques : un seul retard crée un problème de rapprochement. Native Issuance a l’opportunité de réduire les doubles enregistrements et les transferts intermédiaires, mais à condition que la structure juridique, les autorisations de l’émetteur, les plateformes de négociation et les règles relatives aux actifs reconnaissent l’état on-chain. La technique ne peut pas créer ex nihilo une efficacité juridique, ni se substituer à l’émetteur pour ses obligations de service. Dusk place le contrôle d’accès, la divulgation sélective et le règlement déterministe au sein de la même infrastructure : l’objectif est clairement de se rapprocher d’un cycle de vie complet. DuskEVM s’occupe de la voie de développement applicatif familière, DuskDS assume le règlement et la disponibilité des données, et Dusk Trade transforme ces capacités en parcours utilisateur. Les modules ont chacun un rôle ; aucun d’eux ne peut, à lui seul, déclarer qu’un actif a été émis « nativement ». Il faut aussi répondre à : quelles actions de l’entreprise, quels mécanismes de remédiation après la perte d’une clé, et quels rapports réglementaires sont déclenchés par quelle couche de registre, afin de prouver que le grand livre on-chain porte effectivement la responsabilité principale. À mon avis, pour l’avancement du RWA @Dusk_Foundation , je chercherai d’abord la chaîne des enregistrements et des responsabilités, plutôt que de compter seulement combien de Ticker ont été émis. $DUSK #dusk Si un actif doit encore être rapproché chaque jour avec un grand livre total off-chain, il ressemble davantage à un billet numérique efficace ; lorsque les droits et le cycle de vie reposent sur l’on-chain, l’émission native prend alors un sens concret. Selon vous, le plus difficile à migrer sur le marché, c’est la négociation, ou bien la reconnaissance juridique du grand livre final ?
Le point de bascule entre l’émission native et la tokenisation se cache dans « Qui est le grand livre final »

En lisant le chapitre Native Issuance de Dusk, j’ai réduit la question à une phrase : le grand livre on-chain est-il le registre final des actifs, ou n’est-il qu’une image du système de registre off-chain ? En général, la tokenisation émet un token qui représente un actif ou un droit ; cela facilite la programmation et la composition. Mais la conservation (custodie), l’enregistrement ou le règlement peuvent encore dépendre de systèmes off-chain. Native Issuance conçoit la création, la cession, le service et le règlement de l’actif directement autour du grand livre on-chain.

Les deux approches peuvent avoir de la valeur, mais la charge opérationnelle n’est pas du tout la même. Un token de type « image » doit garantir sur le long terme l’alignement entre les quantités on-chain, les actifs off-chain, l’historique des détenteurs et les droits juridiques : un seul retard crée un problème de rapprochement. Native Issuance a l’opportunité de réduire les doubles enregistrements et les transferts intermédiaires, mais à condition que la structure juridique, les autorisations de l’émetteur, les plateformes de négociation et les règles relatives aux actifs reconnaissent l’état on-chain. La technique ne peut pas créer ex nihilo une efficacité juridique, ni se substituer à l’émetteur pour ses obligations de service.

Dusk place le contrôle d’accès, la divulgation sélective et le règlement déterministe au sein de la même infrastructure : l’objectif est clairement de se rapprocher d’un cycle de vie complet. DuskEVM s’occupe de la voie de développement applicatif familière, DuskDS assume le règlement et la disponibilité des données, et Dusk Trade transforme ces capacités en parcours utilisateur. Les modules ont chacun un rôle ; aucun d’eux ne peut, à lui seul, déclarer qu’un actif a été émis « nativement ». Il faut aussi répondre à : quelles actions de l’entreprise, quels mécanismes de remédiation après la perte d’une clé, et quels rapports réglementaires sont déclenchés par quelle couche de registre, afin de prouver que le grand livre on-chain porte effectivement la responsabilité principale.

À mon avis, pour l’avancement du RWA @Dusk , je chercherai d’abord la chaîne des enregistrements et des responsabilités, plutôt que de compter seulement combien de Ticker ont été émis. $DUSK #dusk Si un actif doit encore être rapproché chaque jour avec un grand livre total off-chain, il ressemble davantage à un billet numérique efficace ; lorsque les droits et le cycle de vie reposent sur l’on-chain, l’émission native prend alors un sens concret. Selon vous, le plus difficile à migrer sur le marché, c’est la négociation, ou bien la reconnaissance juridique du grand livre final ?
·
--
Voir la traduction
Hub有流动性不等于Spoke能无限借 我今天不想从“原生BTC终于能用了”讲起,而想纠正一个更容易影响操作的判断:Hub有流动性不等于Spoke能无限借。Trustless Bitcoin Vaults (TBV) 的资料显示,Aave v4 Hub汇总资产流动性,Babylon Core Spoke仍受自身风险参数和额度约束。这意味着,总池余额就是每个市场可借余额并不成立。 围绕“Hub有流动性不等于Spoke能无限借”,我会把判断落到可复核的交易或状态,而不是沿用旧分类。会高估某一抵押市场当下的真实容量。若“Hub有流动性不等于Spoke能无限借”不能改变实际操作顺序,这段分析就还没有完成。“Hub有流动性不等于Spoke能无限借”的结论必须说明谁行动、何时生效,以及失败后停在哪里。 我会特别保留“Hub有流动性不等于Spoke能无限借”对应的原始状态和交易证据,因为会高估某一抵押市场当下的真实容量,这正是结论能否成立的分水岭。 围绕“Hub有流动性不等于Spoke能无限借”的讨论严格对应 @babylonlabs_io 、$BABY 与 #baby ,不延伸到价格判断。
Hub有流动性不等于Spoke能无限借

我今天不想从“原生BTC终于能用了”讲起,而想纠正一个更容易影响操作的判断:Hub有流动性不等于Spoke能无限借。Trustless Bitcoin Vaults (TBV) 的资料显示,Aave v4 Hub汇总资产流动性,Babylon Core Spoke仍受自身风险参数和额度约束。这意味着,总池余额就是每个市场可借余额并不成立。

围绕“Hub有流动性不等于Spoke能无限借”,我会把判断落到可复核的交易或状态,而不是沿用旧分类。会高估某一抵押市场当下的真实容量。若“Hub有流动性不等于Spoke能无限借”不能改变实际操作顺序,这段分析就还没有完成。“Hub有流动性不等于Spoke能无限借”的结论必须说明谁行动、何时生效,以及失败后停在哪里。

我会特别保留“Hub有流动性不等于Spoke能无限借”对应的原始状态和交易证据,因为会高估某一抵押市场当下的真实容量,这正是结论能否成立的分水岭。

围绕“Hub有流动性不等于Spoke能无限借”的讨论严格对应 @BabylonLabs_io 、$BABY 与 #baby ,不延伸到价格判断。
Connectez-vous pour découvrir plus de contenu
Rejoignez la communauté mondiale des adeptes de cryptomonnaies sur Binance Square
⚡️ Suviez les dernières informations importantes sur les cryptomonnaies.
💬 Jugé digne de confiance par la plus grande plateforme d’échange de cryptomonnaies au monde.
👍 Découvrez les connaissances que partagent les créateurs vérifiés.
Adresse e-mail/Nº de téléphone
Plan du site
Préférences de cookies
CGU de la plateforme