On October 1, 2026, NEAR Intents disclosed a security incident involving approximately $3.8 million in assets. The exploit affected the interaction between its Omni deposit and withdrawal infrastructure and the NEAR Intents smart contracts, allowing an attacker to withdraw funds from a vault on BNB Chain.
On-chain records show that the activity began on September 30. The attacker first executed two small test withdrawals before making five larger withdrawals over approximately six hours, extracting a total of 3,865,000 USDT. Each transaction carried a withdrawal proof in the expected format and was accepted by the vault contract.
Following the incident, NEAR Intents suspended certain cross-chain services and patched the affected contracts. On October 2, project lead Alex Shevchenko announced that the stolen funds had been fully returned.
Although the funds were recovered, the incident raises important questions about how cross-chain systems manage withdrawal authorization, asset balances, and settlement across different networks.
This analysis examines the publicly documented Omni Bridge architecture, the observed transaction sequence, and the security checks that matter when multiple contracts and validators are responsible for a single cross-chain withdrawal.
1. How Omni Bridge Handles Cross-Chain Withdrawals
NEAR Intents uses an intent-based execution model that allows users to exchange assets across networks by submitting signed transaction intents.
The related Omni infrastructure manages assets through contracts deployed on supported blockchains and an accounting system operating on NEAR.
According to the public HOT Omni Bridge documentation, the architecture consists of three main components.
Locker Contracts hold assets deposited on supported networks and release them when valid withdrawal requests are submitted. On EVM-compatible chains, these contracts manage ERC-20 transfers, verify withdrawal signatures, and execute asset releases.
HOT Omni Balance maintains cross-chain asset balances on NEAR. It handles token minting, burning, and transfers, and serves as a source of accounting state for deposits and withdrawals.
HOT MPC Validators verify cross-chain events and withdrawal records before producing signed proofs. Destination-chain contracts use these proofs to determine whether a withdrawal has been authorized.
During a normal deposit, a user transfers assets to a Locker contract on the source chain. The contract records the deposit and assigns a nonce. Once validators confirm the deposit, the corresponding balance can be credited or minted on NEAR.
Withdrawals follow the reverse process.
A user submits a withdrawal request on NEAR. Omni Balance processes the corresponding balance deduction or token burn, records the withdrawal, and assigns a nonce. After validators verify the record, they generate a signed withdrawal proof.
The user or an execution service then submits the withdrawal parameters and signature to the destination-chain Locker, which verifies the proof and nonce before releasing the assets.
The documented flow can be summarized as:
Withdrawal Intent → Balance Debit/Burn → Withdrawal Record → MPC Signature → Locker Verification → Asset Release
One important aspect of this architecture is the separation between asset accounting and final settlement.
The destination-chain Locker relies on the withdrawal proof it receives, while the user's complete asset entitlement is maintained by upstream components.
The security of this process therefore depends on the upstream system generating withdrawal records that accurately reflect authorized changes in user balances.
2. Attack Timeline: Seven Withdrawals From the BNB Chain Vault
According to the public on-chain investigation, the attacker-controlled addresses began preparing for the exploit on September 28, including a 10 USDT deposit into the targeted vault.
On September 30, the attacker executed two small test withdrawals of 10 USDT and 11 USDT. Both were successful.
The attacker then proceeded with five larger withdrawals.
| Time (UTC) | Amount | Transaction |
|---|---|---|
| Sep 30, 18:57 | 10 USDT | Test withdrawal |
| Sep 30, 20:05 | 11 USDT | Test withdrawal |
| Sep 30, 23:54 | 800,000 USDT | 0x9fe58e…6c4c |
| Oct 1, 00:24 | 1,200,000 USDT | 0x038126…8220 |
| Oct 1, 00:50 | 1,500,000 USDT | 0x69d1c6…cceb |
| Oct 1, 01:46 | 330,000 USDT | 0x9c10b9…003a |
| Oct 1, 06:08 | 35,000 USDT | 0x16ddfa…0c02 |
The five larger transactions totaled 3,865,000 USDT, with another 21 USDT withdrawn during the initial tests. The approximately $3.8 million figure reported by the project was an initial estimate.
The investigation also found that only 10 USDT in previous BNB Chain deposits could be traced to the attacker-related addresses.
However, this does not establish the full balance held by those addresses within the cross-chain system. Assets may have originated from other supported networks, earlier transfers, or cross-chain swaps.
The more relevant finding is that all seven withdrawals used proofs with the expected structure, and the destination-chain vault accepted the requests.
The BNB Chain transactions establish that the funds were released. They do not, by themselves, explain why the upstream system generated or accepted the corresponding withdrawal authorizations.
3. Signed Withdrawals: What Does the Vault Actually Verify?
In Omni's documented architecture, a destination-chain Locker verifies a signed withdrawal proof before releasing funds.
The public HOT Protocol EVM repository includes a relevant MetaWallet implementation with withdrawal execution, signature verification, and nonce management.
According to the published implementation, the contract uses ECDSA signature verification and a configured verifyAddress to determine whether the submitted proof comes from an authorized signer.
The withdrawal data includes information such as the asset, recipient, amount, and nonce. The contract also checks whether a nonce has already been used.
Each of these checks serves a different purpose.
Signature verification establishes whether the authorization satisfies the contract's cryptographic requirements.
Nonce validation prevents the same withdrawal authorization from being executed more than once within its defined scope.
Parameter binding ensures that a valid proof cannot be reused for a different recipient, asset, amount, or execution environment.
However, a successfully verified signature does not necessarily establish that the underlying withdrawal is economically valid.
Consider a case where an upstream component incorrectly approves a withdrawal that is not supported by the user's available balance.
If that withdrawal is recorded and signed through an otherwise authorized process, the destination-chain contract may still accept the proof and release the requested assets.
From the Locker's perspective, the signature satisfies its authorization rules. Whether the corresponding assets were correctly deducted from the user's balance depends on the upstream verification process.
This creates a trust boundary between withdrawal authorization and asset accounting.
It is an important area for cross-chain security reviews because the destination-chain contract generally cannot reconstruct every relevant balance change from another network.
This is an architectural risk scenario, not a confirmed description of how the NEAR Intents exploit was executed. The available evidence does not establish that the MPC validators incorrectly signed a withdrawal, that a signature was forged, or that the nonce mechanism failed.
4. Root Cause: What Has Been Confirmed?
NEAR Intents confirmed that the vulnerability involved the interaction between Omni's deposit and withdrawal infrastructure and the NEAR Intents smart contracts.
Based on the public architecture, three areas are particularly relevant to the technical investigation.
Withdrawal Authorization and Balance Accounting
A valid withdrawal should correspond to an authorized deduction or burn of the user's assets.
Before generating a withdrawal proof, the system needs to establish that the user has sufficient available funds and that the corresponding accounting operation has been completed according to protocol rules.
Where multiple contracts maintain balances or withdrawal records, the system must also ensure that account identifiers, asset types, amounts, and state versions remain consistent.
Any discrepancy between the record used to authorize a withdrawal and the balance state supporting it can create an opportunity for incorrect settlement.
Withdrawal Proof Generation and Verification
The HOT Omni Bridge documentation describes a process in which validators inspect withdrawal records, generate signatures, and submit those proofs for verification on the destination chain.
A security review needs to examine which contract state validators read, which parameters are covered by each signature, and whether a previously signed request can be modified, revoked, or executed more than once.
Fields such as chainId, token, amount, recipient, and nonce should be bound to the correct authorization context.
The precise set of signed fields must be verified against the deployed implementation. The presence of a field in an application-level withdrawal request does not automatically mean it is included in the signed message.
Settlement Consistency
A correctly formatted withdrawal proof must correspond to an authorized asset movement within the cross-chain system.
The protocol needs to prevent duplicate settlement and ensure that the same underlying asset entitlement cannot be used repeatedly.
This becomes particularly important when cross-chain messages are delayed, transactions are retried, state updates arrive out of order, or only part of a multi-step withdrawal succeeds.
These conditions need to be addressed at the protocol level because different components may observe and process state changes at different times.
As of this analysis, a complete technical post-mortem identifying the vulnerable function and full exploitation conditions has not been independently verified.
The confirmed root-cause scope therefore remains the interaction issue between the Omni infrastructure and the NEAR Intents contracts.
The available evidence does not justify attributing the incident specifically to signature forgery, MPC key compromise, nonce replay, or a particular balance-update bug.
5. Tracing the Stolen Funds Across Networks
After withdrawing USDT from the BNB Chain vault, the attacker converted the assets into BNB and distributed them across newly created wallets.
According to the public investigation snapshot taken on October 1 at 14:30 UTC, a substantial portion of the funds had moved toward Bitcoin and centralized exchanges.
Approximately 34.69 BTC was identified across four Bitcoin wallets, representing around 76% of the stolen value at the exchange rates used in the investigation. Approximately $802,000 was also traced to KuCoin-related deposit addresses.
Another notable detail is that the attacker reportedly processed approximately $822,000 through NEAR Intents' own cross-chain swapping service during the incident.
Some of those operations involved transferring around 750 BNB to the same BNB Chain vault associated with the exploit, then receiving ETH or BTC through the normal cross-chain exchange process.
These swaps were part of the subsequent movement of funds. Their execution alone does not establish that the original vulnerability was exploited again.
Cross-chain fund tracing requires correlating source-chain transfers, swap orders, destination-chain receipts, and transaction timestamps.
Where complete swap records are unavailable, matching amounts and timestamps can support an investigation, but they cannot independently prove every step in a transfer path.
The reported destinations also reflect funds observed at different stages of movement. They should not be treated as mutually exclusive balances or added together as separate losses.
Most importantly, the October 1 snapshot describes the movement of funds before recovery. It does not represent their final ownership or location.
6. Incident Response and Recovery
On October 1, NEAR Intents acknowledged the security incident and stated that the relevant contract issue had been patched.
Certain deposit and withdrawal services remained suspended while the team continued its response to the affected Omni infrastructure.
On October 2, NEAR Intents project lead Alex Shevchenko announced that the approximately $3.8 million in stolen funds had been fully returned and that the related investigation would be closed.
Subsequent public reporting identified a return transaction of approximately 34.6 BTC to a Bitcoin address designated by the project.
The complete return paths for the remaining assets have not been independently reconstructed from the publicly available information. Accordingly, the full recovery is presented here as the project's confirmed statement, with the directly observable Bitcoin transaction treated separately.
The incident affected infrastructure supporting NEAR Intents' cross-chain deposit and withdrawal operations.
There is no public evidence in the reviewed material that NEAR's underlying consensus network was compromised or that the NEAR native token suffered a corresponding protocol-level vulnerability.
7. ScaleBit Security Insight: What Should a Cross-Chain Security Audit Cover?
The NEAR Intents incident involved several components that participate in the same asset transfer: vault contracts on different networks, a shared accounting system on NEAR, withdrawal proof generation, and final settlement.
A Cross-Chain Security Audit should examine these components as a complete execution flow.
Deposit → Balance Accounting → Withdrawal Authorization → Settlement
Several security invariants are particularly important.
Withdrawal Authorization Consistency
Every authorized withdrawal should correspond to a valid asset debit or burn.
The recipient, token, amount, and destination network in the withdrawal proof must match the transaction being settled.
Testing should cover concurrent requests, multiple accounts, different assets, and changes in authorization state while withdrawals are pending.
Where different components maintain separate records, the audit also needs to establish how those records are reconciled.
Nonce Uniqueness and Replay Protection
Each withdrawal nonce should be unique within its intended authorization domain and unusable after successful settlement.
The review should also verify that signatures are bound to the correct chain, contract, asset, and recipient.
This matters when a protocol deploys similar contracts across multiple networks or supports several withdrawal paths using shared signing infrastructure.
A valid proof must not become executable in an unintended context.
Cross-Chain Asset Conservation
The assets released through cross-chain settlement must remain consistent with valid changes in user balances and the system's available reserves.
Testing should cover individual withdrawals as well as aggregate asset accounting across networks.
Message delays, failed transactions, retries, and different execution orders must not allow the same asset entitlement to support multiple successful withdrawals.
Asset Conservation testing is particularly important when deposits and withdrawals are processed asynchronously.
Failure-State Testing and PoC Verification
Cross-chain systems need to be tested beyond their normal execution paths.
Relevant cases include a withdrawal request that has been recorded but not yet signed, a signed proof awaiting execution on the destination chain, a failed settlement transaction that is subsequently retried, or a change in upstream state after a proof has already been issued.
These scenarios can be examined using state-transition testing, Fuzz Testing, and PoC Verification.
The goal is to verify that different components preserve their security invariants even when messages, transactions, and state updates occur in unexpected sequences.
For more complex protocols, testing should also account for validator configuration changes, contract upgrades, and the interaction between old and new withdrawal states.
8. Conclusion
The funds involved in the NEAR Intents incident have been reported as fully recovered, but the disclosed vulnerability involved a critical part of cross-chain infrastructure.
In systems that rely on external validators and cross-chain messages, signature verification, balance accounting, and settlement need to remain consistent throughout the withdrawal process.
When these responsibilities are distributed across multiple contracts or networks, security testing must examine how they interact under both normal and abnormal execution conditions.
ScaleBit, a sub-brand of BitsLab, focuses on vulnerabilities in DeFi protocols, cross-chain infrastructure, and complex smart contract interactions.
Our Smart Contract Security Audit work covers authorization logic, cross-contract execution paths, asset accounting, state consistency, and PoC-based vulnerability verification [BitsLab AI].
For teams building or upgrading cross-chain and DeFi protocols, learn more about our security research and audit services at ScaleBit and BitsLab.