Bloom Trading 盗币报道涉及 9,408 SOL，团队承诺赔付 9 个钱包

9,408 枚 SOL 是怎样的统计

Odaily 于 10 月 26 日新加坡时间 12:26 发布快讯，称约 95.4 万美元资金流向疑似盗币地址。该报道将数字归因于 Onchain Lens：一个盗币钱包从 49 名受害者处获取 9,408 枚 SOL，最终数量可能更高。单笔被盗金额最高为 1,636 枚 SOL，约合 16.6 万美元。Odaily 报道

PANews 使用了相同的数量、受害者人数和最大单笔金额，并同样引用 Onchain Lens。这说明两家媒体提供了可读取的报道，但损失统计来自同一个监测源，不能计作两次独立链上调查。本文保留这一归因，不声称已经自行核对全部受害钱包。

美元金额是报道当时的近似换算，并非本文查询到的即时 SOL 价格。整理自己的损失时，先按交易记录列出 SOL 数量，再单列估值采用的时间与方法。用后来价格计算出的美元数，不能直接替代这篇快讯原有的统计口径。

最大单笔 1,636 枚 SOL 也只属于监测报告。两篇报道都没有说，这笔损失就是 Bloom 已受理的最大赔付申请。没有具体钱包对应关系前，不要把这项数字移入团队的赔付清单。

团队承诺了什么，哪些仍未说明

PANews 将 Bloom Trading 描述为跨链交易自动化平台。报道说，团队将全额赔偿 9 个受影响钱包的损失，资金直接转入各钱包持有人指定的新安全地址。团队仍在调查事件根因，包括第三方服务提供商是否遭到入侵。PANews 报道

已读取的文章没有列出赔付完成清单、到账交易签名、明确付款期限或详细申请流程。可以确认的是媒体报道了这项承诺及其拟采用的接收方式；实际支付状态需要另有记录支持。

49 名受害者与 9 个钱包可能存在某种包含关系，也可能采用不同识别口径，但目前报道没有给出答案。用 49 减去 9，无法得到一个已经核实的“未获赔人数”；把总损失除以 9，同样无法得出平均赔款。想了解自己能否获得赔付，最有用的问题是：团队是否认领你的受损地址，又为该地址确认了多少损失。

保存团队对具体地址的回应，与对应交易放在一起。如果后续监测总额变化，用户仍能保留最初提交的资产数量和团队答复。不要只保存一句笼统的“将会赔偿”，而遗漏它对应的钱包、金额和处理状态。

查钱包记录时，先区分成功转账和失败交易

Solana 官方交易文档说明，一笔交易包含指令、授权变更的账户签名和近期区块哈希；交易中的指令整体执行，只要其中一个指令失败，整笔交易失败，状态变更回退，但仍会收取费用。核对异常余额时，这意味着失败交易和已经完成的资产转出需要分别记录。Solana 交易文档

可以为每笔有争议的转账建立一条记录：交易签名、原钱包、交易记录显示的接收地址、资产数量和状态。如果钱包界面把多个动作放在一笔交易下，保存完整交易详情，不要只截取第一行。官方文档明确，一笔交易可以包含多条指令，界面上的一个名称未必涵盖全部动作。

再把这些记录与自己主动发起的交易对照，标注哪些转账认识、哪些存在争议。同期正常交易另列，避免把钱包全部流水算成失窃损失。这是一种整理证据的操作建议，并不意味着事件附近每一笔转账都被认定为恶意交易。

截图有助于保留钱包界面当时显示的内容，文字记录里也应留下交易签名。Solana 将签名列为交易结构的一部分。具体签名能让处理人员找到同一笔交易，减少仅凭余额截图反推转账的困难。已读取的新闻没有给出完整受害地址名单，用户不能单靠报道核对自己的钱包是否已经入表。

受影响用户现在可以核对的事项

Odaily 转述 Onchain Lens 的建议：立即断开钱包连接，将剩余资产转移到新钱包。这是监测方给出的应对建议，报道没有据此确认盗币机制。不要把这条建议扩写成“私钥已经泄露”“某项授权遭到滥用”或“第三方系统已被攻破”。

继续使用交易自动化服务前，先核对连接 Bloom 的究竟是哪一个钱包，以及仍需保护的资产分布在哪些地址。即使停止使用原钱包，也应保留其地址记录。PANews 说赔付拟发送至持有人指定的新地址，因此受损地址与赔付接收地址在申请中承担不同作用，登记时分开列清楚。

等待赔付时，核对联系渠道、团队认可的损失额和接收地址，再接受具体安排。已读取的报道描述直接向新地址转款，没有提到预付恢复费、补交押金或完成新交易后才能领取。不要因为陌生消息复述了新闻标题，就把它附加的步骤视作团队已经公布的流程。

同时使用中心化交易所和链上钱包的读者，应查看自己的实际转账历史。两篇来源讨论的是 Bloom 用户钱包资产失窃，没有确认某家中心化交易所被攻破，也没有公布某家平台暂停 SOL 服务。需要核对平台资料时，可从 交易所目录 进入相关页面；具体一笔充值或提现仍应回到自己账户中的对应记录。

整理材料时，还可以将损失和赔付各建一个状态栏。损失栏记录自己的核对结果及团队是否认可；赔付栏记录承诺、待支付或已经找到对应转账。把状态写在具体地址旁，避免一次回复更新后，误以为所有申请都已有同样进展。这是建议的记账方式，不是报道已经公布的处理程序。

若收到一笔看似赔付的款项，先匹配接收地址、资产种类与数量，再核对它对应的是哪一项申请。到账截图和团队说法可以一并保留，但不要仅凭钱包余额增加就宣称全部损失结清。对自己尚未提交或尚未得到回应的部分，继续单独列明。若团队后续改变统计范围，原始交易记录仍能保留每笔损失的具体边界，而不会随新闻中的总额一起改写。

后续怎样才能确认赔付与恢复

下一份有用的进展，应把三个原本分开的记录连接起来：损失统计包含哪些交易、团队受理哪些钱包、哪些转账实际结清了申请。对受害者而言，“计划赔付”与“某地址已经支付”回答不同问题。若附有付款交易记录，接收方才能进一步对照自己的钱包历史。

根因方面，PANews 转述的回应仍处于调查阶段。第三方服务提供商是否受侵只是调查方向，尚不能写成结论。已读取材料没有确认责任供应商、漏洞组件或修复完成情况，不能仅凭多个钱包失窃就替团队推定攻击路径。

准备重新使用 Bloom 的用户，可以要求团队说明受影响的访问路径，以及恢复服务前做了哪些变更。赔付承诺涉及由谁承担确认损失，技术说明则需要解释交易为何获得授权、哪些访问方式需要替换。收到其中一个答复，不代表另一个问题已经解决。

目前应分别保留 9,408 枚 SOL、49 名受害者和 9 个赔付钱包各自的统计范围。整理自己的交易证据，等候与具体钱包相关的付款确认及事件根因说明。更广泛的平台比较可继续查阅 交易所目录；本次事件仍待厘清的是监测损失、已受理申请与真实到账之间的对应关系。