TrustedVolumes $6.7M Exploit: 1inch Denies Breach

A TrustedVolumes exploit has drained $6.7 million from the independent DeFi market maker, which operates as a resolver inside 1inch's swap infrastructure. The theft landed Thursday amid a flurry of finger-pointing about who, exactly, bears responsibility — and the answer turns out to matter quite a bit for how you think about third-party risk in decentralized trading.

What Happened in the TrustedVolumes Exploit?

The attack was caught in real time by Blockaid, a Web3 security firm whose exploit-detection system flagged abnormal activity tied to TrustedVolumes-controlled swap infrastructure on Ethereum. Blockaid's early estimate put losses at $5.87 million — covering Wrapped Ether, USDT, Wrapped Bitcoin and USDC. The final tally came in higher.

TrustedVolumes later confirmed the breach in an X post, saying approximately $6.7 million was split across three wallets. Two addresses each held around $3 million; a third contained roughly $700,000. The market maker said it was open to 'constructive communication' and a bug bounty arrangement — the standard soft landing offer that's become a ritualized first move in DeFi exploits.

According to blockchain security firm CertiK, the attacker gained a foothold through a public function that let anyone register as an allowed order signer on TrustedVolumes' custom contracts. Once registered, they used that authorization to execute swap orders that pushed funds directly to attacker-controlled addresses. It's a relatively clean attack — no flashloan gymnastics, no oracle manipulation. Just a permissions door that shouldn't have been left unlocked.

We lack security in general. Blockchains just tend to have an immediate payoff. We need to pay more attention to kill switches, monitoring, circuit breakers, etc.

1inch Says It's Not Its Problem — Is That Fair?

1inch was quick to distance itself from the incident. In a post on X, the exchange said reports linking it directly to the TrustedVolumes theft were 'misleading,' and that 'neither 1inch nor any of the 1inch protocols are involved.' User funds and platform infrastructure were untouched, the company said.

Co-founder Sergej Kunz went further, explaining that 1inch Fusion resolver architecture relies on a network of independent third-party resolvers competing to fill swap orders on behalf of users. TrustedVolumes is one of many such resolvers — not a 1inch-owned entity. 'While it is true that 1inch uses TrustedVolumes as a resolver, we are one of many,' Kunz said.

Kunz called the framing of this as a '1inch hack' both 'confusing and harmful.' And technically, he's right. But technically right doesn't mean users shouldn't care. When a resolver that processes your swap orders gets drained, and that same resolver ran an identical exploit pattern back in March 2025, the question of whether 1inch vets who's in its resolver network is legitimate — even if the core contracts are clean.

While it is true that 1inch uses TrustedVolumes as a resolver, we are one of many.

The Same Attacker Did This Before

That's the part that deserves more attention. Both Blockaid and security researcher Vladimir Sobolev confirmed the attack was carried out by the same operator behind a March 2025 breach of 1inch Fusion V1 resolvers. At the time, SlowMist traced about $5 million in stolen assets, primarily USDC and Wrapped Ether. 1inch and the affected resolver eventually struck a bug bounty deal with the attacker, who returned most of the funds. Case closed — or so it seemed.

Now the same wallet is back, using a different vulnerability on the same class of infrastructure. Blockaid was careful to note the two attacks exploited separate flaws — this wasn't a repeat of an unpatched bug. But the pattern is hard to dismiss. A threat actor who has already targeted 1inch-adjacent resolvers once, returned funds under a negotiated deal, and then hit the same category of target again six weeks later isn't a white hat having a moment of weakness. That profile deserves scrutiny.

Sobolev told reporters there was 'no risk for 1inch users' from the current incident, but was blunter about the systemic issue: 'We lack security in general. Blockchains just tend to have an immediate payoff.' His comment pointed at the broader gap between how quickly DeFi can lose funds and how slowly the industry moves toward real-time kill switches, monitoring, and circuit breakers. This kind of DeFi security risk isn't unique to TrustedVolumes — it's baked into the resolver model across the entire space.

The incident also echoes a pattern seen elsewhere in the DeFi ecosystem, where protocol-level exploits in decentralized finance repeatedly expose the same structural weaknesses. When third-party infrastructure providers deploy their own contracts alongside a core protocol, the attack surface expands in ways that aren't always visible to end users.

No risk for 1inch users.

What Does This Mean for DeFi Resolver Risk?

The broader implication is one the DeFi industry keeps bumping into: modular architecture creates modular attack surfaces. When protocols like 1inch offload order execution to a competitive resolver network, they gain efficiency and censorship resistance. What they lose is unified security accountability. TrustedVolumes operates independently across multiple protocols — not just 1inch. That means the $6.7 million problem belongs to TrustedVolumes, but the reputational knock travels upstream.

For users, the immediate takeaway is that 'your funds are safe' is a conditional statement in DeFi. Safe from what? The core 1inch contracts weren't touched here. But if you happened to have a pending swap being executed through TrustedVolumes at the wrong moment, the picture might look different. The broader pattern of DeFi vulnerabilities affecting users through third-party integrations is something anyone with assets in decentralized protocols should track.

TrustedVolumes has offered to negotiate. Whether the attacker — who already collected a payout in March 2025 and came back for more in May 2026 — sees a second bug bounty as attractive is another question entirely.