$NEAR 支持抗量子账户签名，不等于整条链已经完成抗量子迁移。当前广场第六名的话题值得拆开看，但它对应的技术节点来自7月和9月，不能包装成今天刚上线的新功能。
第一层是账户如何授权交易。nearcore 2.13.0在7月9日发布，说明将ML-DSA-65作为第三种交易签名和访问密钥，与原有两种类型并列。这个变化让账户有新的验签选择，却不是让每个已有账户自动换钥，也不能据此确认全部账户都已采用新算法。
第二层是合约能否验证一段消息。9月16日的2.14.0-rc.1测试网候选版本增加ml_dsa_verify接口，面向合约验证消息。这与账户原生交易授权是不同入口：一个合约能检验签名，并不直接证明它控制的所有操作、外部资产或跨链消息都已完成安全迁移。测试候选也不能写成已经在主网完成部署。
第三层才是整套系统的迁移范围。账户签名只是其中一环，节点采用哪个协议版本、既有密钥怎样更新、其他依赖如何处理，都需要各自的证据。不能把某个模块采用新算法，推导成系统每一层都获得相同保障。
时间线也要分清。7月2日的开发者记录展示的是沙盒环境中的添加密钥与转账演示；7月9日是面向主网的版本发布；该版本另列出7月20日启动协议投票的计划。演示成功、发布版本、投票计划和实际网络激活不是同一个完成状态。本轮没有核验全网升级结果，因此不把计划日期当作部署回执。
对普通使用者，更具体的问题是：自己的账户是否真的配置了这类访问密钥，使用的钱包是否能正确生成、保存和签署它，应用是否支持相应流程。只看到新闻标题，不能判断手里的账户已经受到新签名方案保护。添加新密钥后，旧密钥权限如何处理，也应按账户实际设置确认。
对开发者，则要区分原生账户交易和合约消息验证。前者关系到谁可以授权账户操作，后者关系到程序如何判断某份消息有效；签名验证通过，也不代表消息内容、权限范围或业务逻辑天然正确。安全边界需要落在实际授权流程上。
我更关注接下来的可核节点：正式版本与协议激活记录、钱包支持情况、明确的迁移说明。当前能确认的是NEAR在账户与合约验签层推进不同能力；不能确认的是全部旧账户、应用及外部依赖都已一起完成迁移。这是技术范围的观察，不是从算法名称推导币价方向。
第一层是账户如何授权交易。nearcore 2.13.0在7月9日发布，说明将ML-DSA-65作为第三种交易签名和访问密钥，与原有两种类型并列。这个变化让账户有新的验签选择，却不是让每个已有账户自动换钥，也不能据此确认全部账户都已采用新算法。
第二层是合约能否验证一段消息。9月16日的2.14.0-rc.1测试网候选版本增加ml_dsa_verify接口，面向合约验证消息。这与账户原生交易授权是不同入口：一个合约能检验签名，并不直接证明它控制的所有操作、外部资产或跨链消息都已完成安全迁移。测试候选也不能写成已经在主网完成部署。
第三层才是整套系统的迁移范围。账户签名只是其中一环，节点采用哪个协议版本、既有密钥怎样更新、其他依赖如何处理，都需要各自的证据。不能把某个模块采用新算法，推导成系统每一层都获得相同保障。
时间线也要分清。7月2日的开发者记录展示的是沙盒环境中的添加密钥与转账演示；7月9日是面向主网的版本发布；该版本另列出7月20日启动协议投票的计划。演示成功、发布版本、投票计划和实际网络激活不是同一个完成状态。本轮没有核验全网升级结果，因此不把计划日期当作部署回执。
对普通使用者，更具体的问题是：自己的账户是否真的配置了这类访问密钥，使用的钱包是否能正确生成、保存和签署它，应用是否支持相应流程。只看到新闻标题，不能判断手里的账户已经受到新签名方案保护。添加新密钥后，旧密钥权限如何处理，也应按账户实际设置确认。
对开发者，则要区分原生账户交易和合约消息验证。前者关系到谁可以授权账户操作，后者关系到程序如何判断某份消息有效；签名验证通过，也不代表消息内容、权限范围或业务逻辑天然正确。安全边界需要落在实际授权流程上。
我更关注接下来的可核节点：正式版本与协议激活记录、钱包支持情况、明确的迁移说明。当前能确认的是NEAR在账户与合约验签层推进不同能力；不能确认的是全部旧账户、应用及外部依赖都已一起完成迁移。这是技术范围的观察，不是从算法名称推导币价方向。