NEAR Intents Restarts After $3.8M Exploit, 11 Chains Restricted

NEAR Intents Loss Estimate Remains About $3.8 Million

The project’s initial incident disclosure described the loss as preliminary and said the contract-side vulnerability had been patched. Its estimate concerns assets lost through the exploit, rather than the total value of deposits delayed by the shutdown.

In a separate original Telegram alert, blockchain investigator ZachXBT reported more than $3.8 million in irregular outflows from a BSC hot wallet associated with the service. He said the funds moved to KuCoin and were bridged into Bitcoin.

That tracing account supports an observed theft rather than a vulnerability report without known exploitation. It remains an attributed investigation: Daily Crypto Briefs did not independently reproduce the complete transaction graph, and exchange-bound transfers do not establish that an exchange has frozen or returned the assets.

The wallet identification also needs precision. Official treasury documentation lists 0x233c5370CCfb3cD7409d9A3fb98ab94dE94Cb4Cd, matching the alert’s abbreviated source wallet, as the HOT Bridge treasury for EVM networks. It lists a different EVM treasury for NEAR Intents.

Polosukhin said NEAR Intents now processes more than $4 billion a month in trading and payments volume. That activity figure measures value moving through the service, not assets held in the affected wallet. Comparing the loss directly with monthly volume would therefore say little about the proportion of customer balances exposed or the resources available for reimbursement.

That distinction narrows the operational context without settling the exploit mechanism. A wallet label does not prove whether an attacker compromised a key, exploited withdrawal logic or abused the interaction between components. The team’s disclosure identifies the infrastructure interaction; a detailed post-mortem is still needed to reconstruct it.

As of October 1 at 22:08 UTC, the reviewed materials did not establish a final reconciled loss, verified affected-user count, completed repayment total or separate attack wave. The approximate $3.8 million estimate should therefore remain attributed, without treating every stranded transfer as another confirmed theft.

Eleven Networks Still Show Transfer Incidents

The initial statement projected a core-service restart within an hour and approximately 12 additional hours of deposit and withdrawal restrictions on affected networks. Polosukhin’s later announcement confirms a restart in broader terms, rather than confirming that every route met the original timetable.

At this article’s check, the SHIELD status page continued to list incidents for BNB Smart Chain, Polygon, TON, Optimism, Avalanche, Stellar, Monad, X Layer, ADI, Scroll and Plasma. It also displayed a HOT Bridge incident.

Several networks appeared in more than one status entry. Those entries should not be added together as a count of separate hacks, affected wallets or stolen balances. They describe operational surfaces and overlapping service interruptions.

The project said users already holding assets from affected chains inside NEAR Intents could swap into other assets after core operations resumed. That separates an internal balance exchange from moving funds across the underlying deposit or withdrawal connection.

The distinction follows the product’s architecture. Its token-bridge documentation describes multiple routes between external blockchains and the settlement contract, each with its own trust model. HOT Bridge’s documented supported networks closely match the restricted list.

Its intents explainer says users specify a desired trade and market makers compete to fulfill it. Restoring that trading function can leave individual transfer routes unavailable. A working swap interface alone does not demonstrate successful withdrawal to an external wallet.

Earlier Taiko bridge-exploit coverage illustrates a different operational response involving a network halt. In this case, the disclosed interruption concerns cross-chain service infrastructure, while Polosukhin says the underlying NEAR network was unaffected.

Full Compensation Still Needs a Payment Record

The project’s compensation pledge is explicit: “These funds will be compensated in full.” The reviewed disclosures did not supply a claims process, eligibility calculation, funding source or payment deadline.

Repayment and recovery are separate outcomes. Compensation would restore affected users’ balances; tracing and recovering stolen assets would reduce the amount the operator needs to cover. Announcing either objective does not establish that a payment has reached a victim.

A complete accounting would also separate unauthorized transfers from balances temporarily inaccessible because a route was paused. Both can affect customers, but they call for different remedies: reimbursement for a shortfall and restored transfer access for an intact balance. The published estimate and status entries do not provide that customer-level breakdown.

The team said it reported the incident to law enforcement and was working with security and blockchain analytics partners. Those steps document a response, while the promised public report should establish the loss accounting, scope of the flaw and remediation details.

Polosukhin also proposed incorporating formal verification into NEAR contract releases. That process checks code against defined mathematical properties. Its value depends on the properties and components tested, so the announcement does not by itself validate the repaired infrastructure.

The incident arrives shortly after Bitwise’s NEAR ETF completed registration and listing steps, bringing the token into a separate investment structure. A token-price decline, an infrastructure loss and an ETF’s holdings are different measures of exposure.

Alternative.me’s Bitcoin-focused Fear and Greed Index stood at 74, or Greed, on October 1. That broad sentiment reading is not a safety assessment of NEAR Intents or an estimate of compensation prospects.

The next concrete checks are network-specific reopening notices, a detailed exploit report and evidence of completed compensation. Until those arrive, the verified recovery milestone is resumed core service alongside continuing incident listings, rather than a fully reconciled and reimbursed event.