TrustedVolumes Exploit — Permissionless Signer Registration + Wrong-Key Authorization Drains an RFQ Settlement Proxy

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2026-05-TrustedVolumes_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/TrustedVolumes_exp.sol.

Vulnerability classes: vuln/access-control/missing-auth · vuln/access-control/fake-account-substitution · vuln/auth/signature-validation

One-line summary: An RFQ settlement proxy authorizes signed orders against the attacker-controlled order.taker key instead of the fund-owning order.maker, and lets anyone self-register an allowed signer — so an attacker signs their own orders and pulls the victim resolver's unlimited-approved balances out for free.

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder. The settlement implementation is UNVERIFIED bytecode, so the PoC faithfully replays the attacker's exact on-chain calldata (the register call + 4 signed fill orders, with the real ECDSA signatures) against a mainnet fork pinned one block before the attack. Full verbose trace: output.txt.

Key info#

References: rekt.news · DarkNavy · Verichains

TL;DR#

TrustedVolumes runs an RFQ (request-for-quote) settlement proxy. A signed order says: a maker gives makerAmount of makerAsset, a taker gives takerAmount of takerAsset. The maker is the party whose funds physically move — the proxy pulls makerAsset out of order.maker via that maker's standing ERC20 approval to the proxy. To authorize this, the order must be signed by the maker, or by a key the maker has delegated to via an "allowed order signer" registry.

Two design flaws compose into a total drain:

• Bug #1 — permissionless signer registration. registerAllowedOrderSigner(address signer, bool allowed) (selector 0xea7faa61) has zero access control. It writes _allowedOrderSigner[msg.sender][signer] = allowed. Anyone can register any EOA as a valid signer for their own address.

• Bug #2 — authorization keyed on the wrong party. The fill function (selector 0x4112e1c2) recovers the order signer with ecrecover, then checks authorization as _allowedOrderSigner[order.taker][recoveredSigner] — using the taker (an attacker-controlled order field) as the lookup key instead of order.maker, who actually owns the funds.

The attacker's contract (which is itself the order taker) calls registerAllowedOrderSigner(attackerEOA, true) — setting _allowedOrderSigner[taker][attackerEOA] = true. It then submits four orders where maker = the victim resolver, taker = the attacker contract, makerAsset/makerAmount = the asset to steal, and takerAmount = 1 wei of dust. Because authorization is checked against the taker key (which the attacker controls and just registered), the attacker-signed orders pass — even though the victim maker never signed or approved them — and the maker's unlimited-approved balances are pulled out. Four orders drain WETH, USDT, WBTC and USDC for ~$5.87M, against a total of 4 wei of USDC dust paid in.

Background — what TrustedVolumes does#

TrustedVolumes is an off-chain-quoted, on-chain-settled RFQ trading venue (a "trusted volumes" maker/resolver network). Market makers ("resolvers") quote prices off-chain and sign orders; a settlement contract atomically swaps the two sides on-chain. To make settlement cheap and to support delegated signing, resolvers grant the settlement proxy a standing (often unlimited) ERC20 approval and may authorize additional signing keys through an allowed-order-signer registry.

The settlement contract here is an upgradeable proxy (0xeEeEEe…756) that delegatecalls an implementation (0x88eb28…60d8). Neither contract's source is verified on Etherscan, so the canonical artifact is the on-chain bytecode and the transaction trace; the PoC reconstructs the bug by replaying the attacker's genuine calldata and signatures.

From the live trace, the fill path also performs Chainlink price sanity checks — it reads decimals() on each asset and latestRoundData() on the USDC/USD and ETH/USD feeds (output.txt:139-152). These pass for legitimately-priced assets and provide no protection against the authorization bug: the assets being moved are real, the only thing forged is who authorized moving them.

The vulnerable code#

The implementation at 0x88eb28009351Fb414A5746F5d8CA91cdc02760d8 is UNVERIFIED — fetch_sources.sh 1 0x88eb…60d8 returns UNVERIFIED, as do the proxy and the victim resolver. The behavior below is reconstructed from the exact on-chain trace in output.txt and the decoded calldata in the PoC (test/TrustedVolumes_exp.sol). Equivalent vulnerable pseudocode:

Bug #1 — registerAllowedOrderSigner has no access control#

// selector 0xea7faa61  —  cast 4byte 0xea7faa61 => registerAllowedOrderSigner(address,bool)
function registerAllowedOrderSigner(address signer, bool allowed) external {
    // ⚠️ NO onlyOwner / NO maker check — anyone can register any signer for THEMSELVES
    _allowedOrderSigner[msg.sender][signer] = allowed;
    emit AllowedOrderSignerRegistered(msg.sender, signer, allowed);
}

In the trace this single call writes exactly one storage slot under the implementation's storage in the proxy (output.txt:127-132):

RFQ_Proxy::registerAllowedOrderSigner(0xC3EB…9100, true)
  0x88eb28…60d8::registerAllowedOrderSigner(0xC3EB…9100, true) [delegatecall]
    storage changes:
      @ 0x97aea019…062e: 0 → 1      // _allowedOrderSigner[taker][attackerEOA] = true

Bug #2 — the fill checks authorization against order.taker, then pulls from order.maker#

The order is ABI-encoded as a flat tuple (decoded from the PoC calldata, test/TrustedVolumes_exp.sol:89-93):

order = [takerAsset, makerAsset, takerAmount, makerAmount, taker, maker, expiry, nonce, v, r, s, sigType]

// selector 0x4112e1c2
function fill(Order calldata order) external {
    bytes32 orderHash = _hashOrder(order);
    address signer = ecrecover(orderHash, order.v, order.r, order.s);

    // ⚠️ WRONG KEY: authorization is looked up under order.taker (attacker-controlled),
    //     NOT under order.maker (the party whose funds will move).
    require(_allowedOrderSigner[order.taker][signer], "bad signer");

    // ... Chainlink price sanity checks on makerAsset / takerAsset ...

    // maker's standing approval is used to move makerAsset OUT of the maker:
    IERC20(order.makerAsset).transferFrom(order.maker, order.taker, order.makerAmount); // ⚠️ drain
    IERC20(order.takerAsset).transferFrom(order.taker, order.maker, order.takerAmount); // 1 wei dust
    emit OrderFilled(signer, orderHash, order.taker, order.nonce);
}

The trace shows the recovered signer is the attacker EOA, and the maker is drained while the taker pays 1 wei back (output.txt:137-167):

ecrecover(0xc7a773cf…4305, 27, …) => 0xC3EBDdEa…0389100      // attacker EOA, authorized via Bug #1
WETH::transferFrom(VictimResolver 0x9ba0…, AttackContract 0xd4d5…, 1291161105215879179270)  // 1291.16 WETH OUT of maker
USDC::transferFrom(AttackContract 0xd4d5…, VictimResolver 0x9ba0…, 1)                         // 1 wei dust IN to maker

Root cause — why it was possible#

The settlement contract conflates "who is allowed to authorize this order" with "whose funds the order moves." In a correct RFQ design, the maker owns the assets (its approval is consumed) and therefore the maker must authorize the order — directly, or through a signer the maker has explicitly delegated. This contract instead:

1. Authorizes against order.taker. taker is an arbitrary, attacker-supplied field. By checking _allowedOrderSigner[order.taker][signer], the contract lets the taker decide which signatures are valid for an order that drains the maker. The maker's consent is never required.

2. Lets anyone populate that registry. registerAllowedOrderSigner has no access control, so the attacker registers their own EOA as an allowed signer for the taker key they control. There is nothing to break in — the gate opens for free.

3. Relies on a standing unlimited approval. The victim resolver had granted the proxy type(uint256).max approval on all four assets (the trace confirms WETH allowance = 1.157e77 ≈ uint256.max, output.txt:66-68). So once an order passes auth, the entire balance is reachable in a single transferFrom.

Chained: (2) gives the attacker a valid signer, (1) makes the attacker-controlled taker field the authorization root, and (3) makes the payout the full balance. The Chainlink price checks are irrelevant — they validate that the price of an order is sane, not that the fund owner approved it. The attacker even pays a token-correct 1 wei takerAmount, so any "non-zero consideration" check is satisfied.

This is the textbook authorization-on-the-wrong-party bug: the signature is verified correctly, but the access-control predicate is keyed to a field the attacker fully controls.

Preconditions#

• The victim resolver (maker) holds the assets and has a standing approval (here unlimited) to the proxy. ✓ (trace: WETH allowance ≈ uint256.max).
• The attacker can deploy a contract to act as order.taker (so the on-chain order signatures, which commit to taker = that address, verify). The PoC vm.startPrank(TAKER) to be that address.
• The attacker can call registerAllowedOrderSigner from the taker address — always true (no access control).
• The attacker can pay the dust takerAmount (4 wei USDC total across the 4 orders). The PoC deal(USDC, TAKER, 4) (test/TrustedVolumes_exp.sol:138).
• Orders are within their expiry (decoded 0x69fbe148 = 2026-05-07 00:48:08 UTC, just after the block timestamp) and use fresh nonces (1..4).

No flash loan, no price manipulation, and no privileged role are required.

Attack walkthrough (with on-chain numbers from the trace)#

The whole exploit is the attack contract (the order taker) doing one registration and four fills. All figures are pulled directly from the Transfer events and transferFrom calls in output.txt.

Each fill emits the same shaped event: topic0 = 0x908e04b7…cc8a, topic1 = attacker EOA, topic2 = order hash, data = (taker, nonce). For order #4, makerAsset == takerAsset == USDC, so the victim sends 1,268,771.488879 USDC out and receives 1 wei back — net loss 1,268,771.488878 USDC.

Victim resolver balances — before vs. after (from the trace)#

(Before/after values: output.txt:11-14 and the final maker balanceOf calls, e.g. WETH after = 13042031365816961407 wei.)

Profit / loss accounting#

The attacker's only outlay was 4 wei of USDC. Everything received was the victim resolver's genuine inventory.

Diagrams#

Sequence of the attack#

Authorization-decision flow (where the wrong key is used)#

Victim balance evolution across the 4 fills#

Remediation#

1. Authorize against the fund-owning party, not the taker. The signature check must be keyed on order.maker (the address whose approval is consumed): require(signer == order.maker || _allowedOrderSigner[order.maker][signer]). An order that moves the maker's funds must be authorized by the maker.
2. Add access control to registerAllowedOrderSigner. Only the maker itself (msg.sender == maker is already the registry key, which is fine) — but the combination with Bug #2 is what's fatal. Once authorization is keyed on the maker (fix #1), self-registration becomes harmless because the attacker cannot register a signer for the victim maker. Optionally restrict registration to an allow-listed set of resolvers.
3. Bind the order hash to the maker and chain. Use EIP-712 with the maker, both assets, both amounts, taker, expiry, nonce, chainId, and the verifying contract in the struct hash, and verify the recovered signer is authorized by the maker.
4. Drop unlimited approvals; pull exact amounts per settlement. Resolvers should approve only what a settlement needs, or use a per-order permit, so a single bad authorization cannot reach the entire balance.
5. Publish and verify the implementation source. Unverified settlement bytecode holding unlimited approvals from multiple resolvers is an unauditable, high-value target.

How to reproduce#

_shared/run_poc.sh 2026-05-TrustedVolumes_exp -vvvvv

• RPC: an Ethereum archive endpoint is required for fork block 25,039,669. The bundled Infura key in foundry.toml returned HTTP 401 (invalid project id); this project was switched to mainnet = "https://eth.drpc.org", which serves historical state at that block. (Most pruned public RPCs fail with header not found / missing trie node.)
• Result: [PASS] testExploit() — the victim resolver is drained of WETH/USDT/WBTC/USDC and the attack contract receives exactly the expected amounts (assertEq on each).

Expected tail:

[Bug #2] Attacker-signed orders accepted; victim maker drained.
Stolen by attack contract:
  WETH: 1291161105215879179270
  USDT: 206282446876
  WBTC: 1693910519
  USDC: 1268771488879

Approx USD value (round figures): ~$5.87M

Exploit reproduced: unlimited maker approval + permissionless signer + wrong-key auth = full drain.

Ran 1 test for test/TrustedVolumes_exp.sol:TrustedVolumesExploit
[PASS] testExploit() (gas: 767838)
Suite result: ok. 1 passed; 0 failed; 0 skipped

Note on sources: the RFQ proxy, its implementation, and the victim resolver are all UNVERIFIED on Etherscan (fetch_sources.sh returned UNVERIFIED for all three), so this PoC reproduces the exploit by replaying the attacker's exact on-chain calldata and ECDSA signatures rather than re-deriving them from source. The vulnerable-code section above is reconstructed from the decoded calldata and the live execution trace in output.txt.

Reference: rekt.news — https://rekt.news/trustedvolumes-rekt (TrustedVolumes, Ethereum, ~$5.87M).

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2026-05-TrustedVolumes_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: TrustedVolumes_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• DeFiHackLabs incident explorer: search "TrustedVolumes Exploit".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.