判断一条曲线库迁移是否“可用”，不能只看一句“已经迁移”。Dusk 当前公开材料给出的信息更适合拆成三层：Citadel 曲线栈迁到当前 Dusk curve stack，Citadel API 需要跟着修复，Dusk Curves 还涉及 BLS12-381 支持迁移到 Dusk 曲线库。三件事有关，但不是同一个交付物。

对产品使用者来说，第一层是依赖关系：旧曲线栈的调用者是否已经指向新的库；第二层是接口关系：API 修复后，原来的调用方式是否仍然成立；第三层才是具体曲线能力是否在目标库中可用。把三层压成“迁移完成”，会跳过最容易出错的衔接处。

这也是判断真实可用状态的关键。能确认的是迁移对象、接口修复和曲线支持各自被列出；不能仅凭这些材料确认所有业务已经切换、所有下游调用已经验证，或主网已经全面启用。对 @Dusk 和 $DUSK 感兴趣的读者，最稳妥的看法不是给迁移贴上成功或失败的标签，而是先问：谁负责库迁移，谁负责 API 适配，哪一层有直接证据？这比一句“基础设施升级”更接近真实决策。#dusk

迁移判断因此要落到责任与证据：库是否切换、接口是否适配、曲线支持是否验证，三者有清晰边界，才谈得上可用。

因此，产品团队在采用前需要确认迁移范围与验证责任，而不是把库名变化直接当作用户可见能力。

迁移工作的价值，不在于让所有人相信“更先进”，而在于让采用者知道自己依赖的库、接口和曲线能力分别处于什么状态。