Executive summary
On 7 May 2026, TrustedVolumes, a market maker and resolver operating within 1inch's Fusion-style RFQ (Request for Quote) flow, was exploited for approximately $5.87 million on Ethereum. A single transaction drained four assets: WETH, USDT, WBTC, and USDC.
The root cause was an authorisation mismatch in the order-fill path: the contract validated a signer permission against one address but then debited funds from a different address in the same execution. Analyses by Rekt News and BlockSec both point to this as a parameter confusion bug in a custom RFQ proxy contract, not a standard, widely-audited router.
What happened
RFQ execution works on a straightforward trust assumption: only the authorised maker can trigger the release of their own token approvals. The exploit broke that assumption by exploiting a mismatch in how the contract identified the authorised party at different stages of the same call.
BlockSec's analysis identifies the vulnerability in function selector 0x4112e1c2() of the RFQ implementation contract. The whitelist lookup used one parameter field (varg4) to verify permission, while the subsequent transferFrom call debited funds from a different field (varg5). The registry wrote whitelist entries keyed by msg.sender, but read them back using the taker field, creating a gap where an attacker-controlled address could satisfy the permission check while the victim maker's approvals were used to pay out the funds.
In practice: the contract confirmed the attacker was authorised to act, then transferred tokens from the victim maker's wallet. The attacker walked away with four assets in a single transaction.
Why this class of bug is particularly dangerous
Authorisation mismatches in order-fill paths are high-severity precisely because they bypass the economic logic of the system, not just its code. In an RFQ model, a maker grants approvals on the assumption that only their authenticated counterparty can trigger a fill. When a contract checks permission against field A but executes against field B, that core assumption collapses, and any maker with outstanding approvals to the vulnerable proxy becomes an exposed position.
The fact that this was a custom, thinly-reviewed proxy contract rather than a standard router compounds the risk. Non-standard implementations in high-value execution paths deserve the same scrutiny as core protocol contracts.
What defenders can learn
Bind authorisation to the exact execution context. The same canonical maker address that appears in the transferFrom call must be the one validated in the permission mapping. Any divergence between the address checked for authorisation and the address debited for funds is a critical vulnerability.
Fail closed on parameter ambiguity. If an order's maker, taker, and receiver fields can diverge without an explicit signed commitment to all of them, the contract is operating on an incomplete trust model. Reject orders that don't bind all relevant addresses to a single signed intent.
Treat proxy contracts as primary attack surface. Thinly-reviewed proxies sitting in front of high-value maker approvals are a structural risk. Audit them with the same rigour as the core protocol, and consider whether a general-purpose proxy should hold access to multiple makers' unlimited approvals at all.
Cap allowance exposure. Per-order or per-asset approval limits with expiry windows reduce the blast radius of any single exploit. Unlimited approvals from high-value makers to proxies are a standing vulnerability waiting for the right trigger.
Key details
- Date: 7 May 2026
- Loss: ~$5.87M on-chain
- Chain: Ethereum
- Exploit transaction:
0xc5c61b3a… - Attacker:
0x61e63016… - Vulnerable proxy:
0xeEeEEe53…
Further reading
If you operate RFQ, intent, or OTC execution infrastructure, or hold large maker approvals behind thinly-audited proxies, Security4Web3 can help you threat-model the trust path, design isolation controls, and build detection that fires before approvals become a single-step drain.