TrustedVolumes RFQ Exploit Drains $5.87M in One Tx

TrustedVolumes lost roughly $5.87 million in a single Ethereum transaction after an attacker abused a custom RFQ proxy tied to its market-making inventory. The TrustedVolumes RFQ exploit matters because the contract verified a signer but failed to verify whether that signer had authority over the funds being pulled.

TrustedVolumes RFQ exploit drained four major assets TrustedVolumes, a DeFi liquidity provider and 1inch market maker, was hit by an authorization failure that drained 1,291 WETH, 206,282 USDT, 16.939 WBTC and 1,268,771 USDC from its inventory, according to Rekt’s incident report . The exploit executed through one transaction and affected a custom RFQ swap proxy connected to TrustedVolumes’ own asset inventory.

QuillAudits placed the on-chain loss near $5.87 million and described the vulnerable proxy as 0xeEeEEe53033F7227d488ae83a27Bc9A9D5051756, according to QuillAudits’ technical breakdown . Halborn used a higher estimate of about $6.7 million, likely reflecting price timing and later accounting rather than a different core incident, in its TrustedVolumes hack explainer .

The strongest verified framing is clear: the attacker did not need to compromise a private key. The failure was in authorization logic. The proxy accepted orders that appeared valid under its own rules, then transferred real inventory from TrustedVolumes because approvals already existed.

Missing signer checks turned RFQ logic into a drain path RFQ systems rely on signed quotes. A maker signs an order, a taker presents it to a settlement contract, and the contract checks whether the maker authorized the trade before moving assets. TrustedVolumes’ implementation broke that separation between signature validity and asset ownership.

QuillAudits identified three linked bugs. First, registerAllowedOrderSigner(address signer, bool allowed) allowed an address to register its own signer. Second, replay protection read and wrote order status through different storage keys, so fills could pass repeatedly. Third, the order payload let the attacker set the inventory address used as the transferFrom source, according to QuillAudits’ exploit analysis . That combination created the core failure. The contract checked whether the attacker’s signer was approved for the attacker-controlled receiver, not whether that signer was approved to spend TrustedVolumes’ inventory. Rekt described the same issue as an authorization boundary failure: authentication answered the wrong question. The contract proved the attacker could sign for themselves. It did not prove they could spend from TrustedVolumes.

On-chain evidence shows one atomic transaction The exploit was not spread across a long campaign. Rekt identified the exploit transaction as 0xc5c61b3ac39d854773b9dc34bd0cdbc8b5bbf75f18551802a0b5881fcb990513, visible on Etherscan’s transaction record . Four fill calls moved four assets in one Ethereum block.

QuillAudits said the attacker deployed an exploit contract at 0xD4D5DB5EC65272B26F756712247281515F211E95, registered an attacker-controlled signer, and then used TrustedVolumes’ inventory address 0x9bA0CF1588E1DFA905eC948F7FE5104dD40EDa31 as the source of the drained tokens. The proxy transferred assets because the inventory had already granted unlimited approvals to the RFQ proxy.

The nominal payment back to the inventory was tiny. Rekt said the exploit contract sent 1 wei of USDC per fill while receiving millions in WETH, USDT, WBTC and USDC. That detail is the clearest sign of broken economic validation. The trade path completed because the contract’s checks passed, not because the exchange terms made economic sense.

Unlimited approvals made the authorization bug worse The exploit required a vulnerable RFQ proxy, but the loss scale came from unlimited token approvals. TrustedVolumes’ inventory had granted the proxy broad transfer rights over WETH, USDT, WBTC and USDC, according to QuillAudits. Once the authorization check failed, those approvals let the attacker pull assets directly from the market maker’s custody address.

This is the same approval-risk pattern that appears across many DeFi losses. Unlimited allowances are operationally convenient because market makers and routers need to move assets quickly. They are also dangerous when the receiving contract has a logic flaw. A bad approval does not create a bug, but it can turn a bug from a contained error into a full inventory drain. That is why this incident belongs in Web3 Fraud Files . The TrustedVolumes case is not just about one bad function. It is about the way custom trading infrastructure, inventory custody, proxy contracts and token approvals combine into one risk surface. When any one control breaks, the others must limit damage. Here, they amplified it.

TrustedVolumes’ public response left open questions Rekt reported that TrustedVolumes confirmed the exploit more than two hours after security firms had already mapped the mechanics, and that the team invited “constructive communication” through a bug bounty email and Telegram contact. The same report said the vulnerable implementation contract was not publicly verified on Etherscan and that no audit of the RFQ proxy had been publicly disclosed.

That response creates trust questions beyond the loss number. A market maker running custom code against millions in approved inventory should be able to show contract source, architecture, audits, emergency controls and a response process. If users and counterparties cannot inspect the code until after the exploit, independent risk assessment becomes almost impossible.

This connects with Cryptic Daily’s ShapeShift FOX Colony exploit analysis , where a control-path mismatch also allowed contract logic to treat an attacker-directed action as authorized. The mechanisms differ, but the lesson is similar: access control must bind the caller, the signer, the authority and the asset source inside the same security model.

What this reveals about RFQ market-maker risk The TrustedVolumes RFQ exploit shows that market-maker infrastructure deserves the same scrutiny as public DeFi protocols. RFQ systems may look like backend trading pipes, but if they hold approvals over live inventory, they become custody-critical contracts. A public signer function, miskeyed authorization mapping or broken replay guard can move funds as directly as a vault bug. Halborn framed the weakness as an access-control issue rather than a cryptographic failure, and that distinction matters. The signature itself did not need to be broken. The contract simply accepted the wrong relationship between signer and inventory. Smart contracts should treat signer authority, maker identity, inventory source and replay status as separate checks that must all pass.

The fix path should include source verification, independent audit disclosure, allowance review, replay-guard testing, signer-management restrictions and transaction-level limits on inventory outflows. Custom RFQ proxies should also include emergency pause controls and monitoring for economically irrational fills, such as trades where 1 wei is accepted against millions in assets.

TrustedVolumes’ next concrete signal should be a public postmortem that names the vulnerable implementation, lists the contracts involved, confirms final loss accounting and states whether any funds were recovered through the bug bounty channel. Until then, counterparties should treat unverified RFQ infrastructure with open-ended approvals as a direct custody risk, not as a passive trading tool.

This article is for informational purposes only and does not constitute financial or investment advice. ╗