TrustedVolumes Exploit Drains $5.87M As 1inch Resolver Risk Returns

Changelly



Security firm Blockaid has flagged an active exploit against TrustedVolumes, a 1inch market maker and resolver, with at least $5.87 million drained on Ethereum. The affected contract was identified as the TrustedVolumes resolver, with extracted assets including 1,291.16 WETH, 206,282 USDT, 16.939 WBTC, and 1,268,771 USDC.

The incident does not currently read like a broad 1inch user-fund compromise. The exposed component sits around resolver infrastructure used by a liquidity provider, not the normal user-facing swap flow. That distinction matters because 1inch relies on external resolvers and market makers to fill certain orders, while those third-party systems can carry their own contract, access-control, and inventory risks.

Blockaid also linked the attacker to the same entity behind the March 2025 1inch Fusion V1 incident. The current attack, however, appears to involve a different vulnerability in a custom RFQ swap proxy controlled by TrustedVolumes. The loss figure may change because the exploit was still being described as ongoing when the first public alerts circulated.

Why The March 2025 Link Matters

The earlier 1inch Fusion V1 incident hit resolver infrastructure rather than ordinary 1inch users. Security analysis from Halborn described how the attacker targeted resolvers, which are independent entities that fulfill orders inside the 1inch ecosystem. Decurity’s postmortem traced that attack to a calldata corruption issue in the old Fusion V1 path, where a crafted order let the attacker drain value from a resolver contract.

The new TrustedVolumes incident is different in technical shape, but the risk theme is similar. Aggregators can route trades through sophisticated off-chain and on-chain execution layers, and those layers depend on resolver contracts, custom proxies, market-maker inventories, whitelists, permissions, and monitoring. When one of those systems breaks, losses can concentrate inside a liquidity provider even if the aggregator’s core interface continues operating.

That makes resolver security a more important part of DeFi risk than many users realize. A swap may look simple from the wallet screen, but execution can involve RFQ flows, private pricing, solver competition, settlement contracts, inventory movement, and third-party integrations. Each extra layer can improve pricing and routing, but it also adds another place where a custom contract can fail.

DeFi’s May Security Pressure Builds

The TrustedVolumes drain lands during another difficult stretch for DeFi security. Users were already reacting to the Ekubo router exploit, where insufficient access control reportedly exposed EVM router approvals, and the Aave-Kelp recovery fight, where frozen exploit-linked ETH created a governance and legal battle around recovery.

Recent incidents have shown that DeFi losses are no longer limited to one obvious category of bug. Routing contracts, bridge verification, approval design, privileged roles, perps accounting, liquidity caps, and resolver infrastructure are all becoming live attack surfaces. The April exploit wave already pushed DeFi loss totals sharply higher, and fresh May incidents are keeping security teams under pressure before many protocols have finished postmortems from the previous round.

For liquidity providers and market makers, the TrustedVolumes case is especially direct. Resolver contracts may not be visible to most retail users, but they can hold or control large token inventories and execute high-value settlement logic. A weakness inside that layer can turn a specialized execution tool into an immediate drain path.

The incident leaves 1inch ecosystem participants watching for a fuller technical breakdown, contract status, recovery steps, and whether any remaining TrustedVolumes-controlled infrastructure still carries exposure. The broader DeFi lesson is already visible: better pricing through custom execution infrastructure only works if the resolver layer is secured like core protocol code, not treated as a peripheral integration.



Source link

Ledger

Be the first to comment

Leave a Reply

Your email address will not be published.


*