Loopscale pauses vaults after 30,000 malicious requests a day

A recapitalized vault can still be paused

The reports describe an escalation detected by the protocol's security systems, followed by a suspension of activity to reduce the impact. They name the SOL and USDC Genesis Vaults as the main targets and say the affected vaults were replenished. They do not provide the amount replenished or a breakdown of the financial impact by vault.

That leaves two different questions for a user. The first concerns the team's statement about deposits: the reports say no user deposits were lost. The second concerns access: the protocol had paused activity and attached conditions to a return to normal operations. A positive statement about deposits does not itself confirm that a withdrawal can be completed at the moment a reader opens the page.

ChainCatcher's report also attributes the sustained attacks, recapitalization and pause to Loopscale. Both outlets describe the protocol's statements. Their agreement supports what was reported, but it is not a separate audit of each vault or an independent measurement of all users' balances.

The distinction matters when a headline combines “no user funds lost” with “protocol paused.” Neither part should erase the other. Depositors need an account-specific record and the current operating status. Borrowers also need to know whether they can perform the repayment action discussed by the team.

What the 30,000-request figure describes

The reported number is more than 30,000 malicious requests to the API per day during the preceding week. It is not a count of affected depositors, successful thefts or transactions that moved assets. The sources opened for this report do not attach a loss amount to that request count.

Keep the measurement with its subject. Multiplying a daily request figure into an estimated weekly theft figure would have no basis here. Nor does the report establish how many distinct attackers or wallets generated those requests. The meaningful event is that the team described a continuing campaign and paused activity after an escalation.

The outlets say the team disclosed four associated addresses and was working with federal law enforcement and security professionals. This article does not reproduce addresses because the readable reports opened here did not provide the full address strings needed to check them. A report of cooperation also supplies no recovery amount or deadline by itself.

For a user, the missing detail to watch is an incident report explaining the affected scope, what was replenished and which functions have resumed. Each would answer a different question. A technical explanation could clarify the cause; a service-status update could clarify access; neither should be inferred from the request count alone.

Repayment is the operational question for borrowers

According to Odaily, Loopscale planned to restore repayment as soon as possible to reduce unintended liquidation risk. That wording makes repayment a separate item to monitor. Reopening a website interface and restoring a transaction function are not the same announcement.

If you have a borrowing position, preserve the position details and any repayment attempt shown by the interface. Record the asset, displayed obligation and status of the action you attempted. Use those records when asking the protocol's support channel what remains available for your particular position.

Do not infer a blanket liquidation freeze, an interest waiver, a grace period or debt forgiveness from a plan to restore repayment. None of those measures was established by the opened reports. The narrow reported commitment is to bring repayment back as soon as possible to reduce unintended liquidation risk.

Before attempting a later repayment, read the latest function-specific instructions and compare them with the screen for your position. If the interface loads but the repayment action is unavailable or fails, keep the result attached to that attempted action. A visible page alone does not answer whether the transaction can complete.

Depositors should separate balance, access and transfer status

For someone with assets in an affected vault, start with the vault name and the deposit record. The reports identify SOL and USDC Genesis Vaults; do not assume every product with a similar asset label has the same status. Match the actual position you hold with the product named in the update.

Then inspect what the current interface says about the operation you want to perform. If a withdrawal is pending, retain its displayed status and any transaction details supplied. If the action has not been submitted, distinguish that from a submitted transaction whose destination has not yet credited it.

If you were planning to move SOL or USDC from an exchange into the protocol, read the receiving status before initiating the transfer. The opened reports do not verify any exchange's current deposit or withdrawal setting for that asset. Check the actual source and destination rather than interpreting protocol news as an exchange-wide suspension.

The funding-rates board can provide market context for a separate trading position. It does not show the condition of a private vault deposit or settle whether a paused protocol action is available. Keep the protocol access check tied to the protocol's own position and transaction records.

Conditions for reopening, without an announced deadline

The reported condition for returning to normal operations is that the team fully identifies the scope of the attacks and strengthens security further. Neither opened report provides an exact reopening time. “Soon” for the interface and “as soon as possible” for repayment are not scheduled deadlines.

Read a later update for what it specifically changes. An interface reopening could allow users to see positions while leaving another function restricted. A repayment restoration would answer the borrower-action question. A return to normal operations would be a broader statement and should be checked against the conditions described by the team.

These distinctions are an editorial way to read the reported plans, not a claim that a particular partial reopening has occurred. At the time of the sources reviewed here, the reports described the pause and planned restoration. No later operating-state confirmation was established in this review.

Save the time and wording of an update if it changes the action available to you. Then compare it with your account record before relying on it. If there is a conflict between a general update and a failed transaction, report the particular action and result through the protocol's own support channel.

What the reports leave unanswered

The amount used to replenish the affected vaults was not established in the readable materials. The reports also do not give a final technical cause, a complete loss reconciliation or an exact timetable for each function. Those omissions limit how far a reader can interpret the recapitalization statement.

It would be premature to calculate an attacker profit, a vault loss percentage or a repayment deadline from these reports. The user-facing conclusion is narrower: Loopscale reported that deposits remained safe after replenishment while protocol activity was paused. Access and repayment need their own current checks.

No market-price reaction or exchange liquidation total is attached to this event here. The reports opened for this article do not establish one. A trader following SOL elsewhere should use that position's actual venue data and observation time rather than assign a price move to the incident without evidence.

What to check now

1. Open the record for the exact SOL or USDC Genesis position and save its displayed status. Match the product name with the affected vaults described in the reports.
2. If you owe a repayment, check that function separately from interface access. Keep any failed attempt and ask the protocol's support about the specific position.
3. Before sending assets from an exchange, check the receiving function. Do not submit another transfer to test whether an earlier request has completed.

PANews' English report independently carries the wording “more than 30,000 malicious requests per day” as Loopscale's account. It does not publish a separate measurement of the requests or vault balances.

Quick answers

Did the reports say users lost deposits?

They report Loopscale's statement that affected vaults were replenished and no user deposits were lost. This is an attributed protocol statement, not a separate audit of every balance.

Is the 30,000 figure a loss total?

No. It describes more than 30,000 malicious API requests per day over the past week. The reports do not convert that count into an asset loss or a number of affected users.

Has repayment resumed?

The opened sources describe a plan to restore it as soon as possible. They do not confirm a completed restoration. Check a later repayment-specific update and the position's available action.

When will normal operations resume?

No exact time is supplied. The reported conditions are identifying the full attack scope and strengthening security. The next useful update is one naming the restored function and its effective status.