Loopscale 暂停协议：每日逾 3 万次恶意请求，金库补足后仍须查还款状态

金库补足，回答不了全部访问问题

报道描述，安全系统检测到攻击显著升级后，团队暂停了协议活动，以减少影响。攻击尝试主要针对 SOL 和 USDC Genesis Vaults，相关金库已经补足。可读材料没有给出补足金额，也没有按金库列出资金影响明细。

对用户，这是两个不同的问题。一个是团队如何描述存款状态：报道转述的是用户存款没有损失。另一个是用户此刻能做什么：协议活动仍暂停，恢复正常运营附有条件。资金状态的声明不能替代对提现是否可执行的检查。

ChainCatcher 的报道同样把持续攻击、补足金库和暂停活动归因于 Loopscale。两家媒体都在描述协议的说法，其内容一致能够确认它们报道了什么，不能扩大成逐一核查所有余额的独立审计。

因此，阅读“用户资金未损失”与“协议暂停”时，两部分都要保留。存款人需要自己的仓位和转账记录，借款人还需要单独确认还款操作能否完成。这些问题不能只靠一个标题解决。

每天超过 3 万次，统计的是请求

来源中的数字是过去一周每天超过 3 万次恶意接口请求。它不是受影响用户人数，不是成功盗取资金的次数，也不是已转移资产的交易数量。报道没有把这个请求计数对应成一个资金损失额。

不能把日请求量相乘后，写成每周盗取次数或攻击者收益。可读来源也没有说明这些请求由多少个独立攻击者或钱包发出。报道支持的事件是持续针对协议的攻击活动，以及升级后团队暂停协议。

媒体还称，团队公布了四个关联地址，并与联邦执法部门和安全专业人士合作。本轮可读报道没有列出可逐字核对的完整地址，因此这里不复制地址。合作消息本身也没有提供资金追回额或完成期限。

接下来，能补足信息的是说明受影响范围、补足资金情况与功能恢复状态的具体报告。技术原因回答攻击怎样发生，状态更新回答用户可以做什么。这两个问题都不能从请求数量里推导出来。

借款人需要盯住还款功能

Odaily 转述的计划，是尽快恢复还款，以降低意外清算风险。还款因此应作为一个独立事项跟踪。网页界面重开与交易功能恢复，不是同一条消息，也不能互相替代。

如果你有借款仓位，先保留仓位详情及已经尝试的还款记录。记录资产、页面显示的债务与操作状态，通过协议自身支持渠道询问该仓位目前可以进行哪些操作。提交问题时，应说明具体哪一步不可用。

不要由“尽快恢复还款”推断所有清算暂停、利息减免、宽限期或债务豁免。本轮打开的报道没有确认这些安排。来源中的计划范围，是尽快恢复还款以降低意外清算风险，不能自行加上额外保护条件。

后续尝试还款前，阅读针对该功能的最新说明，再与自己的仓位页面比较。如果界面能加载，但还款按钮不可用或提交失败，就保留对应结果。看到网页，并不能证明交易已经可以完成。

存款人分别查余额、访问和转账

持有受影响金库仓位的用户，可以先核对金库名称和存款记录。报道点名 SOL 与 USDC Genesis 金库，不应因为另一个产品也包含相同币种，就认定它的状态完全一致。先把实际持仓与公告对象对应起来。

再看自己准备执行的操作。如果已经提交提现，保存其状态与页面提供的转账详情；如果还没有提交，就把“无法发起申请”与“已提交但接收方未入账”区分开。两种状态需要查找的记录不同。

若原本计划从交易所把 SOL 或 USDC 转入该协议，应在发起转账前确认接收端状态。本轮报道没有核实任何交易所当前对这些资产的充值或提现设置。协议暂停消息不能直接改写成交易所也暂停。

对另有交易持仓的用户，资金费率页面可以提供市场背景，但它不显示私人金库存款状态，也不能确认某个协议操作是否可用。协议访问问题仍需对应到该协议的仓位与交易记录。

恢复有条件，没有精确时刻

报道中的正常运营恢复条件，是全面查明攻击范围并进一步加强安全。两篇来源都没有给出精确的重开时间。界面“很快”重开、还款“尽快”恢复，不能改写成某个已确定的截止时刻。

后续更新应按它实际改变的内容来读。界面重开可能回答能否查看仓位，还款恢复回答借款人能否偿还，正常运营恢复则是更广的状态说明。这里是在解释如何区分这些计划，不是在声称某种部分恢复已经发生。

本轮来源描述的仍是暂停与恢复计划，没有建立更晚的运营状态。若后续更新改变了你能做的操作，应保存它的发布时间与原文，再回到自己的页面核对，而不是只看转发消息中的一句概括。

如果一般状态更新与实际失败的交易不一致，向协议支持渠道说明具体操作和结果。保留仓位、尝试时间与状态，可以让查询围绕实际问题展开，避免把不同用户、不同功能的情况混在一起。

仍缺哪些事实

可读材料没有确定补足金库所用的金额，没有最终技术原因、完整损失核对，也没有逐项功能恢复的时间表。这些缺口限制了对补足声明的进一步解释，不能自行计算攻击者利润或金库损失比例。

本轮也没有把 SOL 价格变化、交易所清算额归因于这次事件。打开的报道没有建立这种市场反应。若另有 SOL 持仓，应以所在平台真实报价和观察时间检查，不把同时发生的价格波动自动解释成事件结果。

当前能够保留的结论是：Loopscale 据报道补足受影响金库、称用户存款无损，同时暂停协议活动。存款状态、可访问状态、还款能力需要各自的证据，后续更新应明确对应它解决了哪个问题。

现在可以按哪些记录核对

1. 打开实际持有的 SOL 或 USDC Genesis 仓位，保留名称与状态，确认它是否正是报道提到的金库。不要只靠币种名称判断。
2. 有借款时，单独查看还款功能，保留尝试失败的结果，向协议支持渠道说明具体仓位和无法完成的操作。
3. 计划从交易所转入时，先确认接收端功能；已有申请未完成，就先查原记录，不用另一笔转账测试它。

本轮还打开了 PANews 英文报道，其正文明确把每日超过三万次恶意请求、金库补足和恢复还款计划归因于 Loopscale。它支持保留这些归因后的事实，没有提供独立的请求测量或逐户余额核查。后续若出现新的资金明细，应按它实际统计的对象对照，不能把请求数与资金金额混用。

常见问题速答

报道是否说用户存款损失了？

报道转述 Loopscale 称金库已补足，用户存款没有损失。这里保留协议声明的归因，不把它扩展成对所有账户的独立资金审计。

超过 3 万次是损失统计吗？

不是。这个数字指过去一周每天的恶意接口请求量。报道没有把它换算为资金损失或受影响人数。

还款现在已经恢复了吗？

本轮来源只记录尽快恢复的计划，没有确认恢复完成。应检查后续针对还款功能的更新及自己仓位的实际可用操作。

什么时候全面恢复？

来源未给出精确时间。已报道的条件是查明完整攻击范围、进一步加强安全；需要等待明确指出恢复功能与生效状态的更新。