DotSwap V1 遭遇攻击，约 8.5 BTC 被盗，损失估计达 68.5 万美元
DotSwap V1 遭遇攻击，约 8.5 BTC 被盗，损失估计达 68.5 万美元
10 月 25 日，DotSwap 交易平台的旧版 DotSwap V1 遭到攻击，约 8.5 BTC 被盗。事发时，这些比特币价值约 68.5 万美元。
此次事件凸显了比特币应用面临日益严峻的安全挑战：即使用户操作的是去中心化资产，后端授权系统、托管型流动性基础设施和自动签名服务仍可能形成中心化故障点。
根据 On Nexus 发布的事件更新，受影响的平台目前已经下线。团队正在调查攻击、追踪被盗资金，并与交易所及区块链情报合作伙伴展开合作。
DotSwap V1 发生了什么？
DotSwap V1 采用服务器端签名模式来管理流动性池。其流动性基础设施通过托管型多重签名机制运行，这意味着用户存入的 BTC 由平台的签名流程控制，而不是由各个流动性提供者直接掌控。
据报道，攻击者利用了 V1 后端中仍处于启用状态的一套旧版签名机制。在大约四个小时内，自动化脚本通过平台开放的接口与系统交互，逐步转移 V1 流动性池和用户账户中的资金。
此次攻击并未局限于单一代币或单个接口。据报道，这些脚本测试了平台的各类接口，并针对与 99 种符文代币相关的资产展开攻击，使攻击者能够在更广泛的应用环境中识别并利用漏洞。
损失总额估计约为：
- 8.5 BTC 被盗
- 受影响资金约 68.5 万美元
- DotSwap V1 中流动性提供者的存款受到影响
- 平台外由用户自行控制的钱包未受影响
DotSwap V1 此后已被关闭。On Nexus 表示，团队正在努力恢复相关服务，并将发布更完整的事件分析报告以及面向受影响用户的处理方案。
为什么流动性提供者成为主要受害者
此次事件中最重要的区别，在于平台管理的资金与存放在用户自有钱包中的资产之间的差异。
将 BTC 存入 DotSwap V1 的流动性提供者，面临着平台托管和签名架构所带来的风险。尽管该系统采用了多重签名控制，但签名流程仍与后端服务相连接，而这些服务可以通过应用接口被查询和触发。
这意味着，仅依靠多重签名保护并不能完全消除运营风险。如果授权逻辑、API 权限、签名策略或服务器端控制机制设计不当，攻击者仍可能找到生成有效交易的方法。
相比之下，将资产存放在自托管钱包中、且未将资产存入 V1 流动性池的用户，并未受到此次事件影响。他们的私钥始终位于遭到入侵的平台环境之外。
理解流动性池风险的关键就在于这一点：
一个协议可能使用区块链进行结算，但在托管、签名、定价、路由或访问控制等环节，仍然依赖中心化基础设施。
因此，用户不应只评估某个应用是否「在链上」，还应了解签名权限位于何处、谁控制提款权限，以及存入的资金是否可能被后端系统冻结或转移。
AI 辅助攻击自动化的一个可能案例
On Nexus 认为，此次事件与近期出现的一类由 AI 驱动或高度自动化的攻击趋势相吻合。
自动化技术能够显著提升攻击的速度和范围。攻击者无需一次手动测试一个功能，而是可以通过程序自动执行以下操作：
- 发现暴露在外的 API 接口
- 提交大量请求
- 比较不同资产返回的响应
- 检测授权行为中的不一致之处
- 识别异常的签名或提款路径
- 快速连续执行交易
在支持数十种代币合约和交易路由的环境中，自动化能够更轻松地识别出一些在日常手动测试中可能难以察觉的细微实现差异。
更广泛的启示是，安全团队如今必须防范将传统脚本与能力日益增强的 AI 代理相结合的攻击。API 发现、漏洞分类、交易构造和监控等环节，都可以通过自动化工具加速。
这一趋势使得速率限制、端点隔离、异常检测、签名策略执行以及实时交易监控，对于数字资产平台而言变得越来越重要。
该事件揭示了 Runes 基础设施的哪些问题
Runes 生态扩大了可在比特币上发行和交易的同质化资产范围。然而，支持这些资产的基础设施仍在发展之中，许多应用依赖索引器、链下服务、托管池以及专门的交易逻辑。
这带来了多个风险领域：
- 对索引器的依赖： 钱包余额和代币状态可能依赖第三方索引服务。
- 后端授权： 平台可能使用中心化 API 来决定某笔交易是否可以签名。
- 托管流动性： 用户可能会将 BTC 存入由应用管理的资金池钱包。
- 合约和资产的复杂性： 支持大量 Runes 资产会增加需要测试的交易路由、接口和边界情况的数量。
- 运营集中化： 一项遭到入侵的签名服务可能同时影响多个资金池。
探索 Runes 交易或提供流动性的用户，应在存入资金前审查项目的托管模式。平台的用户界面看似去中心化，但重要的控制功能仍可能由中心化系统掌握。
如需了解比特币资产生态的背景，用户可以参考比特币开发者文档以及Bitcoin Optech 新闻通讯，后者会定期介绍比特币协议、钱包和基础设施的最新进展。
面向加密货币用户的实用安全经验
1. 确认资金是否始终由你控制
在提供流动性或存入资产之前，应确认平台是否能够在没有经过你钱包直接签名的情况下转移资金。
值得提出的问题包括：
- 存款会被发送到由用户控制的地址，还是由平台控制的地址？
- 私钥由谁持有？
- 签名是在本地完成、通过硬件设备完成，还是在服务器上完成？
- 管理员能否暂停提现或更改签名规则？
- 提现限额和监控控制措施是否有公开说明？
这些问题的答案可能会实质性地改变该服务的风险状况。
2. 将旧版产品视为潜在的攻击面
DotSwap V1 事件说明了为什么平台的旧版本不应继续连接到活跃服务。即使新版本具备更强的控制措施，过时的 API、签名路径和账户权限仍可能被利用。
项目方应通过以下措施彻底停用已退役的产品：
- 撤销 API 凭证
- 移除旧的签名权限
- 禁用未使用的端点
- 轮换服务密钥
- 将旧版数据库与生产系统隔离
- 监控历史基础设施，及时发现异常活动
3. 避免将资产集中在单一应用中
流动性提供者应考虑在不同钱包、协议和托管模式之间进行分散配置。将大量 BTC 集中在一个应用中，可能会放大单次漏洞利用或运营故障所造成的影响。
这并不能消除协议风险，但可以降低单一事件波及整个投资组合的可能性。
4. 监控钱包活动和授权情况
用户应定期检查钱包余额、已连接的应用、账户会话和交易记录。意外出现的签名请求、不熟悉的提现地址或新的设备登录，都应被视为潜在的警示信号。
对于高价值交易，用户应独立核实以下内容：
- 目标地址
- 资产及金额
- 网络
- 交易费用
- 应用域名
- 钱包显示的最终交易详情
5. 了解多重签名并不等于完全去中心化
多重签名方案可以提升系统的韧性，但其有效性取决于签名者的分布方式以及授权机制的执行方式。
如果所有签名者都由同一个组织控制、连接到同一个后端，或受同一个存在缺陷的策略引擎约束，那么系统仍可能存在实质性的中心化故障点。
安全性取决于完整的签名架构，而不仅仅是是否存在多个签名。
受影响用户需要注意的事项
连接到 DotSwap V1 的用户应警惕声称可以提供退款、赔偿或紧急提现工具的钓鱼信息。攻击者经常利用公开事件冒充项目团队，并引导受害者访问虚假网站。
受影响的用户应：
- 仅关注经过验证的项目官方沟通渠道
- 避免在网站中输入助记词或私钥
- 对未经请求的退款表单保持警惕
- 保存交易 ID 和存款记录
- 独立查询区块链信息
- 监控相关钱包地址是否发生资金转移
- 在签署任何内容前，等待官方的恢复或索赔流程
合法的支持团队绝不会要求提供钱包恢复短语来验证所有权或处理退款。
如需了解保护数字资产的一般指南，CISA 网络安全指南提供了有关网络钓鱼、账户安全和恶意活动的实用信息。
对 DeFi 和比特币应用的更广泛影响
DotSwap V1 漏洞利用事件并不只是关于某个平台存在漏洞的故事。它反映了加密行业面临的一种更广泛的矛盾：应用可能向用户呈现去中心化的界面，但在幕后却依赖中心化组件。
随着基于比特币的金融应用日趋成熟，安全审查需要覆盖的不应只是智能合约代码。审计还应检查：
- API 身份验证与授权
- 服务端签名服务
- 密钥管理与签名者隔离
- 数据库权限
- 资产索引系统
- 升级与关闭流程
- 监控与事件响应
- 紧急提现机制
在 2025 年，自动化代理和 AI 辅助开发的使用日益增多，这使得审查流程更加重要。如果安全控制措施没有以同样的速度发展，更快的软件开发和自动化交互可能会扩大攻击面。
对用户而言，最可靠的保护仍然是清楚了解资产托管方式。直接存放在自托管钱包中的资产，与存入平台控制的资金池中的资产，面临的是不同类型的风险。两种模式都不是完全没有风险，但风险来源存在显著差异。
硬件钱包如何融入更安全的自托管策略
硬件钱包可以通过将私钥与联网应用隔离，帮助降低服务器端遭到入侵所带来的风险。当用户与去中心化应用交互时，可以通过专用签名设备查看并批准交易详情，而不是完全依赖浏览器界面。
OneKey 硬件钱包专为自托管流程设计，支持离线密钥保护和设备端交易确认。它们无法消除智能合约风险、网络钓鱼、恶意界面或市场波动风险，但可以帮助用户继续掌控那些并非有意存入托管平台或流动性池中的资产。
核心原则很简单：在提供流动性或授权交易之前，用户应了解资金由谁控制、自己正在签署什么，以及平台是否能够在未经其直接批准的情况下转移资产。
DotSwap V1 损失约 8.5 枚 BTC 的事件再次凸显，托管架构、签名权限和运营安全所应受到的重视程度，并不亚于代币的实用性或交易量。在日益自动化的加密领域，知情的自托管与谨慎的交易验证仍然是至关重要的防御手段。
