1inch Fusion Resolver TrustedVolumes Hit by $6.7M Exploit — Bounty Floated, Same Operator Behind 2025 Hack

By Jaspal Singh May 8, 2026 Updated: May 8, 2026

TrustedVolumes, an independent market maker that operates as a resolver for 1inch Fusion, lost approximately $6.7 million on May 7, 2026. The funds were drained across three Ethereum addresses — two holding roughly $3 million each, and a third holding about $700,000. 1inch's official position: this is not a 1inch protocol exploit. Co-founder Sergei Kunz called TrustedVolumes “independent” and said the broader 1inch infrastructure is unaffected. The technical story matters more than the corporate framing.

The same attacker who pulled this off was responsible for a March 2025 1inch Fusion V1 resolver exploit that took roughly $5 million in USDC and Wrapped Ether. That exploit was eventually returned under a bug bounty arrangement. TrustedVolumes is now floating the same model — bounty for return, “mutually acceptable resolution” if the attacker reaches out. The question is what this pattern says about how DeFi protocols handle exploit recovery and what is structurally wrong with the resolver model that keeps producing the same vulnerability class.

What Actually Happened: The Vulnerability Mechanism

From CertiK's analysis and Blockaid's threat-intel reporting:

The attack pattern: Attacker registered themselves as an allowed order signer on TrustedVolumes' resolver contract through a publicly callable function
The execution: Once registered, attacker signed and executed unauthorized orders that transferred funds out of the resolver to the attacker's three wallets
The vulnerability class: Insufficient access control on the signer-registration function — anyone could become an authorized signer rather than only the resolver operator
Difference from 2025: Different specific vulnerability than the March 2025 1inch Fusion V1 incident, but Blockaid attributes both to the same attacker operator based on wallet pattern analysis

This is a textbook DeFi resolver vulnerability — the same pattern that has hit half a dozen DEX aggregators and intent-based protocols in the last 24 months. The fix is straightforward (require multi-sig or owner-only authorization for signer registration). The interesting question is why resolvers keep shipping this class of bug.

What a 'Resolver' Is and Why This Matters Beyond TrustedVolumes

1inch Fusion is an “intent-based” trading protocol. Users sign an intent (“swap X tokens for at least Y other tokens by deadline Z”) and resolvers — independent market makers — compete to fill the order with the best execution. The resolver wins the spread between the user's minimum acceptable price and the actual market price.

To do this efficiently, resolvers run their own custom infrastructure: smart contracts that hold liquidity, signers that approve order execution, and off-chain matching engines. TrustedVolumes is one of many resolvers; 1inch's own tally is a multi-dozen ecosystem. Each resolver is independently secured. The 1inch core protocol is not the attack surface; the resolvers are.

This is the architectural choice 1inch made when designing Fusion: decentralize the matching layer to many independent operators, accept that each one is independently secured (and therefore independently vulnerable), and rely on competitive pressure to keep operators security-disciplined. The trade-off is that “1inch is not affected” is technically true on every resolver hack — but users who routed orders through the affected resolver still lose money or get worse fills until the resolver is restored.

The Bounty Pattern: Ransom by Another Name?

Both the March 2025 1inch Fusion V1 exploit and now the May 2026 TrustedVolumes exploit have followed the same recovery playbook: company offers a bug bounty and “constructive communication” in exchange for return of funds. In 2025, most stolen funds were returned. The current bounty offer to TrustedVolumes' attacker explicitly references this precedent.

The crypto industry has effectively normalized this pattern: a sophisticated attacker exploits a real vulnerability, then negotiates the return for a percentage cut. The economics work because the alternative for the attacker is moving stolen funds through mixers and accepting steep liquidity discounts; the alternative for the protocol is permanent reputational damage and customer fund losses. The two parties meet at a price both can live with.

Critics call this ransom by another name. Defenders call it pragmatic recovery. The honest read is somewhere in the middle: the bounty pattern works for individual incidents but creates strange incentives at the system level. If exploits are reliably profitable up to negotiated bounty thresholds, the marginal economics of attacking DeFi protocols stay positive. That keeps a steady stream of new attempts, which is exactly the pattern we see.

My Take

1inch's framing — “TrustedVolumes is independent, this is not a 1inch protocol issue” — is technically correct and strategically problematic. Users who lost money through the affected resolver did so while routing through 1inch Fusion. From the user's perspective, “1inch routed my order through a resolver and the resolver got hacked” is functionally indistinguishable from “1inch got hacked.” The fact that 1inch's core contracts are untouched is meaningful for protocol-level systemic risk but not for individual user trust.

The structural issue is that 1inch Fusion's resolver model concentrates risk in third parties without giving users a way to evaluate which resolvers are well-secured. A user signing an intent has no visibility into which resolver will fill it; the matching engine picks based on execution price. Until 1inch surfaces resolver-level security ratings (or implements protocol-level insurance for resolver failures), this exact incident pattern will keep recurring. The fix is not technically hard — it is a UX and protocol governance choice.

The other thing worth flagging: this is the SECOND incident in 14 months from the same attacker operator. That is not random. Either 1inch's resolvers share enough architectural commonality that one attack pattern unlocks multiple targets, or this attacker has built specialized tooling for the resolver attack class. Both possibilities argue for 1inch to take protocol-level responsibility for resolver security standards rather than treating each resolver as fully independent. The current “not our problem, it's an independent operator” framing will not survive a third major incident.

Frequently Asked Questions

What is a resolver in 1inch Fusion?
A resolver is an independent market maker / liquidity provider that fills user trade intents in 1inch Fusion. Users sign an intent (swap X for at least Y), and competing resolvers bid to execute. Each resolver runs its own infrastructure — smart contracts, signers, and matching logic — separate from 1inch's core protocol.

Did 1inch users lose money in this exploit?
The $6.7 million was held in TrustedVolumes' resolver contracts, not in 1inch's core protocol. 1inch claims no impact on its systems, infrastructure, or user funds. Practically, users who routed orders through TrustedVolumes during the exploit window may have experienced failed fills or worse execution, but the core 1inch protocol contracts are intact.

Is this the same attacker as the 2025 1inch exploit?
Yes, according to Blockaid and SlowMist analysis. The same operator was responsible for the March 2025 1inch Fusion V1 resolver exploit that took roughly $5 million in USDC and Wrapped Ether. The technical vulnerability differed between the two incidents, but wallet patterns and operational fingerprints suggest the same actor.

What was the technical vulnerability?
Per CertiK's analysis: an insufficient access control bug allowed the attacker to register themselves as an allowed order signer through a public function on the resolver contract. Once registered, they could sign and execute unauthorized orders that drained the resolver's funds. The fix is to restrict signer registration to the resolver operator (multi-sig or owner-only).

Will the funds be returned?
TrustedVolumes has publicly offered a bug bounty and “constructive communication” to the attacker. The March 2025 exploit followed the same pattern and most stolen funds were eventually returned under a similar bounty arrangement. There is no guarantee the same outcome occurs here, but the precedent is encouraging.

The Bottom Line

1inch Fusion's resolver model concentrates exploit risk in independent third-party operators, and the same attacker has now hit the system twice in 14 months. The $6.7M loss is contained to TrustedVolumes' contracts, not 1inch's core protocol, but the user experience is functionally identical. Until 1inch implements resolver-level security standards or surfaces resolver-quality ratings to users, this class of incident will keep recurring. The bounty-for-return pattern works for individual recoveries but leaves the systemic incentive structure unchanged.