下午 2:13 – Moonbeam 团队与 Moonwell 团队联系，后者已被 EDT 直接联系。Moonbeam 团队要求立即提供一份 Immunefi 报告，以确定真实性和响应所需信息。

2:25 – PM Moonbeam 技术事件响应团队与 Moonwell 团队代表召开会议，讨论报告。然后将该问题上报给整个业务事件响应团队和 Moonbeam 和 Moonriver 的技术委员会。

下午 2:36 – 白帽要求介绍 Parity 和 Astar 团队。Moonbeam 建立了一个 Telegram 组，用于与白帽团队的内部讨论，并联系被请求团队加入讨论。

3:10 PM – 白帽向 Moonbeam 和 Astar 提交 Immunefi 报告。

3:21 PM – Moonbeam 团队收到报告，重新召开会议并决定进行程序修补，但不将网络置于维护模式。

下午 4:00 – Parity、Moonbeam 和 Astar 确认了问题的严重性。Moonbeam 开发团队设定了更新时间表，并开始着手开发补丁。

下午 5:00 – 通讯发送给生态系统团队。

下午 6:13 – Astar 团队在公共存储库中发布了该问题的修复程序。

下午 6:33 – Moonbeam 团队注意到已发布的代码，并要求技术委员会将网络置于维护模式。开始与重点项目就维护模式进行沟通。

下午 6:46 – 通过 Moonriver 和 Moonbeam 技术委员会制定维护模式，并启动外部通信。

7:46 PM – 更新完成，CI/CD 开始，随后是回归测试和部署多个测试网络。

晚上 8:05 – Moonbeam dApps GUI 离线以防止出现意外行为。

晚上 9:40 – Moonriver 对升级进行投票。由于 EVM 功能在维护模式期间不可用，因此无法使用 Polkassembly。

晚上 10:31 – Moonbeam 升级获得批准，并延迟 60 分钟排队。

晚上 10:58 – 两个网络都成功升级并生产区块。技术委员会对取消维护模式的投票已提交。

Moonriver 技术委员会提案 #92

Moonbeam 技术委员会提案 #50

晚上 11:05 – 维护模式解除，两个网络恢复全部功能。

晚上 11:49 – Moonwell 确认他们的所有服务都已完全恢复。

晚上 11:50 – 升级确认将发送到 Twitter、Telegram、Discord 和 Reddit。