NEAR Intents disclosed an approximately $3.8M USDT exploit on BNB Chain on October 1, 2026, tracing the incident to a bug in the interaction between its Omni deposit and withdrawal infrastructure and the NEAR Intents smart contract.
The incident affected the cross-chain layer around NEAR Intents rather than the NEAR Protocol layer 1 itself. NEAR stated that the network continued producing blocks and processing transactions with zero downtime, while NEAR Intents stopped services and patched the contract-side vulnerability. The precise bug class and the exact failing component had not been published as of October 2, but the available facts point to a critical bridge-accounting and withdrawal-authorisation boundary.
Key takeaway: The NEAR Intents $3.8M exploit shows why bridge security must prove that every asset release corresponds to a real, unique, and previously unconsumed deposit or debit across every connected chain. A patched smart contract is necessary, but the full defence must cover relayers, bridge infrastructure, signer controls, and reconciliation logic.
What happened during the NEAR Intents exploit?
NEAR Intents lost approximately $3.8M in USDT on BNB Chain after attackers exploited a bug in the interaction between Omni deposit and withdrawal infrastructure and the NEAR Intents smart contract. The drain was visible before the public disclosure, while NEAR Intents halted services, patched the contract-side issue, and said affected users would be compensated in full.
On-chain activity indicates that small transfers of 10 USDT and 11 USDT left the drained contract during the afternoon of September 30, US Eastern time. Those small transfers are consistent with a validation phase in which an attacker tests whether a withdrawal, accounting, or release path behaves as expected before attempting larger extractions.
Five larger transfers then ran from 23:54 UTC on September 30 through 06:08 UTC on October 1. Those transfers ranged from roughly $35,000 to $1.5M each. Security analysis placed the loss at $3.865M from a BNB Smart Chain hot wallet, while separate on-chain tracing found about 3.87 million USDT collected from the drained contract.
NEAR Intents publicly disclosed the exploit at about 12:53 UTC on October 1. The protocol said its services had stopped after SHIELD detected unusual activity, and the contract fix landed within about an hour. Deposits and withdrawals across 11 networks were expected to remain unavailable for roughly another 12 hours while the infrastructure was repaired.
| Incident stage | Date or time | Concrete event | Security relevance |
|---|---|---|---|
| Initial probes | September 30, afternoon US Eastern time | 10 USDT and 11 USDT left the drained BNB Chain contract | Small transfers can reveal whether a release path is exploitable |
| Main drain begins | September 30, 23:54 UTC | First of five larger transfers began | The exploit crossed from probing into extraction |
| Main drain ends | October 1, 06:08 UTC | Fifth larger transfer completed | The visible extraction period spanned several hours |
| Public disclosure | October 1, about 12:53 UTC | NEAR Intents disclosed stopped services and an infrastructure-contract interaction bug | Incident communication followed the on-chain drain |
| Return deadline announced | October 2, 00:18 UTC | A 48-hour window was given to return funds | The stated deadline ran to about October 4, 00:18 UTC |
The affected asset reported publicly was USDT on BNB Chain. That scope matters because it distinguishes an application and bridge-infrastructure incident from a compromise of the NEAR base network or a general failure of all NEAR Intents assets.
NEAR Intents had processed over $30B across about 35 blockchains, with a dashboard showing $31.4B in all-time volume as of September 22. Systems with that routing scale do not only need secure smart contracts. They require consistent state assumptions across chains, bridge operators, settlement contracts, monitoring systems, and operational pause procedures.
How does NEAR Intents normally move assets across chains?
NEAR Intents settles user-directed cross-chain outcomes through its intents.near Verifier contract, which keeps a ledger of deposited token balances, updates those records when swaps occur, and releases tokens only through withdrawal and bridge paths. The exploit concerned the boundary where deposit and withdrawal infrastructure interacted with that settlement layer.
A user of NEAR Intents signs an intended outcome rather than directly specifying every execution step. Solvers and market makers compete to fulfil that outcome, and the selected result settles on-chain. This model can improve cross-chain execution, but it also creates a broad trust and verification surface: the settlement ledger must correctly recognise what was deposited, what was exchanged, and what can be withdrawn.
NEAR Intents documentation identifies three bridge systems with different trust models:
- Omni Bridge, operated by Near One.
- POA Bridge.
- HOT Bridge.
The HOT Bridge design is especially relevant to the incident analysis because public analysis identified the drained BNB Chain contract as the HOT Bridge treasury address listed in NEAR Intents documentation, rather than the primary NEAR Intents vault. That linkage is analysis rather than a final official root-cause determination, and NEAR Intents had not confirmed which component failed as of October 2.
In HOT Bridge, locker contracts on each supported chain hold native assets. A contract on NEAR mints matching omni-tokens at a one-to-one relationship. Validator MPC signatures authorise deposits and withdrawals, and the design specifies that each nonce must be single-use.
That architecture has several non-negotiable security properties:
- A release on BNB Chain must correspond to a real lock, debit, or settled entitlement.
- A deposit message must not be replayable after execution.
- A signer approval must be bound to the exact chain, asset, recipient, amount, and nonce.
- A withdrawal request must not be accepted merely because an external component claims it is valid.
- The treasury balance must be reconciled continuously against the ledger and authorised bridge state.
In our experience auditing smart contracts at Soken, the most dangerous bridge failures occur at system boundaries. A contract can enforce its local rules correctly while still releasing assets because an upstream message, off-chain service, or cross-chain accounting assumption was accepted without enough independent verification.
The 11 paused networks matched the HOT Bridge chain list in NEAR Intents documentation: BNB Chain, Polygon, TON, Optimism, Avalanche, Stellar, Monad, X Layer, ADI, Scroll, and Plasma. Ethereum, Base, Arbitrum, Solana, and Bitcoin were not paused. The matching chain lists support a HOT Bridge-focused hypothesis, but they do not prove the exact vulnerable component.
What is known about the bug, and what remains unknown?
NEAR Intents has confirmed that a bug existed in the interaction between Omni deposit and withdrawal infrastructure and the NEAR Intents smart contract, but NEAR Intents had not disclosed the precise component or vulnerability class by October 2. Any claim that the issue was definitively a signature bypass, replay flaw, accounting error, or validator compromise would go beyond the available evidence.
The phrase “interaction” is central. It suggests that the vulnerability was not necessarily a simple isolated coding defect in one contract function. Cross-chain systems often fail when two individually reasonable components disagree about the meaning, finality, or uniqueness of a state transition.
For example, a bridge release path can fail if an off-chain component produces an approval for an event that was never final, if a contract accepts a withdrawal message without consuming it permanently, or if the accounting layer credits a balance that the underlying locker has not actually received. These are distinct technical mechanisms, but they share the same security failure: assets are released without an equivalent locked asset or valid debit.
The NEAR Intents event resembles the general shape of several major bridge incidents, while remaining distinct in its confirmed details.
| Incident | Date | Reported loss | Confirmed failure shape |
|---|---|---|---|
| Wormhole | February 2022 | About $325M | A signature-verification bug allowed guardian approval to be forged and 120,000 wETH to be minted without collateral |
| Nomad | August 2022 | About $190M | An upgrade set the trusted root to zero, causing every message to be treated as proven |
| Kelp DAO over LayerZero | April 2026 | About $292M to $293M | A 1-of-1 verifier configuration allowed a phantom burn to release funds on Ethereum |
| Liquid Network | September 6, 2026 | About $320M | A range-proof verification cache bug enabled unbacked L-BTC to be pegged out to real BTC |
| NEAR Intents | October 1, 2026 | Approximately $3.8M | A confirmed bug in Omni deposit and withdrawal infrastructure interaction with the NEAR Intents smart contract |
Wormhole, Nomad, Kelp DAO, and Liquid Network share a common release-side failure pattern: a bridge accepted a credit, proof, or message that did not map to a real lock or debit. NEAR Intents has not yet confirmed that the October 1 exploit followed that exact mechanism, but its bridge-treasury context makes this invariant the first one a post-mortem should address.
Ronin Bridge is a useful contrast. The March 2022 Ronin incident involved compromise of 5 of 9 validator keys. That is primarily a key-management and validator-threshold failure, rather than a case in which a contract incorrectly recognised an unbacked credit as legitimate.
NEAR Intents has committed to add formal verification to its release process. Formal methods are valuable here when used to encode bridge invariants directly: a valid withdrawal cannot exceed a user’s settled entitlement, a withdrawal message cannot execute twice, and aggregate releases cannot exceed verified backing across the bridge system.
For protocols designing similar infrastructure, technical security reviews should test the whole deposit-to-release lifecycle rather than treating each contract, service, or signer domain as a separate security boundary.
Why were the response and containment decisions material?
NEAR Intents contained the incident by stopping services after SHIELD detected unusual activity, patching the contract-side vulnerability within about an hour, and pausing deposits and withdrawals on 11 affected networks. Fast containment limits further extraction, but complete recovery depends on tracing, legal escalation, and proving that restarted bridge flows satisfy the corrected security invariant.
The immediate service stop was an appropriate response to uncertainty. When a cross-chain withdrawal path may be producing unbacked releases, continuing normal operation can turn a limited exploit into a broader treasury depletion event. The trade-off is severe disruption for legitimate users, which is why bridge pause controls should be granular, rehearsed, and observable.
NEAR Intents said it reported the incident to law enforcement and was working with security and blockchain analytics partners to trace the funds and pursue recovery. Public reporting indicated that stolen funds were sent to KuCoin and bridged to Bitcoin. Separate tracing found about 1.5M USDT moving through the CoW Protocol settlement contract.
A NEAR Intents representative gave the exploiter a 48-hour window to return funds, published return addresses on Bitcoin, BNB Chain, and Solana, and offered no stated bounty. As of October 2, no return of funds or repayment schedule had been reported.
The compensation commitment also matters. NEAR co-founder Illia Polosukhin stated that all affected users would be compensated in full. That commitment addresses customer impact, but it does not replace the technical requirement to publish a precise post-mortem and remediation record before restoring affected routes.
A useful post-incident package should include:
- The exact vulnerable component and bug class.
- The contract and infrastructure changes that remove the exploit path.
- Whether any message, nonce, ledger, signer, or reconciliation invariant failed.
- Independent review results for the repair.
- A chain-by-chain restoration plan for BNB Chain, Polygon, TON, Optimism, Avalanche, Stellar, Monad, X Layer, ADI, Scroll, and Plasma.
- Monitoring rules that would detect the same abnormal withdrawal shape earlier.
The incident also raises governance and operational questions beyond code. Return-address publication, fund tracing, exchange coordination, user compensation, and law-enforcement engagement each involve legal and disclosure decisions. Teams preparing bridge recovery procedures should align technical controls with legal and compliance support, especially where custody, user claims, sanctions screening, or cross-border recovery become relevant.
What should cross-chain teams change after the NEAR Intents incident?
Cross-chain teams should treat every bridge withdrawal as a conservation-of-value proof: the release must be bound to a verified lock or debit, a unique message, a specific destination, and a capped amount. The NEAR Intents incident demonstrates that monitoring and emergency stops are essential, but prevention depends on making invalid cross-component states impossible to authorise.
The first engineering task is to define the bridge’s core invariant in business and technical terms. For a HOT Bridge-style system, the invariant is not simply “the MPC signature is valid.” It is closer to: “this exact withdrawal is authorised once, for this asset and recipient, after a corresponding finalised and unspent deposit or ledger debit.”
That invariant must be tested across failure modes:
- duplicate messages and nonce reuse;
- mismatched chain identifiers;
- mismatched token addresses or decimal conversions;
- stale signer approvals;
- partial infrastructure outages;
- inconsistent ledger and locker balances;
- emergency pause transitions;
- replay attempts after upgrades or contract migrations.
Second, protocols should separate detection from trust. SHIELD detected unusual activity during the NEAR Intents event, which helped trigger containment. Yet monitoring should not be the only barrier between an accounting error and treasury loss. A monitoring system identifies suspicious behaviour after it begins. Contract and bridge verification rules should reject invalid value movement before a transfer is executable.
Third, teams should build reconciliations that compare source-chain locks, settlement-ledger credits, destination-chain releases, and outstanding withdrawal authorisations. A discrepancy should automatically narrow limits or halt the affected route. This control is especially important for hot-wallet and treasury paths, where a valid-looking transaction can otherwise move liquid assets quickly.
Fourth, formal verification should target properties that matter to the bridge business model, not only arithmetic safety. The NEAR Intents commitment to incorporate formal verification is directionally sound if it covers state transitions across deposit, solver settlement, bridge message creation, and withdrawal execution. A formal proof of one contract function is not enough if an external infrastructure component can feed that function an incorrect but accepted premise.
Soken’s research hub examines recurring smart-contract and protocol-security failure modes, including the difference between a local contract check and a system-wide security guarantee. For bridge teams, the practical lesson is consistent: audit scope must include contracts, message formats, signer policy, operational controls, monitoring telemetry, and recovery procedures.
NEAR Intents now needs to turn its promised post-mortem into a verifiable restoration plan: identify the failing interaction, demonstrate why the fixed path cannot release unbacked USDT, and independently test every resumed HOT Bridge route. Teams operating comparable cross-chain infrastructure should begin by mapping every withdrawal authorisation to its underlying lock or debit, then test whether that linkage survives retries, delays, upgrades, and adversarial message ordering.