NEAR Intents lost about $3.8M to a deposit notification bug, says its postmortem

What happened

NEAR Intents is a cross-chain swap system built on NEAR Protocol, and everything settles in one contract, intents.near. Between 29 September and 1 October 2026, someone pulled about $3.8 million out of it. The team paused the contract on 1 October.

On 16 October, general manager Alex Shevchenko published a postmortem. It puts the blame on the contract's deposit notification feature, which let the attacker create balances that no tokens backed. The team calls them "ghost funds".

The postmortem also says every affected user was made whole and the money came back. ThreatWire has not verified that.

What is confirmed

Everything below is as reported from the postmortem and its coverage. Times are UTC.

Timeline

• 29 September, 16:14. First withdrawal of ghost funds.
• 1 October, 05:54. Last withdrawal.
• 1 October, 08:04. The team identifies the withdrawal problem.
• 1 October, 08:33. The contract is paused, 29 minutes later.
• 1 October. The contract reopens with affected routes still paused. Routes reopen over the following days.
• 2 October. A fix is deployed. Contract-side deposits resume.
• 7 October. A second critical report on the same feature arrives. The team removes the feature that day.
• 16 October. The postmortem is published.

Amounts and method

• About $3.8 million left the system. The attacker used 23 failed deposit transactions.
• Withdrawals went out to other chains through the Omni bridge infrastructure.
• The postmortem says: "This was a bug of the NEAR Intents contract, not a bug of the Omni infrastructure."
• The first public statement on 1 October had blamed the interaction between Omni and the contract. The postmortem changes that account.

Detection gap

• Monitoring compared tokens on origin chains with total token balances on NEAR.
• It did not compare users' internal balances with the tokens the contract actually held.
• The team says it added that check, with an automatic pause if the two diverge.

Earlier reports and the bounty

• A January 2026 bug bounty report on a similar third-party call feature was fixed in two days. It was not exploited.
• The 7 October report came from researcher Rohan Ganapa through HackenProof. The postmortem says he received $300,000.
• Shevchenko wrote that the feature "had a history of bug reports, all in the gap between its two steps."

Recovery, according to the postmortem

• The attacker returned the funds within 36 hours of detection, with help from SHIELD, chain analysis and outside researchers.
• On 2 October Shevchenko posted a public message to the attacker with a return deadline.
• The Crypto Times reports an on-chain message from the attacker saying the funds were returned and that they were in the wrong.
• Two outlets report the team had already refilled its contracts from its own funds.
• On-chain investigator ZachXBT flagged abnormal outflows from a BNB Chain wallet linked to the protocol, per The Crypto Times and Coindaro.

How the bug worked

What follows is our plain reading of the postmortem, without code.

The system tracks three things:

1. Tokens on the origin chain.
2. The same tokens on NEAR.
3. A private ledger inside intents.near with each user's balance.

One rule must always hold. The ledger must never promise more than the contract really holds.

When someone deposited, the contract could also notify a third-party contract. The attacker built a contract that made that notification fail on purpose.

NEAR runs steps one after another, not all at once. When the notification failed, the token contract sent the deposit back to the attacker. But the NEAR Intents contract kept the credit in its ledger.

Deposit  ->  ledger credited
Notify   ->  fails on purpose
Token contract  ->  refunds the tokens
Ledger   ->  credit stays   (ghost funds)

Repeated 23 times, the ledger showed about $3.8M more than the contract held. The attacker then withdrew real tokens against that credit. The withdrawals looked normal, because the contract held plenty of tokens from other users.

The postmortem does not say exactly why the credit was not rolled back. One independent analysis suggests silent error handling or too little gas. That is a reconstruction. It is not confirmed.

What is not known

• How many users were affected. The postmortem gives no count.
• Which solvers were affected. None are named.
• Which token the 23 deposits used. An early statement from NEAR's co-founder said the bug was isolated to USDT on BSC. The postmortem does not repeat that.
• Who the attacker is. No public identification.
• Why the attacker returned the funds, and on what terms. The postmortem mentions negotiations but gives no terms.
• What the 7 October bug was. It has not been disclosed.
• Why the January fix was a patch and not a removal.
• Whether any funds beyond what the postmortem says were affected.

Where sources disagree

• Duration. One outlet says about 37 hours. Another says nearly 40. The withdrawals span about 37.7 hours. From the first withdrawal to detection is about 40 hours. Both fit the same timeline.
• "100% recovered". The postmortem and coverage say everything came back. One outlet counts a Bitcoin return worth about 78% of the loss, per an outside estimate. The rest is said to have returned another way, unexplained. Outlets differ on whether Bitcoin and Monero were returned.
• Cause. The 1 October statement named Omni. The postmortem says the contract.
• Attacker address. One outlet publishes a theft address attributed to ZachXBT. ThreatWire found no second source, so it does not repeat it.
• Classification. DefiLlama lists the incident under bridges. That entry predates the postmortem.

Lessons for builders

• Keep the invariant. Internal balances must never exceed real holdings. Monitor it, not only the bridge.
• Pause automatically. If the invariant breaks, stop the contract without waiting for a person.
• Handle failed callbacks. In an asynchronous runtime, a later step can fail after an earlier one succeeded. Credit a balance only when the token movement is final.
• Treat notification targets as hostile. A third-party receiver can fail, stall or misbehave.
• Surface errors. Do not ignore failures in callbacks.
• Act on repeat reports. A feature that keeps drawing critical reports may be better removed. NEAR Intents removed this one.

What users should do

Nothing urgent, if the postmortem is right that all affected users were made whole. ThreatWire has not verified that.

Follow the official NEAR Intents channels for updates. Be cautious about unofficial messages claiming to offer refunds.

Sources: the NEAR Intents postmortem, as reported by The Defiant, The Crypto Times and Coindaro, plus an independent analysis on the thecoding Substack. We did not read the original X post directly, and none of those outlets are linked here.