🚨 @TrustedVolumes - Loss $5.87M (2026-05-07) Type: Signature/Execution Parameter Mismatch The TrustedVolumes RFQ proxy has a critically broken fill function. The EIP-712 signature commits to (makerToken, takerToken, makerAmount, takerAmount, maker, counterparty, expiry, salt), and the contract checks `_allowedOrderSigner[signedMaker][recoveredSigner]`. But the function also takes unsigned calldata that does the actual transfer - including the real `from` address, real token, and real amounts. Nothing binds the executed `from` to the signed `maker`. The permissionless `registerAllowedOrderSigner(signer, allowed)` is benign on its own - it's keyed on msg.sender, so anyone can only self-authorize signers under buckets they control (their own EOAs/contracts), not under the victim Resolver's bucket. What turns it into an exploit is the unsigned `from`: the attacker registers themselves under a maker they do control (their exploit contract), signs an order with `maker = exploitContract` (passing the per-maker auth check), then in the unsigned params sets `from = TrustedVolumes Resolver`, which had infinite ERC20 allowances to the proxy. The price-loss oracle check uses only the signed amounts so a 1:1 dummy order trivially passes. TX: etherscan.io/tx/0xc5c61b3ac3… Victim: etherscan.io/address/0x9bA0C… Router: etherscan.io/address/0xeeeee…