The recovery rate for crypto exploits is a number nobody markets. Across the past decade, protocols that lose funds to on-chain attackers claw back somewhere between one and three percent of principal โ and that estimate is generous, because it folds in white-hat returns and quiet settlements that most victims never disclose. Against that baseline, NEAR Intents' disclosure reads like a statistical outlier. Roughly $3.8 million taken. An exploiter identified. A 48-hour ultimatum issued. Full restitution executed. A hundred percent recovery, closed inside a two-day window.
That is the headline. It is also the least informative number in the entire event.
Because the metric that should anchor any serious read of this incident is not the recovery rate. It is the disclosure rate of the root cause, and that figure currently sits at zero. Funds came back. The vulnerability has not been described. Those two facts are not the same fact, and the gap between them is where every real question lives.
The Context: What NEAR Intents Actually Is
To read this event correctly, you have to understand what was attacked โ because an intent protocol is not an AMM, and the attack surface is not comparable.
NEAR Intents is an intent-based execution layer sitting inside the NEAR ecosystem. The design premise is chain abstraction: a user declares a desired outcome โ "swap 1 ETH for at least 3,000 USDC on any chain" โ and a competitive set of solvers bids to fulfill that outcome. The user never specifies a route. The user never touches a bridge. The user never chooses a liquidity venue. They sign an intent; the solver network resolves it.
This is not novel architecture in isolation. CoW Protocol proved the model on a single chain with batch auctions and MEV protection. UniswapX proved it with Uniswap's distribution advantage baked in. 1inch Fusion proved it with an aggregator's flow at the top of the funnel. The differentiation NEAR Intents pursues is cross-chain execution โ moving the solver auction across settlement domains rather than confining it to one.
That ambition is precisely what expands the attack surface. A single-chain intent system has a bounded pipeline: user signature, solver competition, settlement contract. A cross-chain intent system inserts at least two additional stages โ a cross-chain message layer and a verification step on the destination domain โ and each stage is a potential fault line.
I have audited enough pre-launch token distributions to know that complexity is not a feature. It is a liability surface. In 2017, while working as a junior developer, I reviewed the whitepapers and contract logic of fifteen pre-sale ICOs, including Golem and Status. One project's token distribution mechanism carried a reentrancy flaw that would have allowed a caller to re-enter the distribution function before state finalized. I flagged it; the launch slipped. That single finding reshaped how I read every protocol since: the number of moving parts is inversely correlated with the probability of correct execution under adversarial pressure.
NEAR Intents has many moving parts. And on this occasion, at least one of them failed.
The Core: Reading the Attack Through the Verbs
Here is the discipline I apply to every post-incident disclosure, and it is the same discipline I applied to the on-chain flow data during the Terra/Luna collapse in May 2022. When a protocol describes an attack, ignore the adjectives and read the verbs. The verbs tell you what the team actually did. The adjectives tell you what the team wants you to feel.
In the NEAR Intents disclosure, four verbs carry the entire evidentiary load: stolen, identified, ultimatum, returned.
Start with stolen. Roughly $3.8 million left the protocol's control without authorization. This single fact falsifies a whole class of claims. Any protocol that has lost funds to an external actor has, by definition, demonstrated a material defect in either its contract layer, its settlement logic, or its key management. This is not a matter of technical sophistication. It is a matter of security engineering outcomes. A protocol can be architecturally elegant and operationally compromised at the same time; the $3.8M figure is the operational verdict, and it overrides the architectural pitch.
The interesting verb is identified. In a pure anonymous attack โ the kind that defines most of the industry's worst days โ teams cannot identify the attacker. They watch funds move into mixers and they write post-mortems about what they could not prevent. The ability to identify an exploiter within 48 hours implies one of a small number of attribution paths. Either the attacker touched a KYC-gated on-ramp, meaning a centralized exchange holds a verified identity at the other end of the flow. Or the attacker's on-chain history clustered with a previously doxxed address, collapsing pseudonymity through transaction-graph analysis. Or the exploit originated from a leaked private key or a front-end compromise, which points toward an insider or a semi-insider rather than a clean external breach.
Each of those paths tells a different story about what actually failed. And that is the point: the verb identified is not a marketing flourish. It is forensic evidence, and it narrows the hypothesis space considerably. A team that can identify an attacker is a team that is holding leverage. Leverage does not appear from nowhere. It appears because someone left a thread that could be pulled.
The third verb, ultimatum, is the one the industry will underweight. A 48-hour deadline is not a technical remedy. It is a pressure mechanism, and it belongs to the toolkit of negotiation and legal threat, not of cryptography. This is where the event stops being a pure security incident and becomes a hybrid of on-chain tracking, social engineering, and legal positioning. The ultimatum implies the team believed it could impose real cost on the attacker โ reputational, financial, or criminal. You do not issue a deadline you cannot enforce. The existence of the deadline is itself a signal about what the team knows and whom it can reach.
The final verb, returned, closes the loop. Funds came back. Full restitution. From a purely accounting standpoint, the protocol is made whole.
Now the number that matters. Recovery is the headline; the disclosure of root cause is the substance. And on substance, the record is empty. The disclosure describes what was lost and what was recovered. It does not describe what was broken. There is no vulnerability class. No affected contract. No timeline of the exploit path. No confirmation that the flaw has been patched. No statement that a re-audit has been commissioned.
The alpha isn't in the press release; it's in the silenced code. And the code is silent here.
The Evidence Chain, Reconstructed
Let me build the chain the way I would build it for a fund memo, using only what the disclosure supports plus what the architecture implies.
Stage one: intent signing. A user signs an intent expressing a desired outcome. The signature is the authorization primitive. If an attacker can replay or forge a signed intent, they can execute against a user's authority without the user's knowledge. Signature replay is a classic failure mode in intent systems, and it is frequently underestimated because the cryptographic primitive itself is sound; the flaw lives in the nonce management or the domain separation around it.
Stage two: solver competition. Solvers bid to fulfill the intent. In a competitive auction, the winning solver is chosen on price. If the solver selection logic is manipulable, an attacker can either win auctions they should lose or capture value during fulfillment. Solver misbehavior is a distinct threat class from external hacking, and it is structurally under-disclosed because admitting it exposes the economic design rather than just the code.
Stage three: settlement and verification. The winning solver executes, and the settlement contract verifies the outcome before releasing funds. This is the highest-value target in the pipeline, because it is where value actually moves. A logic flaw here โ an incorrect state check, a missing access control, an order-of-operations error โ is the most common route to a clean drain.
Stage four: cross-chain message. For a cross-chain intent, the fulfillment on the destination domain depends on a message arriving correctly from the origin. If the message layer can be spoofed or replayed, the attacker bypasses the origin entirely and drains the destination.
The NEAR Intents disclosure does not tell us which stage failed. That omission is not a minor editorial gap. It is the difference between a bounded, patched, one-off defect and a systemic weakness in the pipeline that a second attacker can re-exploit next week. A defect in stage four is a cross-chain trust problem. A defect in stage one is a cryptography-adjacent implementation problem. A defect in stage three is a contract-engineering problem. Each carries a different remediation path and a different residual risk.
What I can say with reasonable confidence, drawing on the pattern rather than the disclosure, is that the vulnerability was probably repairable rather than terminal. The team recovered funds within 48 hours. That timeline is only possible if the attacker had not laundered the proceeds through a mixer, had not bridged them into an untraceable pool, and had not destroyed the attribution trail. A terminal attack โ funds through Tornado-style infrastructure and gone โ has a recovery probability approaching zero, regardless of how capable the response team is. The speed and completeness of restitution imply the trail was still warm when the team acted.
That inference cuts both ways. It is good news for the recovery. It is neutral-to-bad news for the security posture, because a warm trail means the attacker was reachable โ which is consistent with a semi-attributable actor, and semi-attributable actors are frequently insiders or key-management failures rather than elite external crews.
The Trust Ledger
Here is what the market will systematically misprice. The ledger remembers what the marketing forgets. A hundred-percent recovery will be filed under "competence" by most observers, and that filing is wrong. Recovery competence and prevention competence are different skills, executed by different teams, measured against different baselines. A protocol can be excellent at incident response and poor at preventive security. In fact, the two often trade off, because a team that has built a strong response capability may be implicitly accepting that incidents will happen.
This is the same structural pattern I saw in the 2020 DeFi Summer, when I wrote a Python script to track liquidity-pool inefficiencies across Uniswap and SushiSwap. The script surfaced a $2.4 million arbitrage created by delayed oracle updates, and executing it returned 15% for the fund in 48 hours. The lesson was not that arbitrage is easy. The lesson was that inefficiencies persist precisely where the market has stopped paying attention โ where a mechanism is trusted rather than verified. Security disclosure works the same way. The market trusts "full recovery" as a closing statement. The data treats it as an opening hypothesis.
The right question is not whether NEAR Intents recovered the money. It is whether NEAR Intents can survive the next attempt. And the disclosure gives us no basis to answer that, because it never names the flaw. Scarcity is an algorithm, not a belief system โ and the scarcity here is information, not capital. The protocol returned $3.8 million and withheld the one thing that would let anyone independently assess whether the protocol is safe to use again.
The Contrarian Angle: Recovery Is Not Remediation
Here is where I part company with the consensus read.
The dominant interpretation of this event is that NEAR Intents "handled it well." Funds recovered, attacker identified, deadline enforced, resolution achieved. Under that framing, the incident is a net positive for the protocol's reputation โ a rare case where a team outmaneuvered an attacker.
That framing conflates two variables. Correlations are the lie; liquidity is the truth. The correlation here is between recovery and competence. The truth is that recovery says nothing about whether the underlying flaw has been eliminated. It is entirely possible โ and, given the information void, not improbable โ that the team recovered the funds without fully closing the attack path. Recovery is an outcome measured in dollars. Remediation is an outcome measured in attack-surface reduction. They are not the same measurement, and the disclosure only reports the first.
There is a second blind spot. The ultimatum-and-recovery sequence creates a strong incentive to narrate the event as a triumph, and that incentive can crowd out the harder disclosure. A post-mortem that names the vulnerability class is uncomfortable. It tells competitors exactly where the weakness was. It tells future attackers which stage to probe. It invites scrutiny of the audit process. The rational short-term move is to emphasize the recovery and stay quiet on the root cause. That move is rational for the protocol and dangerous for its users, because users who cannot see the flaw cannot price the residual risk.
And there is a third, sharper possibility. The full-recovery figure may be true and still incomplete. "All funds returned" is compatible with a range of settlements โ including one in which a portion was quietly treated as a white-hat bounty or an incentive for cooperation. The industry has a long history of "full recovery" announcements that elide negotiated splits. I am not asserting that happened here; I am noting that the disclosure does not exclude it, and that the absence of a line-item accounting is itself a data point.
Due diligence is the only hedge against chaos. And diligence, applied here, produces an uncomfortable conclusion: the most reassuring number in this story is also the most distracting one.
The Takeaway: What to Watch, Not What to Conclude
The forward signal is not the recovery. It is the post-mortem that has not yet appeared. Watch for three things over the next four to eight weeks. First, whether NEAR Intents publishes a root-cause analysis naming the vulnerability class and the affected component โ the presence or absence of that document will tell you more about the team's security culture than the recovery ever could. Second, whether an independent re-audit is commissioned and disclosed, because a patched flaw without third-party verification is a claim, not a proof. Third, whether the protocol's locked value drifts downward despite the recovery, because capital that understands security will reprice the risk even when the headline is positive.
A hundred-percent recovery is rare. So is a hundred-percent honest post-mortem. Watch which one NEAR Intents chooses to deliver.