Back to blog

NEAR Intents exploit: the integration boundary was the test

3 min read
NEAR Intents exploit: the integration boundary was the test

Sources checked: . FailSafe Research.

An integration can fail even when teams understand its individual components. The important question is whether the combined workflow preserves the same authority and accounting rules at every transition.

The recovery update changes the headline

NEAR Intents’ 1 October statement attributed an approximately $3.8 million exploit to the interaction between Omni deposit and withdrawal infrastructure and the Intents contract. It reported a contract-side patch and temporary restrictions while infrastructure work continued. In a subsequent recovery statement, NEAR co-founder Illia Polosukhin said all funds had been returned.

It would be misleading to report the initial amount as an established permanent loss after that update. The statements also do not establish that the underlying NEAR blockchain was compromised. This article does not independently reconstruct the exploit or the return transfers.

Write the invariant before the test

For a payment or settlement workflow, define the business property that must remain true. A withdrawal must have the intended authorization. A state change must be reflected consistently across participating services. A retry must not create a second economic effect.

Then map which component verifies each property. An assessment should include the handoff, not simply test each API in isolation. Errors, retries, partial completion and changed permissions are useful cases because they reveal assumptions hidden by the normal happy path.

Design safe validation and suspension

Use synthetic balances or a dedicated test deployment, with explicit limits on state changes and external calls. Agree stop conditions before running an agent. Record the expected and observed states so an engineer can reproduce the failure without recreating a live financial incident.

Suspending part of an integration also needs a test. Determine whether queued work, cached permissions or another route can bypass the pause. Restart only after the intended property is demonstrated and reconciliation has a named owner.

Bring the integration into the pentest scope

FailSafe SWARM connects threat modeling, active testing and reproduced findings across agreed application and API workflows. That approach is useful when business risk emerges between services rather than in a single vulnerable package.

For another distinction between response metrics, read our Binance analysis. A reported transfer, a freeze and a completed return describe different events. FailSafe’s existing NEAR-related work does not imply a role in this incident’s investigation or recovery.

Explore the October incident collection for related cases and existing FailSafe coverage. Incident descriptions are attributed to the linked sources; assessment recommendations are FailSafe’s analysis. We have not conducted forensic investigations of these incidents.

Questions & answers

Questions about this topic

Direct answers to common questions about this page.

The initial statement reported an approximately $3.8M exploit. A later statement from NEAR’s co-founder says the funds were returned in full.

No. The cited statement describes an interaction between deposit and withdrawal infrastructure and the Intents contract.

Put this guidance to work

Discuss a scoped FailSafe SWARM assessment with reproduced findings, engineering handoff and remediation retesting. Containment and forensic investigation remain separate workstreams.

Test the boundary that matters