A Public Signer-Registration Function Let an Attacker Empty TrustedVolumes' Vault for $5.87M

TrustedVolumes, a liquidity provider and resolver working inside 1inch's Fusion ecosystem, lost roughly $5.87 million across four assets in a single Ethereum transaction on May 7, 2026. The cause was not a leaked private key or a novel cryptographic break — it was an authorization boundary failure in a custom RFQ swap proxy that the TrustedVolumes team itself wrote, deployed, and controlled.

A function anyone could call let the attacker register themselves as a legitimate order signer. From there, the fill logic never checked whether that signer actually had any claim over the funds being moved.

CertiK was the first outside party to flag the incident. Blockaid posted its own alert roughly sixty seconds afterward. TrustedVolumes itself needed close to two and a half hours to acknowledge what on-chain observers had already pieced together.

01Security Researchers Beat the Team to the Diagnosis

CertiK's initial post laid out the mechanism in a single message: the attacker had registered itself through a public function as an AllowedOrderSigner, then executed an order that pulled funds from the victim. The firm urged anyone with exposure to revoke approvals to the vulnerable contract immediately.

Blockaid's follow-up, posted about a minute later, added the victim contract, the exploiter's address, the attack transaction, and a running total — $5.87M lost across four different tokens.

SlowMist published a root-cause breakdown shortly after, describing how signature validation checked allowedSigners[msg.sender][signer] keyed on the caller — the taker — rather than on the order's maker. That mismatch let an attacker register through registerAllowedOrderSigner and then execute forged orders against any maker's balance. Four separate drains followed, each pulling against unlimited token approvals, with no victim signature required at any point.

By the time TrustedVolumes confirmed the exploit, the attacker had already converted the stolen tokens into ETH. The team's statement was brief and formal: a bug-bounty contact address, links to the relevant wallets, and an offer of "constructive communication." It said nothing about the underlying cause or next steps. Outside researchers had mapped the entire mechanism before TrustedVolumes had published a single word about it.

02How Three Small Bugs Added Up to Full Drain Access

According to QuillAudits' analysis, three separate defects in the custom RFQ implementation combined to hand an outside party unrestricted access to TrustedVolumes' own treasury. None of the three individually demanded advanced technical skill — one of them was arguably discoverable just by reading the function's name.

Banteg's Foundry reproduction describes the underlying issue as an authorization boundary failure: the contract confirmed who had signed an order but never confirmed that the signer had any right to move the assets in question. Authentication and authorization were effectively treated as one check instead of two.

The first flaw was that registerAllowedOrderSigner() carried no access restriction. Any address could call it and register any externally owned account as an authorized signer for itself, acting as maker — no ownership check, no permissioning of any kind. The attacker used this to register its own EOA and become a recognized participant in a single transaction.

The second flaw compounded the first. Inside fillOrder(), the contract checked allowedOrderSigner[order.receiver][signer] — verifying only that the signer was permitted for the attacker's own receiver address, never verifying anything about the party actually holding the funds. The check proved the attacker was allowed to sign for itself; it proved nothing about control over the inventory being drained.

The third flaw sealed the outcome: the transfer logic used the taker field as the transfer's from address, and the attacker simply set taker to the victim. Because TrustedVolumes' inventory wallet had already granted the RFQ proxy unlimited ERC-20 approvals, no signature from the actual asset owner was needed — the proxy pulled straight from TrustedVolumes' own vault on the attacker's say-so.

A fourth safeguard also failed silently: replay protection technically existed, but the saltStatus mapping wrote to one storage key while a separate check read from another. As a result, all four drain calls sailed through the replay check without resistance, letting the same structural exploit fire four times in immediate succession within one transaction.

The cost of standing up the attack was trivial: one deployed contract and 4 wei of USDC total — a single wei per fill, sent as the nominal "payment" the RFQ structure required from the taker on each trade. The contract accepted these fractional-cent transfers as completed trades while releasing millions of dollars in the opposite direction.

Banteg's full reproduction in Foundry — including reconstructed Solidity, a flow diagram, and on-chain evidence — validated every step of the attack against a fork of block 25039669, without needing the actual attacker's signed data. In principle, any address holding four wei of USDC and about fifteen minutes could have replicated it.

Correcting any single one of the three core defects — the open registration function, the misdirected signer check, or the broken replay guard — would have prevented the exploit entirely.

03Four Drains Executed in One Block

The entire attack fit inside a single transaction. Four separate calls to the fill function stripped four different assets from TrustedVolumes' inventory, all within one Ethereum block: 1,291 WETH, 206,282 USDT, 16.939 WBTC, and 1,268,771 USDC, totaling approximately $5.87 million.

Each of the four calls followed an identical pattern: the attacker's contract invoked the fill function, the proxy drew the target asset from TrustedVolumes' inventory using its standing unlimited approval, and 1 wei of USDC was sent back to the inventory as a token gesture toward payment. The protocol's own logic executed all four trades — each one a forged order the contract had no way to distinguish from a legitimate one.

Exploit transaction (all four drains executed here): 0xc5c61b3ac39d854773b9dc34bd0cdbc8b5bbf75f18551802a0b5881fcb990513

Attacker EOAs: 0xC3EBDdEa4f69df717a8f5c89e7cF20C1c0389100 0x61e6301614178A2cA21Bfa0FBB30ABa06ACC2D1c

Exploit contract (one-shot contract acting as maker/receiver — received the drained funds): 0xD4D5DB5EC65272B26F756712247281515F211E95

Vulnerable RFQ proxy (TrustedVolumes' custom swap proxy — the attack's entry point): 0xeEeEEe53033F7227d488ae83a27Bc9A9D5051756

RFQ implementation contract (logic contract behind the proxy, holding the buggy code): 0x88eb28009351Fb414A5746F5d8CA91cdc02760d8

TrustedVolumes inventory owner (held the assets and the unlimited approvals to the proxy): 0x9bA0CF1588E1DFA905eC948F7FE5104dD40EDa31

Once the funds reached the exploit contract, the WETH was unwrapped and forwarded to the attacker's EOA, and the remaining USDT, WBTC, and USDC followed the same route out. The attacker then moved to convert and consolidate the proceeds quickly enough that the resulting positions were already visible on-chain while TrustedVolumes was still writing its confirmation post.

The stolen assets ended up split across two attacker-controlled wallets. Notably, TrustedVolumes' own post-incident accounting placed the loss at roughly $6.7 million, a figure somewhat higher than the $5.87 million total derived from on-chain pricing of the four drained assets at the time of the attack.

Stolen funds address 1: 0x61e6301614178a2ca21bfa0fbb30aba06acc2d1c

Stolen funds address 2: 0xc3ebddea4f69df717a8f5c89e7cf20c1c0389100

The asset movement outpaced the team's public response by a wide margin — the conversion into ETH had already happened before any official acknowledgment was posted.

04A Long Silence, Then a Bug Bounty Address

TrustedVolumes' confirmation post broke a social media silence that had stretched for well over a year — it was the team's first public statement in that span. There had been no prior security advisories, no maintenance updates, no community communication of any kind. The account's return to public posting doubled as an admission that it had just been exploited.

In that statement, TrustedVolumes said it was open to "constructive communication regarding a bug bounty and a mutually acceptable resolution," listing two contact channels: [email protected] and t.me/trustedvolumes.

The project's website advertises CeFi, DeFi, API, and About Us sections, but the linked API documentation offers little beyond a base URL and a production endpoint — no architecture explanation, no security disclosures, nothing substantive to explore. For an operation acting as a market maker and resolver with custody-adjacent control over millions of dollars in assets, the public footprint amounted to little more than a name, a Proton Mail address, and an empty documentation page.

No audit of the vulnerable RFQ proxy has ever surfaced publicly. The implementation contract itself was never verified on Etherscan — its source code was never submitted, meaning both underlying bugs were only ever visible to anyone willing to read raw bytecode.

The bug-bounty channel remains open, though whether the attacker engages with it is a separate matter. For context, this incident adds to what was already an especially damaging month for the sector — April saw roughly $635 million lost across 28 distinct incidents, the worst monthly total since the Bybit breach in February 2025.

05Takeaway

Stripped to its essentials, the incident traces back to a contract that moved millions of dollars without ever having gone through a rigorous security review. A permissionless registration function, a signer check pointed at the wrong address, and a replay guard that silently failed to fire were all it took. Banteg reconstructed the entire exploit path in Foundry within hours, demonstrating that any wallet with a few wei of USDC and about fifteen minutes of effort could have carried it out.

A negotiated return of funds, should one happen, would not retroactively verify the implementation contract, produce a meaningful audit, or account for the more than a year of public silence a market maker holding unlimited approvals over millions in customer-adjacent assets maintained before it had anything to say. The exploit vector varies from incident to incident — compromised keys, oracle manipulation, or in this case a broken authorization boundary — but the recurring theme across this cycle of losses remains the same: capital was placed under the control of code that was deployed before anyone rigorously asked whether it was safe.