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.
Key concepts: This analysis covers access control failure, RFQ protocol, smart contract bug, security vulnerability and related blockchain security topics.
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.
Authorisation Logic Failures: The Most Dangerous Smart Contract Bug Class
The TrustedVolumes exploit is a clean illustration of why authorisation mismatches rank among the most severe vulnerability classes in smart contract security. The exploit did not require a complex multi-step attack, a flash loan, or a novel cryptographic technique. A single transaction was sufficient, because the contract's permission model said one thing and its execution logic did another.
That gap — between what a contract checks and what it acts on — is the defining characteristic of this bug class. It is also why it is so consistently underdetected before deployment. Unit tests typically exercise the happy path: the authorised party does the authorised thing. They rarely explore whether the authorised party field and the fund-debiting field can be independently controlled by an attacker.
Why Authorisation Mismatches Are So Dangerous
- They bypass economic logic entirely: In RFQ and intent-based systems, the economic model depends on makers only releasing their approvals to authenticated counterparties. An authorisation mismatch doesn't just break a security control — it invalidates the entire trust model the system is built on.
- They affect every user simultaneously: A bug in a shared proxy or router doesn't exploit one user's funds — it potentially exposes the approvals of every maker who has granted access to the vulnerable contract. The blast radius scales with the number of integrated participants.
- They are invisible to standard monitoring: The exploit transaction looks like a legitimate fill to any monitoring that only checks whether the contract executed without reverting. Detecting it requires monitoring that also verifies the economic outcome — did the right address receive the funds, and did the right address pay them?
- Proxy contracts amplify the risk: Custom, thinly-reviewed proxies sitting in front of high-value approval sets are concentrated risk. The proxy's logic is the actual security boundary, but it often receives a fraction of the review time allocated to the core protocol contracts it wraps.
How to Catch This Class Before Deployment
The most reliable approach is to formally verify the authorisation invariant: that for every code path that results in a transferFrom or equivalent fund movement, the address used in the permission check is identical to the address debited. This is a property that can be expressed as a formal specification and verified exhaustively, not just tested against known cases.
Our smart contract audit specifically targets authorisation logic in order-fill paths, approval handling, and proxy routing — treating these as the primary attack surfaces they are. For execution infrastructure handling significant maker approvals, our formal verification service provides the exhaustive coverage that testing alone cannot: a mathematical proof that the authorisation invariant holds across all possible inputs, not just the ones a test suite happened to cover.
The TrustedVolumes incident follows a repeating pattern in DeFi: a bespoke component introduced into a high-value execution path receives less scrutiny than the core protocol it interacts with. Every non-standard component in the critical path of fund movement should be treated as primary attack surface and reviewed accordingly.