NEAR intents exploit: what the $3.8M deposit bug means for our solver
What happened
The Defiant reported a $3.8M exploit in a NEAR-based intents system, with the project's own postmortem attributing the loss to a flaw in the deposit path rather than the matching engine. Intents are signed instructions that outside parties (solvers) execute on a user's behalf; the deposit flow is the boundary where a solver is credited for funds it believes it has received.
Why it matters for us
- Stream 9, item 3.1 (intent solving): the revenue model assumes we only take the surplus between a signed limit price and the achieved fill. A deposit-path bug would let a counterparty make a deposit that credits us without funding it, which turns our "risk-free" spread into a hole.
- Stream 3 (security screening): the existing mempool scanner scores opportunities by size and rebate. Nothing in it currently checks whether the counterparty's accounting has been validated.
- Stream 9, item 3.7 (attestations): this is exactly the case for a verifiable "funds received" attestation rather than trusting a project's own UI state.
What to do next
Rec 1: When intent-solver.js lands (s9-todo-001), require a settlement-side balance check before treating any intent as fillable. Simulated fills only until that exists.
Rec 2: Add a "counterparty accounting" risk note to the job-escrow design (s9-todo-002): release funds only against an on-chain deliverable commitment, never against a UI-reported state.
Rec 3: Do not add intents to the live scanner until research-todo-017-002 (CoW/UniswapX/Fusion requirements) has been completed and the deposit semantics of the chosen venue are documented.
Sources
Unblocks
research-todo-017-002 s9-todo-001 s9-todo-002