In May 2026, TrustedVolumes, a DeFi liquidity provider and market maker associated with 1inch, was the victim of a hack. The attacker exploited a vulnerability in the protocol’s request-for-quote (RFQ) swap proxy that allowed them to steal an estimated $6.7 million from the protocol.
Inside the Attack
TrustedVolumes’ RFQ swap proxy is part of its market maker functionality. When someone wants to trade crypto, the RFQ swap proxy offers them a price for the swap that is completed from the protocol’s own inventory of the token. It sits between the user’s swap request and TrustedVolumes’ funds and is responsible for validating that TrustedVolumes authorized the swap before executing it.
This authorization is in the form of a digital signature, and the vulnerability exploited by the attacker was in the protocol’s signature validation logic. The protocol had a publicly accessible function that was responsible for managing the allowlist for authorized order signers. Since this function was unprotected by access controls, the attacker could add themselves to the allowlist, thereby authorizing themselves to approve orders on behalf of TrustedVolumes.
With this authority, the attacker could create trade orders that looked legitimate to the protocol since the digital signature attached to the orders was linked to an approved address. The attacker exploited this authority to perform trades that drained an estimated $6.7 million in WETH, WBTC, USDT, and USDC from the protocol. These tokens were all converted into ETH before being split across multiple blockchain wallets.
Lessons Learned from the Attack
The TrustedVolumes hack involved failed validation of digital signatures on trading orders. However, the issue wasn’t a logical or implementation error in the cryptographic code. Instead, it was a simple access control error. By allowing anyone to add themselves to the list of approved trade order signers, the protocol undermined its ability to effectively authorize trade orders.
These types of access control vulnerabilities have been around for a long time. Marking a function as public simplifies privilege management — since the protocol won’t break if an authorized user doesn’t have access — but it can undermine security. Smart contract functions should be private or internal by default unless there is a clear business need for them to be public.
This type of vulnerability could have been found and fixed by a comprehensive smart contract audit. For help with protecting your protocol against similar threats, get in touch with Halborn.