币圈界报道：

Gnosis Pay安全事件深度解析：从漏洞爆发到全面应对

Gnosis联合创始人Martin Köppelmann公开承认，其推出的Gnosis Pay支付产品遭遇了针对延迟执行模块的恶意攻击，并确认项目将承担所有受影响用户的资金损失。目前，团队正全力遏制漏洞扩散，控制潜在影响范围。最初，Köppelmann建议用户立即提取资产，该警示随后获得区块链安全机构PeckShield的强化支持，后者明确呼吁用户尽快转移包括EURe和GNO在内的全部资金并评估自身暴露风险。然而，指导立场迅速调整——原始警告被撤回，取而代之的是说明多数用户将无法完成提款操作。此后，Köppelmann重申团队正在积极应对，确保用户获得全额赔偿。

核心问题未解：损失规模与技术根源仍模糊

尽管赔偿承诺为用户提供了心理保障，但关键的技术疑点仍未澄清：实际被盗金额几何？哪些具体合约或账户受到波及？漏洞究竟源于Zodiac延迟模块本身的设计缺陷，还是其在Gnosis Pay中的部署方式，抑或是更深层的系统架构问题？作为以太坊生态中历史悠久的基础设施项目，Gnosis以其智能合约钱包工具和兼容EVM的Gnosis Chain网络著称。此次事件之所以格外敏感，是因为Gnosis Pay直接面向终端用户，属于支付层而非单纯的DeFi收益产品，其安全性直接影响日常金融交互的可信度。

延迟机制为何成为攻击入口？

本次事件使“延迟模块”这一本应增强安全性的组件陷入争议。该机制原意是通过设置交易排队时间，赋予用户或管理员在资金转移前识别并阻止异常行为的机会。然而，现实情况显示，若攻击者能将恶意提款指令注入共享队列，整个系统可能因共用基础设施而面临集中性风险。前Near协议核心开发者Vadim Zacodil指出，Gnosis Pay采用统一延迟层处理来自多个Safe钱包的转出请求，这种设计使得单个漏洞可同时影响数千名用户的交易队列，即便各自的私钥未被泄露。这揭示了一个重要事实：即使资产仍由用户自主控制，其操作安全性却高度依赖于共享模块、中继服务、交易队列管理以及项目方的应急干预能力。在此案例中，损失控制主要依靠Gnosis动用国库资源进行补偿，虽有效缓解用户损失，但也暴露了自托管模式在平台级风险面前的脆弱性。

投资者需重新审视“去中心化”表象

Gnosis Pay事件凸显一个关键认知偏差：智能钱包的安全边界远不止于私钥保管。当交易延迟、路由逻辑、自动化执行等环节依赖外部共享组件时，用户看似拥有控制权，实则仍处于平台运营方设定的规则框架内。一旦这些基础设施出现故障或被滥用，风险会迅速蔓延至大量账户，形成协同性攻击效应。因此，真正决定安全性的，往往是那些不显眼却至关重要的底层模块与流程配置。

对智能钱包信任体系的冲击

此次事件恰逢智能合约钱包生态面临多重挑战之际。此前，与Safe钱包关联的SquidRouterModule合约曾被滥用，导致约86个Safe账户被窃取超320万美元，尽管官方声明漏洞不在核心协议范围内，但仍引发市场对第三方集成模块风险的高度警觉。如今，Gnosis Pay的事故进一步加剧了此类担忧。随着智能钱包逐步成为加密支付、账户抽象、机构接入的核心载体，其灵活性带来的便利也伴随着复杂性增加——每一条额外功能都引入新的合约依赖，必须持续验证与监控。对于普通用户而言，难以直观判断一个“自托管”钱包是否真具备抗风险能力，因为其背后的操作逻辑可能早已嵌入共享基础设施的控制链中。

市场反应与长期影响

事件的最终影响取决于损失数额、受波及的合约范围，以及项目方对漏洞性质的定性——是配置失误还是深层架构缺陷。在这些信息尚未完全披露前，此事件仍属未决风险。若Gnosis能及时透明地兑现补偿承诺，并公布完整的漏洞分析报告，或可部分修复声誉损伤。但仅赔偿并非终点，项目还需解释攻击路径、模块响应机制、初始警告变更原因，以及后续防范措施。对整个市场而言，该事件或将推动更严格的尽职调查标准：交易所、金融科技伙伴与机构客户或将不再仅关注钱包是否非托管，而是深入审查其资金移动所依赖的共享合约、延迟机制与中继网络。值得注意的是，当前加密漏洞总损失呈下降趋势——CertiK数据显示5月损失降至约6830万美元，为年内第三个月低于1亿美元。在此背景下，一起高调的支付层攻击事件，反而可能重新点燃公众对基础设施安全的关注。

根本教训在于：钱包安全已演变为一个系统性议题。私钥控制、Safe账户结构、模块化组件、中继器网络与紧急暂停机制共同构成一个复合风险堆栈。Gnosis Pay事件表明，当共享层失效时，单纯强调“自托管”不足以抵御协同式攻击，真正的安全需要从整体架构层面构建韧性。