2024 年还以“原始兑换平台”身份推出的 DotSwap V1，原本已经被官方归入“已停用”的旧版系统，但一场发生在 10 月 25 日前后的安全事件，又把这个名字重新推回了聚光灯下。据 On Nexus 公告与多家媒体报道，攻击者并非从当前产品线切入，而是绕道利用了 V1 遗留的服务器端签名路径，在约 4 小时的时间里完成整轮操作。单一来源称，约 8.5 枚 BTC 被从 DotSwap V1 的托管式多签流动性池以及相关账户中转走，按公告采用的估值口径约合 68.5 万美元，这些损失最终由当初向 V1 流动性池存入 BTC 的流动性提供者承担。更刺眼的是，对外宣称“退役”的 V1，关键的服务端签名机制却仍以遗留组件的形式驻留系统之中，为攻击者提供了现成的入口。公开材料尚未披露攻击者身份或资金后续链上流向，也未说明这一路径是否已被彻底关闭，但有一点已经被这次事件写在比特币生态的教训本上：退役不等于安全，只要托管式多签与服务端签名还残留在系统中，旧协议就仍可能是下一次攻击的薄弱环节。
退役平台成破口：旧签名路径被再激活
表面上，DotSwap V1 在产品线层面已经“退役”，品牌也完成向 On Nexus 的迁移，但这次事件暴露出，一个被标记为停用的前端，并不意味着其后端已经彻底谢幕。On Nexus 与多家媒体在公开渠道中确认，本次攻击并非针对当前主推的 On Nexus 产品，而是直接利用了 DotSwap V1 遗留的服务器端签名路径——这一路径作为服务端签名机制的一部分，在 V1 被视为旧版平台后依然保持可用状态，相当于为攻击者保留了一条可以替代用户自行签名的操作通道。
据单一来源描述，从攻击发起到结束，整个过程大约在 4 小时内完成，这种节奏更像是有备而来，而不是临时“撞洞”。要在如此短时间内完成多笔操作并成功将约 8.5 枚 BTC 从 DotSwap V1 的流动性池与账户中转出，前提是攻击者对 V1 的遗留签名机制、调用方式和权限范围有相当清晰的认知。对比产品线早已迁移到 On Nexus、V1 被官方归类为“已停用旧版平台”的对外叙事，这一现实显得格外讽刺：只要托管式多签背后的服务端签名服务仍在后台运行，它就可能在某个时间点被“再激活”，从一个被淡忘的旧版本，重新变成整个协议安全体系中最脆弱的攻击入口。
托管式多签失守：LP 在哪一环被暴露
对于向 DotSwap V1 池子注入 BTC 的 LP 来说，他们的头寸并不是传统意义上的“自托管”。公告已经点明，V1 流动性池的 BTC 由托管式多签统一管理，池子与 V1 账户构成了一套集中托管结构：LP 把币打进来，实际进入的是一个由项目方运营的多签金库，而不是各自独立掌控的链上仓位。只要这套多签还在运行，服务器端签名路径就相当于金库的一把钥匙，一旦被攻破，多签这一层“门锁”就名存实亡。
这次事件里，攻击者正是利用了 V1 遗留的服务器端签名机制，从托管式多签管理的 V1 流动性池和 V1 账户中，陆续转出约 8.5 枚 BTC。形式上看，是多签在执行合法转账；实质上，是服务端签名这一环节被替换为攻击者的意志，LP 的资产在他们毫不知情的情况下被“代表”签名挪走。损失直接落在所有向 V1 池存入 BTC 的流动性提供者头上，而公开信息里既没有给出受影响 LP 的数量，也没有披露单个 LP 的损失分布，这让一个原本被宣传为“多签更安全”的托管池，暴露出一个长期被忽略的现实：只要多签结构中存在服务端签名和运营侧集中权限，LP 的风险就不仅是链上的合约逻辑风险，更是对这条服务器签名链路能否被彻底关闭的信任赌博。
DotSwap-On Nexus 安全债务拖延
从叙事上看，DotSwap 在转型为 On Nexus 时，故事是干净的：旧的 DotSwap V1 被贴上“已停用”标签，品牌与主推产品全面迁移到新平台，用户被告知当前焦点在 On Nexus；但从技术结构上看，这次迁移更像是一场“装修换招牌”，而不是彻底拆除旧楼。公告与媒体口径都指向同一个薄弱点——V1 遗留的服务器端签名路径并未完全下线，这条原本应该随 V1 一起退役的签名链路，最终在 10 月 25 日前后被攻击者摸索出来，成为整起事件的关键入口。
结果是，商业叙事上已经完成升级的产品线，把技术上没有结清的“安全债务”抛在了身后，而这笔债最后由向 V1 多签池存入 BTC 的 LP 和旧账户用户代为偿还。更棘手的是，当前公开材料没有说明 V1 剩余资产是否已经完全安全，也没有明确遗留签名路径是否已被彻底关闭，风险到底被清零，还是只是被“静音”，外界无从判断。DotSwap V1 的遭遇提醒所有在迭代和品牌重塑中的协议：如果旧版签名服务和托管结构没有在技术层面同步退场，那么所谓“退役”的平台，只是把安全债务延后记账，而不是把它真正从资产负债表上抹掉。
比特币原生 DeFi 的托管与自治拉扯
在比特币原生 DeFi 场景里，许多协议不得不在「纯粹的用户自托管」与「可用的产品体验」之间折中：一头是完全由用户掌握私钥、链上逻辑简单透明，另一头则是引入服务端签名和托管式多签，由运营方帮助汇总指令、批量签名，以减少交互次数和复杂度。DotSwap 面向比特币原生资产，其运作本身就绕不开比特币层的签名与托管基础设施，V1 被描述为依赖服务器端签名路径并采用托管式多签管理 LP 资产，这种设计在降低用户门槛的同时，把一部分安全边界从链上合约，移到了运营方维护的签名服务之上。
DotSwap V1 的事件把这种架构的脆弱点照得很清楚：此次攻击面主要出现在服务器端签名路径，而非公开的链上合约参数变更，协议层「代码是否安全」不再等同于整体系统是否安全。相比完全用户自托管的模式，这类托管与自治混合结构要求参与者额外关注的是——运营方如何退役旧系统、如何关闭遗留签名通道、如何持续管理这些托管多签，而不仅仅是阅读一次合约审计报告。公开材料没有提供链上成交量、未平仓头寸或资金费率等量化指标，这起事件更多暴露的是签名与托管架构层面的结构性风险，而不是某种可被直接量化的市场结构变化信号，在比特币原生 DeFi 里，安全与体验的拉扯正在这种细节中不断累积风险成本。
8.5 枚 BTC 被盗后团队与 LP 关注点
约 8.5 枚 BTC 在约 4 小时内从 DotSwap V1 托管式多签管理的流动性池与 V1 账户被转出，这次事件对团队的直接提醒，是“退役”一个协议绝不等于只关掉前端或把产品线改名，而是要把所有服务器端签名路径、托管组件和遗留权限真正下线，否则被标记为“已停用”的旧系统依然会作为高价值攻击面长期暴露。对于向 V1 池存入 BTC 的 LP 以及更广泛的比特币原生 DeFi 用户而言，这次损失也暴露一个长期被忽视的盲点：当参与托管式多签、服务端签名驱动的产品时，风险不应被简单等同为“链上合约风险”，而是需要预先弄清资产实际托管路径、在退出或协议关停时资产如何安全归还，以及一旦出现问题，责任主体是运营方、托管方还是保险方。当前公开材料主要来自 On Nexus 的公告与媒体报道，尚未披露攻击者身份、链上资金追踪、资金追回或赔付安排，也没有说明 V1 遗留签名路径是否已经完全关闭、是否会引入第三方安全审计，接下来值得关注的是 On Nexus 是否会补充更完整的安全复盘与遗留资产处置计划，以及在这些关键信息仍然缺失的背景下，比特币原生 DeFi 生态是否会重新评估对托管式架构的容忍度，把“退役协议”的安全边界画得更清晰、也更难被忽视。
加入我们的社区，一起来讨论，一起变得更强吧！
AiCoin专属Hyperliquid福利：https://app.hyperliquid.xyz/join/AICOIN88
AiCoin专属Aster福利：https://www.asterdex.com/zh-CN/referral/9C50e2
链上电报（Telegram）社群：https://t.me/AiCoinWhaleData
链上社区：https://www.aicoin.com/link/chat?cid=N6OVMor5g
AiCoin链上推特：https://x.com/aicoinwhaledata
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到[email protected]，本平台相关工作人员将会进行核查。
