加密安全事件时间线：接下来发生了什么，该怎么读

一条加密安全新闻，通常把好几件事压缩成一个吓人的词：被黑了。这个词可以指智能合约的逻辑错误、验证者私钥被盗、恶意代码被塞进网站、多签团队被骗，或者交易所的托管被攻陷。而用户当下该怎么办，取决于坏掉的是哪个部件、攻击者拿到了什么权限，以及通向更多损失的那条路是不是还开着。

第二次压缩，发生在「恢复」的新闻标题里。「跨链桥回来了」「资金已足额」「漏洞已控制」「受影响用户已获全额补偿」——这四句话不是同义词。一个协议可以修好有问题的代码，却在重建余额期间继续保持暂停。一个平台可以在自己吃下一笔金库损失之后，让提现照常运行。被盗资产可以被冻结，但没有被归还。攻击者可以把钱还回来，而原本的设计缺陷仍然需要推倒重来。

本文研究 2022 至 2025 年的八份一手事件记录：Wormhole、Ronin、Euler、Ledger Connect Kit、Radiant Capital 的两起独立事件、Bybit 和 Cetus。选它们，是因为它们的官方报告暴露出不同的故障模式和不同的结果。目的不是按金额给灾难排名，而是建立一套在下一次全新事件里依然管用的阅读方法。

有用的问题不只是「它是不是被黑了」。而是：坏的是什么、还有什么在暴露、现在什么能用，以及谁真的把价值拿回来了。

每一份事件更新都该分开的四种状态

事件响应是分阶段展开的，而且阶段之间会重叠。团队常常在事实还不完整时就发布，因为用户需要立刻收到警告。早期的不确定是正常的。真正的编辑错误，是把一份早期声明当成最终事后报告，或者把某一个已完成的阶段，当成后面每个阶段都完成了的证明。

1. 发现：观察到了什么？

发现，从一个异常开始：一笔意料之外的转账、被扭曲的池子余额、未经授权的软件包版本、失败的签名流程、异常的提现，或者外部研究者的告警。第一条通知可能用词谨慎，比如「正在调查」「疑似事件」或「异常活动」。这种谨慎未必是在回避；范围本来就还在确定中。

一份好的发现通知，会写明已知最早时间、受影响产品和当下的防范措施。它不该去猜是谁干的。链上交易能显示资产往哪去了，但这本身并不能证明谁控制着目标地址。一份公司声明可以指认哪些基础设施被攻陷，但之后的取证报告，可能会收窄或修正根本原因。

2. 控制：损失还会不会继续？

控制，意味着关闭或限制那条正在被利用的路径。协议可能暂停合约、停用某个市场、轮换密钥、替换恶意软件包、屏蔽某个钱包界面，或者请求验证者拒绝来自具名地址的交易。交易所可能把资产从正在被调查的钱包体系中转走。这些动作，应该和攻击面对得上。

控制也可能是不彻底的。一个补丁可能只保护了新的交互，而攻击者掌握的私钥在别处依然有效。前端可以是干净的，但用户手上仍然留着事件期间授出的恶意授权。如果冻结依赖的是自愿配合，那被冻结的资产照样可能动。读者应该去找一份逐个部件说明的表述，而不是把「已控制」当成一句技术描述来接受。

3. 恢复：用户现在能安全地用什么？

恢复，是有控制地把服务放回来。它可能需要代码复核、审计、余额对账、测试、治理批准、流动性补足，或者迁移到新合约。一项服务重新开放，并不能证明每一个受影响账户都得到了补偿。它只能证明：运营方认为，在新的条件下，那项写明的功能可以用了。

恢复公告应当点名受支持的界面，以及任何需要用户配合的动作。一座跨链桥可能在一个新合约上重开。一个去中心化交易所，可以先恢复未受影响的池子，再恢复受影响的。一家交易所可以在更换托管方案的同时，保持交易和提现开放。旧书签和旧合约在废弃之后可能仍然可达，所以「官方指定的地址」很重要。

4. 追回：哪些价值被归还、被补足或被赔付了？

追回，是一个经济和法律层面的结果。被盗资产可以由攻击者归还、被验证者或发行方冻结、由赞助方补足、由公司资产负债表承担、通过 DAO 方案偿付，或者干脆一直不见踪影。每条路径给用户的权利主张和时间表都不一样。

「资金已追回」应当写明数量、资产种类、接收方和剩余缺口。美元数字会随市场价格变化，所以代币数量和估值时点很重要。「用户已获全额补偿」应当写明是哪些用户、哪些余额。金库损失可能被排除在外，哪怕零售余额已经补齐。一份储备金证明报告，可以支持交易所当前的足额说法，但并不能证明被盗资产本身被追回了。

「被黑了」这三个字里藏着的四类故障

跨链桥验证与验证者失陷

跨链桥必须判断：一条链上的事件，够不够格在另一条链上释放或铸出价值。如果消息验证可以被伪造，那么没有对应抵押的包装资产就能被造出来。如果足够多的验证者私钥被攻陷，一笔提现就能在桥自己的门槛规则下显得「已获授权」。

Wormhole 和 Ronin 展示了这个家族的两个版本。Wormhole 2022 年的事件，出在 Solana 一侧的验证逻辑上。Ronin 的事件，则是验证者私钥被攻陷，而攻击者能凑够那个门槛。两者影响的都是桥，但根本原因、补救方式和信任假设完全不同。「跨链桥被攻击」只是个类别标签。

智能合约逻辑与记账错误

智能合约完全可以严格按代码执行，而代码本身允许一个经济上无效的状态存在。Euler 缺少的那次健康度检查，让「自我清算」这条路走通了。Radiant 在 2024 年 1 月的事件，涉及一个刚上线、储备为空的市场的流动性指数。Cetus 报告的，则是它的集中流动性池所用数学库里一处错误的溢出检查。

审计降低风险，但不能证明不存在可被利用的行为。代码变更、库依赖、异常的初始条件，以及函数之间的相互作用，都可能造出此前评审没有覆盖到的路径。当一个团队说合约「审计过」，接下来该问的是：审的是哪个版本、审的范围是什么、以及那条脆弱路径在那次评审时是否已经存在。

软件供应链与前端失陷

一个协议的链上合约可以纹丝不动，而那个负责构造交易的软件却变成了恶意的。Ledger 的 Connect Kit 事件，起因是攻击者拿到了一名前员工的软件包发布账号，发布了这个 JavaScript 库的恶意版本。加载了该软件包的第三方去中心化应用，可能因此弹出一个会掏空钱包的交互。

这一类改变了用户该做的核查。光盯着合约地址，可能看不出来一个网站正在构造一次恶意授权或转账。这时真正重要的，是在可信钱包屏幕上看清楚交易详情、把依赖版本锁死、校验软件包完整性，以及管好部署权限。硬件钱包保护的是私钥不被导出；当持有者亲手授权了有害指令时，它无法让那笔交易变得安全。

签名欺骗与运营环节失陷

多签托管的设计初衷，是让任何一把私钥都不能单独行动；但它仍然依赖签名者彼此独立，以及他们所看到的信息是真实的。Radiant 2024 年 10 月的事后报告描述：参与者的设备被攻陷，屏幕上显示的是合法的交易信息，实际签下的却是恶意交易。Bybit 2025 年 2 月的调查，则指向 Safe 基础设施被攻陷，以及一次常规冷钱包转热钱包过程中被欺骗的签名流程。

签名的个数，不等于整个安全模型。如果几个签名者看的是同一个被做过手脚的界面，或者共用同一条脆弱的操作路径，那么这些批准在实际上就不是相互独立的。强健的体系会用交易模拟、带外核验、已知合约哈希、角色分离、延迟和限额，让一块看起来很有说服力的屏幕，没法授权出无限的改动。

八份事件档案：按「故障」和「结果」来读

2022 年 2 月 2 日 —— Wormhole：伪造的验证，之后是资本补足

Wormhole 报告称其网络被利用，损失 120,000 枚包装 ETH。官方事件说明描述了 Solana 一侧验证路径上的一处失效：攻击者得以造出一个伪造的验证状态，在没有对应锁仓 ETH 的情况下铸出包装价值。网络被暂停，漏洞随后被修复。

这起事件的经济结果，和「直接追回」并不一样。补入 ETH 之后，包装 ETH 重新做到一比一足额支撑，网络也恢复了运行。这次补足保住了支撑关系，但它不意味着攻击者归还了原始资产。对一个包装资产的持有者来说，当下真正要紧的两个事实，是「支撑状态」和「桥能不能用」。

长期有效的一课，关于消息的有效性。一座桥可以拥有一组分布式的守护者，却仍然在「验证守护者消息」的那个合约上出问题。读者应该去定位那个精确的验证边界，而不是把这件事翻译成「链被黑了」。

2022 年 3 月 29 日 —— Ronin：验证者私钥与一个跨链桥门槛

在发生涉及 173,600 枚 ETH 和 2,550 万枚 USDC 的未授权提现之后，Ronin 宣布跨链桥出现安全事故。它随后的安全工作，重点放在验证者的分散度、提现限额和治理变更上。这里的故障，并不是每一个 Ronin 用户的钱包都被攻陷了；而是攻击者拿到了足以批准跨链桥提现的验证者权限。

当这座桥于 2022 年 6 月 28 日重新开放时，Ronin 表示用户资金已一比一足额覆盖、用户已获全额补偿，同时另行说明了 Axie DAO 金库那部分的处理。重新设计的桥经过了内部和外部审计，并引入了熔断机制、分级审批门槛和每日提现上限。

这个过程把三个节点分开了：事故披露、安全重构，以及重开时的用户余额足额。只记下 3 月那笔损失的人，会错过整个恢复结构；只记下 6 月重开的人，则会错过那个催生新管控的验证者私钥故障。

2023 年 3 月 13 日 —— Euler：合约逻辑漏洞与协商归还

Euler V1 被通过一条涉及 donateToReserves 函数的代码路径利用。Euler 后来的说明解释：缺少的那次健康度检查，让攻击者可以制造出不健康的头寸，并从自我清算中获利。这个函数原本是此前一次修复的一部分，而且经过了评审——这恰恰说明，一次补救也可能引入新的交互风险。

经济结果很不寻常。经过链上沟通、调查和协商，攻击者归还了可追回的资金。Euler 基金会宣布所有可追回资金均已归还，Euler 后来也表示用户资产已完全恢复。但这次追回，并没有免掉「让受影响版本退役、并重建」的必要。

Euler 说明了为什么不能从漏洞机制推断追回结果。一次严重的合约损失，可能换来大量归还；一次较小的事件，可能一直悬而未决。攻击者后来的行为、法律压力、可追踪性和谈判，都是与代码漏洞相互独立的变量。

2023 年 12 月 14 日 —— Ledger Connect Kit：被投毒的依赖版本

Ledger 的 Connect Kit 事件，影响的是被第三方去中心化应用使用的一个 JavaScript 库。Ledger 表示，一名前员工被钓鱼，使攻击者得以发布 1.1.5、1.1.6 和 1.1.7 三个恶意版本。恶意代码利用一个假冒的 WalletConnect 项目，把用户资金重定向。Ledger 与合作方切断了这条路径，并发布了正版 1.1.8。

那句范围声明很关键：Ledger 表示，Ledger 硬件和 Ledger Live 的完整性未受影响。这次事件涉及的，是那些在窗口期内与加载了恶意套件的第三方应用交互、并签下了有害交易的用户。仅仅拥有一台 Ledger 设备、而没有和受影响应用交互，暴露程度是完全不同的。

对用户来说，这一课是：在可信屏幕上检查交易。「连接钱包」可能带来的，是远超一次简单登录的权限或交易。对开发者来说，软件包发布权限、锁定版本、代码评审和安全的构建流水线，都是安全边界的一部分。

2024 年 1 月 2 日 —— Radiant：一个刚上线的市场与坏账

Radiant Capital 的一月事后报告描述了一次基于闪电贷、针对 Arbitrum 上新引入的原生 USDC 市场的攻击。攻击在该市场储备为空的条件下操纵了流动性指数，制造出未经授权的借款和坏账。Radiant 暂停了相关活动，之后走了一套经 DAO 批准的偿付流程。

受影响的范围是一个市场，而不是所有挂着 Radiant 名字的链上组件。这个区分，决定了用户第一步该查什么：我的头寸在哪条链、哪个市场、哪个池子、哪个合约里？一条笼统的「Radiant 被黑」标题，没法告诉一个存款人他的那个市场有没有被碰到。

后来对共同坏账的偿付，并不是攻击者归还。它用的是项目资源，依据的是治理决定。两者都可能通向「用户余额被补回来」，但成本的落点不同，并且会影响协议未来的能力。

2024 年 10 月 16 日 —— Radiant：被攻陷的设备与恶意签名

Radiant 在 10 月经历了第二起、完全独立的事件。其事后报告称，三名长期贡献者——使用硬件钱包、设备也分布在不同地区——遭到攻陷。界面显示的是预期中的交易数据，而恶意的所有权变更交易，在后台被签署并执行。

这件事说明了：为什么一段事件史不能按品牌层面去概括。一月出问题的是市场的记账条件；十月出问题的是运营中的签名环境。针对其中一个的补救，未必能拦住另一个。对借贷逻辑做更多审计，本身并不会让开发者的设备或多签的交易复核变得安全。

Radiant 后续的更新表示，追偿仍在进行、结果不确定；2026 年，该 DAO 描述了一个收缩后、以追偿为重心的形态。这是一个「控制和调查并没有变成『受影响用户已完全恢复』」的例子。一条负责任的时间线，必须把结果留在开放状态。

2025 年 2 月 21 日 —— Bybit：一次被骗过的冷钱包签名流程

Bybit 的事件影响的是一次常规转账中的一个以太坊冷钱包。平台后来的取证更新称，被攻陷的 Safe 开发者凭据让攻击者得以未经授权访问 Safe 基础设施，并骗过签名者批准了一笔恶意交易。Bybit 和第三方评审方均报告，没有迹象显示 Bybit 自身的基础设施被攻陷。

Bybit 保持提现运行，并把资金从由 Safe 管理的地址转出。之后的一次储备金证明复核报告称，在补足储备缺口之后，范围内的客户资产已获得充分的一比一支撑。这是一个关于支撑与偿付能力的表述，不是「被盗资产已从攻击者那里回来」的证明。

这起事件暴露了「冷存储」和「安全操作」之间的差别。冷钱包限制了在线暴露，但资金的转移要经过一整套仪式：软件、设备、签名者和合约权限。如果这套仪式始终如一地呈现虚假信息，那么好几把有效私钥，也能一起授权出一个无效的结果。

2025 年 5 月 22 日 —— Cetus：池子数学、被冻结的资产与重启

Cetus 报告其部署在 Sui 上的集中流动性做市池被攻击。事件报告把漏洞归因于一个开源数学库中不正确的溢出检查。攻击者利用闪兑和流动性操作，用极小的输入造出一个虚高的头寸，把池子储备抽干。

Cetus 先停用了核心池子，随后停用了相关合约。Sui 验证者投票拒绝来自攻击者地址的交易，冻结了留在 Sui 上的那部分受影响资产；另一部分资产已经转移到生态之外。冻结减少了资产流动，但它本身并没有把所有权转回给用户。

该协议随后发布了恢复方案，并在完成修复、审计和余额工作后，于 2025 年 6 月 8 日重启。恢复同时依赖技术补救和一套针对受影响流动性的方案。这是一个很有参考价值的例子：整个生态的应对，把合约管控、验证者行动、治理和项目出资结合在了一起。

怎么建一份经得起后续修正的事件记录

一份有用的事件记录，是一串有出处的事实主张，而不是一段被定格在最混乱那一刻的话。为「第一次未授权动作」单起一行，再为「被公开发现」单起一行。这两者常常不是同一个时间。Ronin 的跨链桥提现，和它后来才被发现这件事，正好说明了为什么「事件日期」里可能藏着两个时钟。只要项目方提供了，就把交易时间、发现时间和披露时间分别记下来。

给每一次更新打上发布时间戳，并保留它原本的不确定措辞。如果第一份声明说这次事故「看起来仅限于」某一个部件，不要把它改写成最终结论。把后来的取证结论作为新的一行加上去。这能让记录如实反映用户在每个决策点上知道什么，也能避免事后诸葛亮把当初的应对说得比实际更笃定。

技术字段要分层写。大的家族也许是「智能合约逻辑」，但具体缺陷可能是「某个特定记账序列下缺少一次健康度检查」。受影响对象可能只是某条链上的某一个市场。攻击者拿到的权限，可能是「未经授权的借款」。有了这几层，另一个读者才能把根本原因、攻击手法和财务影响区分开。

经济字段至少留四列：最初受影响的资产、被冻结的资产、攻击者归还的资产、以及来自其它来源补入的资产。再加第五列：实际发放给用户的部分。一个项目可以如实报告很大的冻结量或补足量，而「发放」这一列仍然是空的。如果来源只公布了一个美元估计值，那就记下它的发布日期，别用今天的价格去更新那个数字。

写恢复情况时，列出功能，而不是写一句「已恢复上线」。充值、提现、兑换、借款、清算、领取和前端，可能在不同时间分别恢复。有的话，把合约或版本也写上。一项服务跑在新合约上，不代表旧合约被重新启用；用户需要知道项目现在支持的是哪个地址、哪条路径。

最后，留一个显眼的截止日期。安全调查、法律行动和追偿计划，可能持续好几年。本文的截止日期是 2026 年 8 月 23 日。日后再看到这一页的读者应该明白：「仍在进行」描述的是那个截止日期上有出处的状态，而不是对当下的断言。配套工具使用同样的边界，并为每张卡片链接到项目记录，好让当前状态的核查从来源处开始。

怎么在不靠猜的情况下读一份实时更新

先看受影响的对象

把那些名词原样抄下来。受影响的对象是一个钱包、一个市场、一座桥、一个软件包版本、一个前端、一组验证者、一个账户数据库，还是所有产品？除非公告自己给了定义，否则「基础设施」这个词太宽了。一个服务方可能运营着许多钱包和链，各自的密钥体系还不一样。

还要认清资产的表示形式。原生 ETH、另一条链上的包装 ETH，和一个跟踪 ETH 的基金份额，是三个不同的对象。一次跨链桥的支撑失效，可以影响包装形式，而完全不改变以太坊的账本。技术范围很窄的时候，代币价格照样可能大范围反应。

把已确认事实和工作假设分开

早期更新应当带上时间戳，并被当作暂定结论对待。「我们认为」「初步」「看起来仅限于」「正在调查」，都在告诉读者：边界还会移动。第一份通知也许只描述了一笔未授权交易，而后来的取证报告，可能把失陷归因到某个员工账号、某台开发者设备或某个第三方系统。

不要把一个链上标签当成身份。分析公司可以把地址聚类，官方可以把某场行动归因，但归因需要的证据，不止是一个眼熟的洗钱套路。如果一个项目说某个组织是责任方，请注意这是它自己的判断、某位具名调查者的判断，还是官方机构的认定。

找到下一步动作，以及它是给谁的

有用的行动指引是有范围的。「在进一步通知之前，不要与受影响的去中心化应用交互」和「把所有资产转走」，是两回事。开发者可能需要更新软件包，而用户需要撤销授权。流动性提供者可能要等一个余额重建流程，而普通代币持有者什么都不用做。

紧迫感必须挂在一条经过核实的路径上。在撤销授权或迁移之前，请独立地找到官方公告。攻击者常常买下搜索推广位、在事件帖子下面回复、发送假的赔付表单。一起真实事件，本身就制造出一大批「正等着看到反常指示」的观众。

追问：支持「已恢复」的证据是什么

恢复的证据可能包括一次修复提交、一份审计报告、一个新合约地址、一次治理投票、一个网络重启时间、一份储备金证明报告，或者一个公开的余额查询工具。它们各自证明的东西都不一样。审计评估的是写明的代码和范围，它不为项目的资产负债表背书。储备金证明在某种方法学下处理资产与负债，它不检验每一项运营内控。

最有力的更新，会写明自己的局限。它会说：哪些池子仍然暂停、哪些余额被排除在外、旧合约是否已废弃、下一份报告什么时候发。一句笼统的「一切系统正常」，远不如一张写清楚各项服务状态的表格有信息量。

用原生单位追踪追回情况

美元损失的估算会变，而攻击者手里的代币数量可能一枚没动。项目公布了资产和数量的，就照着记；估值口径另外记一行。如果一个项目说损失了 2 亿美元、而价格上涨后归还了 2.4 亿美元，那并不必然意味着回来的代币数量比出去的多。

把「归还」「冻结」「补足」「赔付」分清楚。归还，是资产从攻击者控制下回来。冻结，是资产受限，但可能还需要法律或治理动作。补足，来自赞助方或服务方。赔付，是用户在某个补偿方案下拿到价值。一个笼统的「追回百分比」，会把这几条路径全糊在一起。

为什么相似的损失会有不同的结果

架构决定了什么能被叫停

如果管理员保有相应权限，一个可升级合约可以被暂停或替换。一组验证者可以拒绝特定交易。一家中心化交易所可以转移储备，同时让内部账本继续运转。一个没有紧急控制的不可变合约，则无法原地打补丁。这些差异，决定了控制的速度，也决定了「去中心化」与「紧急干预」之间的取舍。

冻结不是没有代价的。验证者层面的干预，可以保住可追回的价值，同时也会引出关于交易中立性的治理问题。管理员暂停可以止住失血，同时制造出对密钥持有人的依赖。事件报告应当写清楚：是谁、依据哪条规则，行使了这项控制权。

资产负债表决定了谁能扛下损失

Wormhole 的支撑被补足了。Ronin 表示通过补入和重构，用户获得了全额补偿。Bybit 报告称，在填补储备缺口后，客户资产仍然足额。而一个更小的协议，可能只能依靠金库资金、代币治理、外部融资或未来收入。技术上的严重程度可以差不多，经济承受能力却可能天差地别。

用户不该因为以前发生过，就假设未来一定会有赞助方出现。一句「承诺弥补损失」，需要资金来源、法律义务和执行方案。「已承诺」和「已发放」，不是同一个阶段。

攻击者的行为会改变追回路径

Euler 那次协商归还，不是默认结果。有些攻击者会通过链上消息沟通；另一些则迅速洗钱、把钱输给别的攻击者，或者受制于制裁约束。悬赏可以制造激励，但不保证对方配合。项目方可能把谈判细节保密，因为公开会削弱追偿工作。

这就造成了一种沟通上的张力：用户需要足够的信息来保护自己，而调查方可能要隐去手段。一份有限的声明，不能证明背后没人在做事；但它仍然应该给出状态、范围，以及下一次更新的时间。

可组合性会把影响扩散到被攻击的合约之外

DeFi 头寸经常被用作其它协议里的抵押品、金库资产或流动性。一次攻击，可能在别处引发坏账、脱锚、清算或集成暂停。直接损失和下游敞口应当分开计数，以免重复统计。

对用户而言，这意味着要检查依赖关系。如果一个金库把资金存进了受影响的借贷市场，那么即便用户从没访问过那个借贷协议，这个金库照样有敞口。如果一个稳定币持有受影响的资产，那它自己的赎回状况就变得要紧。一个协议的状态页，未必会描述它的每一处集成。

一套不依赖小道消息的用户应对方案

1. 停止与被点名的部件发生新的交互。在官方来源澄清范围之前，不要签名、不要跨链、不要充值、不要授权。
2. 保留证据。保存交易哈希、账户记录、余额、时间戳，以及你当时用的那个确切界面。不要泄露助记词或私钥。
3. 确认暴露是否还在持续。一个恶意的代币授权、一个被劫持的会话或一把泄露的私钥，在网站修好之后依然危险。
4. 用你独立找到的官方渠道。手动输入你已知的域名，或使用此前保存的书签。不要点开回复区或私信里的赔付链接。
5. 照字面读那条行动要求。开发者、流动性提供者、交易所用户和硬件钱包用户，收到的指示可能完全不同。
6. 迁移先用小额试。在转移全部余额之前，确认目标合约和网络。
7. 追踪那四种状态。把「已发现、已控制、已恢复、已追回」分别写下来，每一条都带上来源和时间戳。
8. 事后报告出来之后再核一次。根本原因和受影响版本，可能和最初的通知不一样。

如果你的助记词或私钥已经泄露，那么撤销授权是不够的。资产应当转移到一个用未被污染的材料新建的钱包里，并遵循可信的钱包指引。如果只是某个代币额度被恶意授权，那么一笔经过核实的撤销交易，也许就能处理掉这个权限，而不必更换助记词。不要凭猜测判断自己属于哪种情况。

如果事件发生在中心化交易所，请把注意力放在提现、客户资产支撑、受影响的钱包，以及为你的账户提供服务的那个法律主体上。一次冷钱包失窃，不自动意味着内部账本资不抵债；而提现照常，本身也不能证明资产完全足额。运营层面的证据和余额层面的证据，都要看。

如果事件发生在 DeFi，请找出持有你头寸的那个合约，以及它是否可升级、是否已暂停。前端可能显示余额不可用，而头寸其实还在链上；反过来，池子被抽干之后，界面上显示的余额也可能是过期的。只有在官方恢复界面的合约被公布、并经过独立核实之后，才使用它。

第二起事故：假客服与追损骗局

安全事件天然创造出完美的社会工程条件。用户处在焦虑中，本来就在等反常的公告，而且可能相信自己必须在某个期限之前采取行动。骗子会冒充管理员、发布假的授权撤销工具、提出帮你「验证」钱包，并发出索要助记词的表单。

没有任何一次正当的追偿，需要你的助记词或私钥。即便不涉及这些秘密，仅仅「连接钱包」也可能是危险的——因为它可以请求授权或签名。请在钱包屏幕上把交易读清楚。如果那个界面没法解释这个动作到底在做什么，就停下。

留意域名替换、多出来的连字符、不同的顶级域名，以及搜索推广广告。官方社交账号本身也可能被攻陷，所以对影响重大的指示，请到项目的既有官网、状态页、治理论坛或代码仓库上交叉印证。一条被很多新账号转发的消息，不构成独立确认。

索赔类服务的生命周期，也可能比事件本身长。请从官方公告里把真正的索赔页面加进书签，并确认它有没有截止时间。骗子可能在真实窗口关闭之后，照着做一个一模一样的赔付页面。永远不要向一个来路不明的追损代理预付「解锁费」「gas 验证费」或税费。

事件之后，读者常问的问题

「漏洞已修复」是不是意味着可以放心再用了？

未必。脆弱路径可能已经打上补丁，而余额、集成关系或旧的授权仍然没解决。请等一份明确的恢复公告，它要点名你打算使用的那个服务、版本或合约。

硬件钱包能防住所有事故吗？

不能。它能保护私钥不离开设备，但它没法让一笔你已经授权的交易变得无害。一个被攻陷的前端，可以请求用户签下一次恶意授权或合约变更。在可信屏幕上复核、以及能看懂的清晰签名，仍然很重要。

既然要好几个人批准，多签为什么还会出事？

只有当签名者本人和他们的核验路径足够独立时，多把私钥才真的提升安全性。共用的被攻陷软件、被做过手脚的显示界面或失陷的设备，都可能让好几个有效签名者，一起批准同一个恶意动作。

被冻结的资金算追回了吗？

不算。冻结意味着流动被限制。要把钱还回来，可能需要发行方配合、验证者行动、法院程序、治理决定或一笔签名交易。冻结数量和归还数量，要分开记。

审计能保证一个协议不被攻击吗？

不能。一次审计，是在有限时间和方法下，检查一个界定好的代码版本和范围。之后的升级、依赖库、运营流程和未经测试的经济状态，都可能引入风险。审计是有用的证据，不是保证。

为什么不能只按美元损失给事件排名？

美元数字会随币价变化，而且它描述不了范围、用户结果或故障模式。一次规模较小的供应链失陷，可能波及大量应用；一次金额巨大的盗窃，可能被完全吸收掉。原生代币数量、受影响用户和追回路径，才补上了必要的语境。

这条时间线完整吗？

不完整。这是精选的八起事件，目的是讲清楚几种不同的阅读模式。数据集截止到 2026 年 8 月 23 日。这些事件请以文中链接的一手报告为准；任何新事件，请以当前的官方渠道为准。