0x德宝

看到“Atomic Settlement”，我原以为 DvP 的难题就是让资产腿和付款腿同时落链。今天重新梳理 @Dusk 的市场基础设施文档后，我停在了更麻烦的一层：原子与确定性可以消除半笔成交，却不会替机构决定失败之后该怎么办。

Dusk 的官方框架试图把准入判断、地址归属、受限转让、支付协调与最终交割串进同一市场工作流；DuskDS 在区块获 ratification 后提供确定性最终性。这个组合能改变传统证券交割最昂贵的一类问题——参与方不必在多个账本间反复确认“资产到底给了没有、钱到底到了没有”。

但把场景放进一次债券申购，异常马上出现。投资者先通过资格检查，现金被预留，份额等待交付；提交时却可能发生资格过期、余额不足、签名方离线、托管接口超时，或外部支付状态没有同步。如果两条腿确实由同一原子条件控制，最好的结果是一起成功或一起失败；可“一起失败”只是链上结果，不是业务闭环。

这正是我认为 Dusk 方向有价值、但证据仍不够的地方。DuskDS 的最终性把失败边界变清楚：最终区块中的成功或错误不会长期悬而未决，执行失败也有可查询结果。可 Dusk Trade 官网当天仍标为 Building 并开放 waitlist，公开资料没有给出生产环境的 DvP 完成率、异常分布或人工介入数据。

风险也很具体。第一，隐私与选择性披露若缺少成熟的授权审计工具，异常调查反而可能更慢。第二，若资产腿与付款腿跨越不同系统，原子性边界会缩小，人工补偿重新进入流程。技术最终性没有失败，但业务承诺可能仍未兑现。

你认为机构验收 DvP 最该先看 A 正常路径速度，B 异常自动恢复，还是 C 跨系统对账？#dusk $DUSK

默认能放 10,000 笔交易，我原以为这至少能说明网络扛得住一次机构订单高峰。今天继续读 @Dusk 的交易生命周期文档，我反而得出相反结论：mempool 容量回答的是“节点暂时能收多少”，机构真正购买的是“订单能否在业务截止前完成结算”。

官方文档写明，Dusk L1 节点的 mempool 容量由运营者配置，默认值是 10,000 笔。满载时，更高 gas price 的交易可以驱逐最低价条目；而且每个节点看到的是本地队列，不是全网统一快照。这个数字能证明节点提供了缓冲机制，不能证明 10,000 笔都会被执行，更不能证明它们按业务优先级完成。

把它放进一次债券申购或基金份额发行就很清楚。截止时点前，投资者要完成资格校验、订单提交、付款与资产交割。业务上更重要的可能是同一发行批次、同一付款窗口和失败补偿；但区块候选交易按 gas price 降序选择。若队列拥堵，技术上的价格优先未必等于市场工作流里的公平顺序。

交易还要依次经历构建签名、节点准入、传播、选择、执行和最终化。执行失败也会消耗 gas；`removed` 事件只说明交易离开某个本地 mempool，可能是入块、替换、过期或容量驱逐，不能单独判断结果。Dusk 首页今天仍展示约 10 秒确定性最终性，但那描述的是区块被最终确认后的确定性，不是从提交到业务完成的端到端 SLA。

更值得警惕的是本地策略差异。文档同时说明，交易过期是节点政策：Rusk 内置默认是三天，而 node-installer v0.5.22 为主网和测试网配置的是 30 分钟。客户端必须按自己接入节点的规则处理，不能把任一数值当作网络保证。
#dusk $DUSK

隐私越强，交易所越难接？

我原以为，一条强调隐私的链，交易所当然应该优先接入最隐私的交易模型。今天重新梳理 @Dusk 的交易模型和交易所集成文档后，我的判断反了过来：隐私不是越多越好，而是每增加一层不可见性，托管、归因和审计流程都必须有对应的运营设计。

DuskDS 原生提供两种价值模型。Moonlight 是公开账户：余额、发送方、接收方和金额可见；Phoenix 使用屏蔽票据与 nullifier，在不暴露金额、参与者和具体票据关系的情况下证明没有双花且资金充足，也可通过 viewing key 做选择性披露。两者最终落在同一条链上，但可见性完全不同。

这能证明 Dusk 不是“所有交易都不可见”，也不是只能把机构数据全部摊在公开账本上。用户可以按场景选择公开账户或屏蔽票据：财务报告、交易所充值等需要稳定观察和归因的流程，可以走 Moonlight；不希望暴露余额和交易关系的持有与转移，可以走 Phoenix。

这里出现了一个二阶矛盾：为了降低信息泄露，用户可能要多走一次 Phoenix 到 Moonlight 的转换；为了降低运营复杂度，交易所又可能把公开账户设成默认入口。结果是协议拥有隐私能力，但最常见的法币和中心化流动性入口仍把用户导向公开路径。隐私功能的采用率，不能只看“能不能隐藏”，还要看用户是否愿意承担转换、披露和异常处理成本。

至于 $DUSK ，我仍只采用官方确认的 gas 与 staking 口径。只有公开与屏蔽两条路径都产生持续、可恢复的真实作业，隐私选择才会转成网络执行和安全需求，而不是演示功能。

你认为 Dusk 的隐私采用先要突破 A 交易所托管，B 查看权限运营，还是 C 用户转换成本？#dusk

多链不是一张市场：固定期限越丰富，流动性越容易被切碎

多链常被当成覆盖面指标，但对固定期限市场来说，链越多，未必越像“一张更大的市场”；它也可能只是更多彼此不能直接成交的小市场。

我重新梳理 @TermMax 的市场定义时注意到：每个固定利率市场都由债务资产、抵押品和到期日共同确定。公开 App 还有多链筛选入口。流动性不只按资产对分开，还会继续被期限和网络切分。

这会改变用户真正经历的资金流程。出借人不是把资金放进一个抽象的“总池”，而是在某条链、某组债务与抵押品、某个到期日下寻找报价；借款人也要在同样具体的格子里出售对应头寸。另一个网络的深度不能自动补足眼前的订单。

因此，“支持更多链”解决的是触达和资产入口，不会自动解决成交质量。期限越丰富，资金可能越分散；小额报价漂亮，目标金额一放大，就可能出现滑点、部分成交或找不到对手方。跨链桥能搬运资产，也不等于把不同链上的订单和结算风险合并。

官方项目页把 Atomic Orders 和 Order Aggregator 放在 “What's Next” 中：前者希望一份流动性跨市场部署，后者希望自动寻找更优报价。我的推断是，分散资金的调用效率是重要问题；但路线图存在，不等于今天已经获得统一深度。

怎样判断多链扩展有没有变成真实采用？我更关注四组指标：按链、资产对和期限拆分的可成交深度；目标金额下的加权 APR 与滑点；完整成交率及等待时间；到期资金复投到下一期限的比例。总 TVL 即使增长，也可能集中在少数市场，不能替代这些分布指标。

如果只能选一个优先级，你会选 A 先做更多链和资产入口，B 先集中少数市场做深流动性，还是 C 先完成跨市场聚合再扩张？#TermMax

我原以为，质押规模够大，就能直接说明网络经济已经跑起来。今天我重新读取 @Dusk 的官方端点，看到约 2.149 亿 DUSK 处于正质押记录，约占当时 5.9958 亿流通量的 35.84%；但同一轮核验也让我停在一个更重要的问题上：这些安全预算，到底有多少来自真实交易付费，多少仍来自协议发行？

对一条面向受监管金融的 Layer 1，质押首先证明有人把资本放进共识安全，却不能证明债券认购、DvP 结算、公司行动或隐私审计正在持续发生。

Dusk tokenomics 写得很清楚：$DUSK 的核心用途是 gas 与 staking；每个区块的奖励由两部分组成——新增发行，以及该区块收取的全部交易手续费。主网供给模型是初始 5 亿枚，再用 36 年释放另外 5 亿枚，发行速度按几何模型递减。

当天官方 gas-price 端点返回 average、median、min、max 都是 1 LUX。这个快照能证明当时的报价，却不能证明费用收入低，因为总费用还取决于交易数量和 gas used；同样，约 2.149 亿正质押也不能直接证明去中心化。官方 provisioner 端点有 226 条正 amount 记录，但一名运营者可能控制多条 key，合约池也可能拆出多条记录。

所以我更关心的不是一个漂亮的“质押率”，而是三张能互相校验的账：第一张是安全资本，包括正质押、locked stake、惩罚和运营者集中；第二张是网络工作量，包括真实交易、合约执行、隐私证明与结算；第三张是经济回流，包括 gas used、实际手续费总额，以及手续费在区块奖励中的占比。

我保留两个风险。第一，若奖励长期更依赖发行而非费用，未来发行递减会考验节点收入与安全预算。第二，即使手续费上升，也要确认来源不是少数应用或短期迁移操作。

我的判断是，2.149 亿质押值得认可，但它回答的是“有多少资本在保护网络”，不是“谁在为这份安全持续买单”。#dusk

“固定利率”不等于“任何金额都能按屏幕上的利率成交”。我对照 @TermMax 的 Range Order 与风险说明后，发现真正决定协议采用的，可能不是页面上有没有漂亮 APR，而是这条报价曲线能承载多大的真实资金。

用户看到的利率像一个数字，底层却是一条随成交量变化的定价曲线。不同区间配置不同利率；订单继续吃进深度，后续部分可能落在另一档报价。

这带来一个关键反转：利率在成交后、对应到具体到期日时可以被锁定；但在点击确认之前，实际成交条件仍取决于订单规模、曲线剩余容量和链上执行。固定的是已匹配头寸的成本，不是页面报价对任意资金量的承诺。

小额借款只消耗曲线前段，可能接近首屏展示值；大额借款继续向后成交，加权 APR 就可能上移，甚至只能部分成交。官方风险页也提示，大额交易沿 AMM 曲线消耗更多流动性，预期与实际执行还可能因链上确认和 MEV 偏离。

因此，“利率可预测”必须分成两层。第一层是合约层：一旦撮合，借款成本和到期日不再随浮动借贷市场变化。第二层是市场层：在目标规模上能否以接近预期的加权利率完成交易。前者是机制属性，后者才是流动性与采用的检验。风险也不能被一句“固定”盖住。曲线过薄会放大滑点或造成部分成交；拆单虽可能减少单笔冲击，却增加 gas、等待时间和 MEV 暴露。

今天公开 App 页面没有返回可复核的 TVL、市场数、活跃金库或实时 APR，因此我不沿用旧数据。后续我更关注四个可验证指标：目标金额的加权成交 APR、不同规模相对首屏报价的滑点、订单完整成交率，以及同期限双边深度在压力时是否仍存在。

你会用哪组指标判断 TermMax 的固定利率市场成熟？A：TVL 与首屏 APR；B：不同订单规模的加权成交 APR 与完整成交率；C：压力行情下的双边深度与滑点？

#TermMax

Sur le site officiel, on lit « €300M+ émission confirmée » : on n’est plus très loin d’un marché de titres on-chain à l’échelle. Aujourd’hui, en relisant le site officiel de @Dusk , la documentation de Dusk Trade et le nouvel article du 15 août, je reste au contraire bloqué sur deux états parallèles : d’un côté, €300M+ d’émissions confirmées et 50K+ d’atteinte investisseurs ; de l’autre, Dusk Trade est encore étiqueté « Building », l’entrée renvoie toujours à une liste d’attente.

Ces données prouvent l’existence d’un pipeline de partenariats institutionnels et d’une portée potentielle, mais ne prouvent pas que les €300M ont déjà été émis et mis en chaîne, ni encore moins l’existence d’un volume équivalent de transactions, de règlement ou de liquidité secondaire. Lire « émission confirmée » directement comme « transactions conclues » supprimerait la partie la plus difficile de la construction du marché.

Prenons un exemple simple : une obligation d’entreprise pour PME. L’émetteur commence par fixer les droits, le taux, la maturité et les documents juridiques ; les investisseurs complètent la vérification d’identité et d’adéquation ; les ordres de souscription doivent correspondre aux paiements ; après l’attribution, on met à jour la titularité ; pendant toute la durée de vie, il faut aussi gérer le paiement des intérêts, les notifications, le vote, le remboursement et les litiges ; si l’on entre sur le marché secondaire, il faut encore des acheteurs qualifiés, la divulgation d’informations, la formation des prix et l’environnement autorisé pour opérer.

L’ancre technique principale de Dusk Trade n’est pas un contrat token, mais une couche produit : découvrir les actifs, onboarder les investisseurs, connecter les wallets, coordonner les paiements, exécuter les achats/ventes et le règlement dans le même flux de travail utilisateur. En dessous, il peut s’appuyer sur le règlement et la finalité de DuskDS, l’identité de Citadel et la divulgation sélective, ainsi que la connexion de compte via Dusk Connect. Ce qu’il veut changer, ce n’est pas juste « remplacer des titres par des symboles on-chain », mais modifier des processus de rapprochement back-office transaction par transaction.

C’est précisément pour cela que les €300M+ méritent l’attention : si, au final, ce lot de projets place l’émission, l’admission, la titularité, les paiements et les services dans un état partagé, Dusk n’obtient pas seulement une vitrine, mais un flux continu d’opérations de marché. L’article officiel le rappelle d’ailleurs clairement : fractionner les parts ne crée pas automatiquement une demande, une certitude juridique ou de la liquidité.

Cependant, le manque à vérifier est tout aussi important. Aujourd’hui, le site officiel marque Dusk Trade comme Building et l’article continue de diriger les utilisateurs vers la liste d’attente (waitlist). Je n’ai trouvé aucune page publique listant le nombre d’actifs déjà ouverts, les montants d’émission déjà finalisés, le volume de transactions, la quantité de règlements DvP, ou le nombre d’investisseurs actifs. Ainsi, « confirmed issuance » ressemble davantage à un ordre en attente d’exécution qu’à un reçu de transaction.
#dusk $DUSK

Une fois qu’il entre sur un marché à durée fixe, est-ce que RWA se rapproche davantage des « obligations on-chain » ? En recoupant, après coup, la vision, la définition du marché et le mécanisme de livraison physique de @TermMax , je me dis au contraire qu’il faut éviter cette analogie qui dérape : un taux fixe permet d’écrire clairement le temps et le prix, mais ne permet pas d’inscrire automatiquement les droits hors chaîne dans le contrat.

La vision officielle de TermMax classe RWA comme une direction de collatéral extensible. Les utilisateurs choisissent toujours un marché défini par un actif de dette, un actif de garantie et une date d’échéance : l’emprunteur verrouille des tokens de collatéral pour obtenir de la liquidité, puis à l’échéance échange selon les règles. Ce mécanisme exprime de façon plus claire les coûts, les maturités et la position on-chain.

Mais le protocole identifie le token. Est-ce qu’il correspond à un actif sous-jacent revendicable ? À quels émetteur ou organisme de conservation le détenteur a-t-il affaire ? Dans quel ressort (juridiction) et selon quelles conditions le token est-il racheté ? On ne peut pas déduire tout cela de la seule notion de « durée fixe ». À mon avis, les limites des droits proviennent des documents d’émission, des arrangements de conservation et du mécanisme de rachat ; TermMax prend en charge le pricing et la répartition des risques de fonds on-chain liés à ces tokens, mais ne complète pas les contrats off-chain.

Un coût d’emprunt déterminé aide l’emprunteur à planifier ses flux de trésorerie, et une date d’échéance explicite facilite la comparaison entre différentes maturités ; toutefois, si le prix du token de collatéral est faussé, si l’émetteur suspend le rachat, si le marché sous-jacent ferme ses portes, ou si la liquidité on-chain s’amincit, la certitude de l’échéance n’élimine pas les risques d’évaluation, de crédit et de liquidation.

La livraison physique de TermMax illustre davantage cette frontière : si, à la fin de la fenêtre de liquidation, le prêt arrivé à échéance n’est pas encore entièrement remboursé, le pool de rachat peut contenir à la fois l’actif de dette et l’actif de garantie, et les détenteurs de FT reçoivent selon leur quote-part. Cela signifie que le règlement ne se limite pas à l’attente du remboursement par l’emprunteur ; mais si l’on reçoit des tokens de collatéral RWA, la possibilité de racheter, le prix auquel vendre et le temps nécessaire pour convertir en liquidités dépendent toujours des droits propres au token et du marché.

Ainsi, je ne jugerai pas directement l’adoption de RWA avec « soutenir RWA » ou l’APY de la page. La validation la plus utile se fait en trois niveaux : les droits du ressort, du sous-jacent, de l’émetteur et du dépositaire sont-ils publics ? Les souscriptions et rachats sont-ils stables, et dans quelle mesure le prix on-chain et la valeur liquidative de référence divergent ? En cas de stress, quelle est la profondeur secondaire, la continuité des oracles, le taux de recouvrement en cas de défaut et le temps de liquidation.

Quelles preuves utiliseriez-vous pour juger la maturité du marché à taux fixe pour RWA ? Réponse : A : TVL et APY de la page ; B : clauses de rachat, spread et profondeur secondaire ; C : taux de recouvrement après défaut et temps de liquidation ?

#TermMax

J’ai d’abord cru qu’une fois que des titres réglementés pouvaient être déplacés via une infrastructure de cross-chain, ils gagneraient naturellement un plus grand marché on-chain. Jusqu’à ce que je relise, @Dusk et le matériel officiel de NPEX qui utilisent les standards de Chainlink : je suis alors resté bloqué sur un problème encore plus ardu : les tokens peuvent traverser les chaînes, mais l’admissibilité des investisseurs, les restrictions de cession, les droits de divulgation et l’autorisation des plateformes de négociation ne migrent pas automatiquement avec un simple message.

Mettez cela dans un flux de travail réel et c’est évident. Supposons qu’une obligation réglementée soit émise sur DUSKEVM et que l’émetteur veuille la déplacer vers une application de prêt ou de trading sur une autre chaîne. La couche technique doit gérer la conversion cross-chain de la représentation de l’actif ; côté métier, il faut aussi vérifier si l’adresse cible est éligible, si l’application cible peut recevoir le token, si les restrictions de détention et de territoire sont cohérentes, et surtout qui est responsable du rachat, des actions sur titres et de la conservation des preuves de conformité réglementaire. À chaque étape, si l’on ne transporte que le token sans les règles, on laisse derrière soi un nouveau compte de rapprochement.

L’annonce officielle de 2025 utilise la formulation « en cours d’intégration » de Chainlink CCIP, DataLink et Data Streams, et décrit un chemin d’actifs inter-chaînes via CCT. Le point le plus important n’est pas « à combien de chaînes cela relie », mais plutôt que le modèle burn/mint du CCT ne dépend pas de pools de liquidité tiers ; $DUSK et NPEX conservent toujours la propriété du contrat de token, avec la possibilité de définir des rate limits et des chemins d’upgrade.

Pour des actifs réglementés, la vraie difficulté réside donc dans la portabilité des stratégies. La chaîne source peut déjà être liée à des justificatifs d’investisseurs qualifiés, à des plafonds de détention et à une divulgation sélective ; la chaîne cible peut en revanche avoir un système d’adresses, des services d’identité, des capacités de confidentialité et des lieux autorisés différents. Si les règles des deux côtés ne se reconnaissent pas mutuellement, le cross-chain sera refusé ou renvoyé à une approbation manuelle ; et si on assouplit les règles pour préserver la liquidité, on risque aussi de rompre les conditions initiales d’émission.

Mon avis est donc le suivant : le cross-chain ne fait pas disparaître les obstacles réglementaires « de façon technique ». Il découpe un seul accès au marché en deux temps : d’abord prouver que le message relatif à l’actif est valide, puis prouver qu’il reste légal, auditable et serviable dans l’environnement cible. C’est une refonte du processus, pas l’ajout d’un bouton de pontage.

Selon vous, la difficulté majeure du cross-chain d’actifs réglementés est-elle A la sécurité des messages, B la reconnaissance mutuelle des règles, ou C la liquidité du marché cible ? #dusk

La liste des marchés s’allonge, ce qui peut facilement être interprété comme « une explosion de la demande de taux fixes ». Mais après avoir reconsidéré les Markets et les ordres Range de @TermMax , je pense que cela revient peut-être à prendre la capacité d’offre pour un usage réel : créer autant de marchés ne dit rien d’autre que le nombre de choix disponibles. Que quelqu’un soit prêt à emprunter tel montant, pour telle durée et à tel coût, indique réellement si la demande existe.

Dans TermMax, un marché n’est pas seulement une paire de tokens. Il lie l’actif emprunté, le collatéral et la date d’échéance, et définit le taux de marge ainsi que le seuil de liquidation. L’emprunteur immobilise le collatéral, forme une position de dette, puis obtient la liquidité via la courbe de tarification ; l’ prêteur achète des FT représentant le droit d’être remboursé à l’échéance et attend la conversion à maturité.

Cela signifie qu’un même actif empruntable peut générer plusieurs marchés si le collatéral ou la date d’échéance diffèrent. L’augmentation du nombre peut venir du découpage du produit, mais pas forcément d’un nouvel emprunteur. Assimiler directement « nombre de marchés créés » à « adoption » revient à prendre le nombre d’étagères d’un centre commercial pour des ventes.

Je vais donc décomposer l’« adoption réelle » en trois niveaux : d’abord, regarder les volumes réels d’emprunt par durée et les emprunts répétés ; ensuite, vérifier si les horizons court, moyen et long forment une courbe de transactions explicable, et si la profondeur peut absorber des transactions plus importantes ; enfin, évaluer si le règlement à l’échéance et la sortie se font de manière fluide : l’emprunteur rembourse-t-il à l’échéance, se réemprunte-t-il, ou doit-il se refinancer de force dans une liquidité trop peu profonde.

Cela explique aussi pourquoi le TVL ne peut pas, à lui seul, apporter la réponse. Le TVL ressemble davantage à un stock de capitaux ; si, sur le long terme, ces fonds ne sont pas empruntés, cela peut simplement signifier une offre abondante. L’augmentation des volumes d’emprunt n’est pas nécessairement saine : si elle se concentre sur un seul type de collatéral, une durée unique ou quelques gros acteurs, il subsiste des risques de concentration, de liquidation et de congestion à l’échéance.

Mon hypothèse est que la valeur à long terme de TermMax ne réside pas dans « le fait de lancer davantage de marchés à taux fixes », mais dans la capacité à construire progressivement une courbe de rendement DeFi générée par des besoins de fonds réellement concrétisés par des transactions. Des échéances fixes rendent la planification des capitaux plus claire, mais les risques liés à la volatilité des collatéraux, à la liquidation, à l’oracle, aux smart contracts et à la liquidité sur les échéances demeurent.

Quelles séries d’indicateurs utiliseriez-vous pour juger si TermMax est réellement adopté ? A : TVL et nombre de marchés ; B : volume d’emprunt réel et profondeur de la courbe ; C : boucles de règlement à l’échéance et de refinancement ?

#TermMax

Le coffre standardisé donne le plus facilement une illusion : l’interface est uniforme, et la qualité de la stratégie semble aussi uniforme. Après avoir re-trié le Vault @TermMax , je m’inquiète davantage du problème masqué par les « revenus passifs » : la standardisation porte sur les parts, pas sur le jugement du curator.#TermMax

L’utilisateur dépose des actifs de dette et reçoit des parts ERC-4626 ; ensuite, le curator alloue le même actif à différents marchés selon les échéances. L’utilisateur confie au gestionnaire le travail de choisir la date d’échéance, la courbe de cotation et l’affectation des fonds.

Cela réduit effectivement la friction réelle : l’utilisateur ordinaire n’a plus besoin de comparer en continu chaque échéance, ni de maintenir lui-même des ordres inter-marchés. La planification des fonds passe de « quel terme acheter » à « est-ce que j’accepte ces règles de configuration des échéances ».

Mais l’ERC-4626 ne définit que l’interface et la comptabilité des parts ; elle ne peut pas aider l’utilisateur à juger une stratégie. Le curator peut gérer les ordres, les courbes de prix, les plafonds de fourniture, les files de dépôt/retrait, et soumettre des changements via des listes blanches, des time locks et des ajustements de frais de performance. Chaque choix que l’utilisateur économise correspond à un jugement supplémentaire du curator.

TermMax encadre ce pouvoir avec des time locks, un guardian, des listes blanches et des limites de capacité : les changements majeurs ne prennent pas effet instantanément, et les changements en attente peuvent être annulés. Cependant, le time lock ne donne qu’une fenêtre d’observation et de sortie, sans prouver que les nouveaux paramètres sont rationnels ; la liste blanche ne peut pas non plus supprimer les risques liés aux collatéraux, aux oracles, aux contrats ou à la liquidité.

Par conséquent, je n’évaluerai pas le Vault uniquement avec le TVL ou l’annualisation affichée. Le TVL indique les fonds qui entrent, mais ne répond pas à la question de l’emprunt réel, de la persistance des rendements et de la qualité des retraits. Je me concentre davantage sur le rendement net après frais, le taux d’utilisation des fonds, le niveau de concentration, ainsi que sur l’attente et le slippage en période de stress.

Surtout, il faut distinguer « on peut initier un rachat » et « on peut récupérer les actifs rapidement au prix attendu ». Le coffre détient des positions contraintes par les échéances, la capacité et la profondeur ; une interface standard ne peut pas créer de manière magique de la liquidité de sortie. Et les rendements historiques ne peuvent pas remplacer les besoins d’emprunt du prochain cycle.

Mon avis est que la valeur du Vault V2 ne réside pas dans le fait que « tout le monde n’a plus besoin d’étudier », mais dans le fait d’élever l’objet de l’étude vers des règles de délégation auditables. Un coffre mûr devrait divulguer ce que le curator a choisi, pourquoi il a ajusté, combien il facture, quand on peut sortir, et qui peut bloquer en cas d’écart de stratégie. Ce n’est que si, même avec une faible incitation et dans un marché sous pression, c’est transparent et que la sortie reste possible, qu’il peut devenir une porte d’entrée stable pour des fonds à échéance

Je pensais que le navigateur pouvait générer une preuve de confidentialité en moins de 2 secondes, et que le problème de performance adopté par l’organisation serait alors en grande partie réglé. Après avoir re-trié les articles Hedger de @Dusk et l’état du produit aujourd’hui, je suis au contraire plus prudent : un joli benchmark ponctuel ne prouve pas que l’authentification, la compensation et l’audit d’autorisation sont déjà prêts pour un SLA de production engageant.

Il faut replacer cette contradiction dans un vrai flux de travail. Quand une institution soumet un ordre obligataire ou de fonds, elle ne veut pas divulguer les soldes, quantités, positions et intentions de transaction à l’ensemble du marché ; mais l’émetteur ou l’auditeur doit, lui, confirmer que la transaction est valide, que les participants sont qualifiés, et obtenir au besoin des preuves contrôlées. L’ancre technique principale de Hedger consiste à traiter des données chiffrées via un chiffrement homomorphe sans exposer les valeurs, puis à vérifier que le calcul est correct à l’aide d’une preuve à connaissance nulle, afin d’obtenir pour l’application DuskEVM un chemin de transactions confidentielles vérifiables.

Un article officiel de Dusk en 2025 a déjà indiqué que des circuits légers peuvent générer des preuves « inférieures à 2 secondes » côté navigateur. Cette donnée est importante : elle réfute le jugement grossier selon lequel toutes les interactions ZK seraient nécessairement trop lentes pour être utilisables, et montre que les preuves côté client pourraient se rapprocher de l’expérience d’attente des applications financières ordinaires.

Mais cela ne répond pas à quatre questions de production : sur du matériel bas de gamme, est-ce que c’est encore stable ? lorsque le parallélisme des ordres augmente, la latence en bout de chaîne devient-elle incontrôlable ? combien de calculs seront ajoutés par différents contrats et des règles plus complexes ? en cas d’échec de la preuve, peut-on récupérer sans que l’utilisateur doive reprendre tout le flux depuis le début.

Le point le plus clé : le temps de preuve n’est pas le temps de règlement. La documentation de DuskEVM décompose clairement le processus : la transaction est d’abord soumise au sequencer ; ensuite, le batcher publie les données sur DuskDS, et les engagements d’état ainsi que les fault proofs connectent ensuite les résultats à DuskDS pour le règlement. La documentation rappelle explicitement que l’inclusion et le settlement sont deux étapes distinctes : lorsqu’il y a de la valeur à travers des couches, il faut lire l’état du protocole ou du portefeuille, plutôt que d’inférer la finalité à partir du temps écoulé.

$DUSK délimite clairement l’usage officiel actuel : la transaction paie le gas, le staking protège le réseau. Hedger ne fera payer son coût de confidentialité sur la chaîne que si le passage des fonctionnalités de test à des tâches financières exécutées en continu se produit ; sinon, les 2 secondes restent une entrée de laboratoire, pas une preuve d’exigence.

Pensez-vous que la confidentialité au niveau institutionnel bloque d’abord à la latence de fin de file de la preuve A, l’exploitation et l’audit d’autorisation B, ou bien l’intégration dans une application réelle C ?#dusk

Je pensais qu’en transformant des placements privés en token, on avait simplement terminé la mise à la chaîne des actifs. Mais après avoir lu l’article sur le marché des placements privés mis à jour hier (@Dusk ), puis en le rapprochant de la documentation Native Issuance, je suis au contraire plus inquiet d’un point : si le droit de propriété légal, la conservation (custody), les actions de la société et la compensation sont toujours déterminés par un autre système, ce token n’est peut-être pas un outil d’efficacité, mais plutôt une nouvelle série d’enregistrements à rapprocher.

La tokenisation crée généralement un token qui représente un actif ou une revendication de droit ; elle peut rendre l’actif plus facile à programmer, à distribuer et à intégrer dans des applications. Mais l’actif sous-jacent peut rester hors chaîne, enregistré, conservé ou compensé dans un système différent. Les exigences de la Native issuance sont plus élevées : l’actif lui-même est créé et géré autour d’un grand livre en chaîne ; l’émission, le transfert, le service et la compensation utilisent autant que possible le même état de propriété.

Le vrai test, c’est qu’une émission en placement privé doit être saisie six fois de manière répétée. Dans les processus traditionnels, l’émetteur, le conseiller, le gestionnaire, la banque, le dépositaire (custodian) et la plate-forme de négociation traitent chacun séparément l’approbation de la structure, l’éligibilité des investisseurs, l’attribution des souscriptions, le registre des porteurs, le paiement, le transfert et les services ultérieurs. Chaque partie conserve un enregistrement similaire mais pas identique. Les erreurs surviennent souvent lors des transferts et des validations a posteriori.

Si l’on se contente d’ajouter un token à l’ancien processus, il faut quand même faire correspondre les soldes on-chain avec le registre de référence off-chain. Le transfert est effectué on-chain, mais il faut attendre la mise à jour du registre. Les dividendes sont calculés à partir de la liste off-chain, puis on revient expliquer les détenteurs on-chain. En cas de litige, on ne sait pas non plus quel jeu d’enregistrements a priorité. Techniquement, cela semble plus rapide ; opérationnellement, cela crée au contraire un nouveau point de rupture.

Ce que change vraiment la Native issuance, c’est le processus et la frontière de confiance : l’éligibilité des investisseurs peut être vérifiée avant la souscription ou le transfert ; l’attribution et la mise à jour de la propriété se produisent autour d’un même état contrôlé ; les restrictions de transfert s’appliquent directement à l’enregistrement du détenteur actuel ; les « jambes » de l’actif et les « jambes » du paiement sont coordonnées selon le même processus de compensation ; les paiements d’intérêts (coupon), le vote, les dividendes et le rachat lisent un historique continu des droits de propriété. La divulgation sélective et le contrôle d’accès de Dusk répondent à « qui peut voir, qui peut faire ». La compensation déterministe de DuskDS répond à « quel état est déjà définitivement réglé ».

C’est plus important que « émettre des tokens moins cher », parce que cela vise à réduire les rapprochements en double entre l’émission, l’enregistrement, la conservation, la négociation et le service—et pas seulement à changer l’apparence de l’actif en un symbole on-chain.

Selon vous, quel est le point le plus difficile à faire fonctionner dans la Native issuance ? $DUSK #dusk

J’ai d’abord cru qu’une fois qu’une blockchain atteint une confirmation définitive de manière incontestable, l’échange de titres est alors réellement « terminé ». Après avoir réexaminé les informations relatives à @Dusk , j’ai constaté que cela ne règle que la question technique de l’absence de re-rétrocession (rollback) ; ce n’est pas pour autant que les droits et responsabilités juridiques sont définitivement tranchés.

La Succinct Attestation de DuskDS atteint la finalité en trois étapes : proposition, validation et approbation. D’après les valeurs d’observation publiées aujourd’hui sur le site officiel, elle se situe autour de 10 secondes. Elle peut réduire les coûts d’attente et de rapprochement, mais elle ne peut pas décider automatiquement qui est le titulaire légal, qui est responsable en cas d’un échec de conservation (custody), ni comment les opérations sur titres (corporate actions) doivent être exécutées, ou encore qui, en cas de litige, possède les droits de révocation et d’indemnisation.

Donc j’accepte le règlement déterministe, mais je ne vais pas l’écrire comme une « disparition du risque juridique ». Je ne surveille que deux points : d’une part, si la jambe (leg) des actifs et la jambe (leg) des paiements sont bien réglées en véritable synchronisation ; d’autre part, combien de temps il faut pour qu’une transaction anormale passe de la détection à la prise en charge. Quant aux implications à long terme pour $DUSK , il faut d’abord revenir aux exigences de gas et de staking déjà confirmées, plutôt que d’enrober la finalité technique en promesse de rendement.

Pensez-vous que les institutions craignent davantage un rollback sur la chaîne A, ou un flou sur les droits et responsabilités hors chaîne (chaîne B) ? #dusk

Je pensais que l’argument principal de la « blockchain de confidentialité » était de rendre les données invisibles. Après avoir reconstitué les informations de @Dusk , je me suis arrêté sur le terme « selective disclosure » : l’enjeu n’est pas d’éteindre les registres, mais de transformer « qui peut voir quoi » en règles exécutables.

DuskDS conserve à la fois les comptes publics de Moonlight et les transactions shielded de Phoenix ; dans ce dernier cas, des preuves à divulgation nulle de connaissance masquent le montant et les relations, tout en permettant, via une viewing key, de divulguer aux parties autorisées. Cette conception ressemble davantage à des permissions hiérarchisées en finance qu’à une anonymisation inconditionnelle.

Cependant, une direction pertinente ne veut pas dire que tous les problèmes sont déjà résolus. Si la frontière de l’autorisation est mal définie, la confidentialité devient un nouvel îlot informationnel ; et si le processus d’audit est trop lent, les institutions finiront encore par revenir à la comptabilité et rapprochement hors ligne. Je ne regarde que deux indicateurs : dans la vraie activité, l’usage de la divulgation sélective, et le temps ainsi que le coût d’un audit après autorisation. Pour $DUSK , la demande à long terme devrait aussi d’abord se concentrer sur le gas et le staking que l’official a déjà confirmés, plutôt que sur une « prime de confidentialité » imaginée.

Vous êtes plutôt en faveur de A : tout public, ou B : une confidentialité auditables ?#dusk

Je vois, je comprends. Quand je relis toute une série d’actions récentes de Dusk, surtout ce qu’ils ont fait avec le courtier/exchange réglementé néerlandais NPEX et leur plateforme DuskTrade, je me dis que ce n’est pas tout à fait comme les autres. Il semble qu’ils ne se contentent pas de parler de l’avenir : ils utilisent une combinaison appelée « confidentialité conforme », cherchant à faire sauter la porte la plus lourde.
#dusk $DUSK @Dusk

Je comprends la direction, mais la plus grande erreur de TBV pourrait être la suivante : une fois que les règles sont verrouillées dans Bitcoin, les utilisateurs n’auraient plus à s’en préoccuper.

En relisant la description des rôles du protocole pour le @BabylonLabs_io , je pensais que « figer à la création » n’était qu’une garantie de sécurité ; en continuant à lire, j’ai constaté que cela renvoie aussi la charge de compréhension aux utilisateurs. AVK, Universal Challenger, la fenêtre de défi, etc. s’appliquent selon la version en vigueur au moment de la création du vault ; les anciens vault ne changent pas automatiquement de trajectoire simplement parce qu’une nouvelle version apparaît.

Ce n’est pas forcément une mauvaise chose. Ce n’est pas que le back-end peut modifier les règles à tout moment, mais plutôt que ton BTC natif n’accepte que des chemins Taproot déjà signés à l’avance. Cependant, si le front-end ne met en avant que les taux et les facteurs de santé, sans expliquer clairement la version du vault, l’ensemble des participants, les frais du Provider et le chemin de récupération, la self-custody pourrait alors devenir : « j’ai signé moi-même, mais je ne comprends pas ce que j’ai signé ».

Je vais observer si ces quatre points deviennent des étiquettes de risque standard, plutôt que de se limiter au nombre de vault. Je reconnais la conception du contrôle de TBV, mais pour qu’elle soit vérifiable, il faut aller encore plus loin : la rendre compréhensible.

Quel point te préoccupe le plus ? A. Les règles ne peuvent pas être remodifiées / B. Les informations sur le risque se comprennent d’un seul écran / C. Les deux sont indispensables

$BABY #baby

Je comprends la direction, mais le plus grand seuil institutionnel de la TBV n’est peut-être pas le taux d’intérêt : c’est plutôt que le portefeuille ne peut tout simplement pas signer.

En relisant les FAQ du testnet pour @BabylonLabs_io , je me suis arrêté sur un avertissement très concret : côté Bitcoin, il faut que ça supporte Taproot P2TR, PSBT et la signature de messages ; des multisigs de type Safe, via WalletConnect, s’ils ne déclenchent pas la signature, la documentation recommande plutôt de commencer par utiliser des extensions de portefeuille en connexion directe.

Je pensais que le self-custody résout le problème de « qui détient le BTC », mais en continuant, je me suis rendu compte que les institutions doivent aussi répondre à la question : « qui est capable de signer toute cette série de transactions conformément aux politiques internes ? ». L’enjeu n’est pas de faire migrer le BTC entre chaînes : l’enjeu, c’est de laisser le BTC natif dans le vault Taproot de Bitcoin, puis de contraindre la sortie avec des chemins pré-signés et des preuves basées sur l’état externe.

Les avantages : absence de pont, d’actifs “wrapped” et de dépositaire ; les risques : à l’heure actuelle, on en est encore au processus de test signet + Sepolia ; les résultats publics manquent encore pour ce qui est de la compatibilité avec les portefeuilles matériels, les validations multisigs, la séparation des permissions et la résilience en cas de sinistre.

Mon avis : regarder d’abord la matrice de compatibilité, le taux de signatures réussies et les exercices de reprise des institutions, puis seulement parler d’adoption à grande échelle. $BABY , quant à sa valeur à long terme, devrait aussi être portée par des opérations réelles de vault et la participation à la gouvernance, plutôt que par une simple phrase : « les institutions vont venir ».

Selon vous, qui franchira le premier le seuil ? A. utilisateurs d’extensions de portefeuille personnels / B. équipes techniques de custody professionnel / C. multisigs d’institutions traditionnelles.#baby

TBV : le risque vraiment facile à négliger n’est pas qu’il y ait trop peu de signatures, mais que l’utilisateur a cliqué de nombreuses fois sur « confirmer » sans savoir où le BTC sera finalement autorisé à aller.

En retraçant le processus de création de vault @BabylonLabs_io , je pensais au départ que la pré-signature en plusieurs lots rendait simplement l’opération plus pénible. En continuant à regarder, j’ai réalisé que l’enjeu n’est pas « signer beaucoup », mais que ces signatures Schnorr verrouillent à l’avance des chemins légitimes comme Claim, Assert, ChallengeAssert et Payout.

**Ce n’est pas de confier le contrôle du BTC au protocole ; c’est l’utilisateur, avant le dépôt, qui fixe à l’avance les sorties possibles.** C’est précisément ce qui fait la clé de TBV, sans dépendre d’un bridge, d’un wrapping ou d’un custodian.

Mais cet avantage apporte aussi un risque produit : si le portefeuille n’affiche qu’une longue suite de PSBT difficile à lire et des confirmations par lots, l’auto-custodie cryptographique peut se transformer en « aveugle signing » côté expérience utilisateur. À l’heure actuelle, nous sommes encore sur signet + le testnet public Sepolia ; la portée de compatibilité de UniSat, Taproot P2TR, PSBT et du message signing nécessite encore davantage de validations dans le monde réel.

Mon avis : je suis optimiste sur les limites de la pré-signature, mais je ne vais pas confondre « pouvoir signer » avec « comprendre ». Je vais surveiller le résumé des adresses de sortie, les explications de chaque chemin, le taux d’interruption de la signature et le taux de compatibilité avec les portefeuilles matériels.

Vous vous souciez davantage de laquelle de ces options ?

A. Des chemins bien expliqués
B. Plus de compatibilités côté portefeuille
C. Signer moins de fois

$BABY #baby

Ne vous précipitez pas à crier « Bitcoin DeFi en plein décollage » juste parce qu’un testnet fonctionne. Un petit succès et une grande sécurité, ce sont deux bulletins de notes totalement différents.

En rebalayant aujourd’hui la page des paramètres @BabylonLabs_io , je pensais au départ que 0,4 BTC correspondait simplement à une limite d’expérience standard. En continuant à regarder, j’ai compris : le public testnet actuel ne plafonne pas seulement 0,4 BTC par vault, par position et par adresse. L’exposition totale de l’application Aave v4 est aussi limitée à 10 BTC.

Ce n’est pas des données d’adoption : c’est une garde-fou de gestion du risque, qui réduit volontairement le rayon d’explosion. Le BTC natif de TBV reste verrouillé dans ses propres UTXO Taproot : pas de pont, pas d’emballage, pas de mélange dans un pool. Mais une petite capitalisation réduit naturellement la preuve de concurrence, le risque d’engorgement de liquidation et la pression sur la capacité des opérateurs.

Donc j’approuve le mécanisme, mais je n’étendrai pas un « flow qui tourne » à un « système qui tourne à grande échelle ». Pour l’instant, nous sommes toujours sur signet + Sepolia testnet : je regarde uniquement le taux d’utilisation du cap, le nombre de vaults actifs simultanément, et la latence P95 des preuves une fois la capacité augmentée, ainsi que le taux d’échec.

Le véritable point d’inflexion de Bitcoin DeFi n’est pas un démo plus joli : c’est le moment où, une fois les garde-fous progressivement desserrés, la sécurité tient toujours. Vous regarderez d’abord lequel ?

A. Nombre de vaults actifs
B. Stabilité après extension
C. Taille réelle des emprunts sur le mainnet

$BABY #baby