# A Malicious Treasury Manager Can Burn Treasury Tokens By Setting makerFee To The Amount The Maker Receives

Notional's EIP1271Wallet._validateOrder omits makerFee/takerFee checks, letting a malicious treasury manager set makerFee equal to maker proceeds, burning treasury tokens for free.

- Payout: Audit contest
- Severity: high
- Program: Notional
- Found by: leastwood
- Disclosed: 2022-03-10
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2022-01-notional-findings/issues/230
- Library page: https://bugbountylibrary.com/r/c4%3A2022-01-notional%3AH-03
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** EIP1271Wallet 0x order validation (TreasuryManager)
**Root cause:** _validateOrder checks feeRecipient, tokens, oracle price and slippage but never requires makerFee and takerFee to be zero, so a signed 0x order can route the maker's proceeds to fees.
**Steps:**
1. Treasury manager signs a 0x order via EIP1271Wallet where makerToken is a treasury asset and takerToken is WETH
2. Set makerFee to the full makerAmount so the maker receives zero tokens while fees absorb the proceeds
3. Keep makerPrice (takerAmount/makerAmount) above the oracle priceFloor so the slippage check passes
4. Order fills on 0x; treasury manager receives nothing, taker gets tokens at no cost
**How found:** Code review of EIP1271Wallet._validateOrder against 0x MixinExchangeCore/LibFillResults fee accounting; noticed fee fields were never constrained while other order fields were.
**Exploitation:** A malicious/compromised treasury manager crafts and signs an off-chain 0x order through EIP1271Wallet with makerFee set to the maker's received amount; the order passes _validateOrder's slippage check and fills, transferring treasury tokens to the taker while the treasury receives zero.
**Insight:** When a contract validates externally-signed exchange orders, enumerate every order struct field the exchange's fill math consumes (fees, feeRecipient, taker/maker amounts) and require the ones that divert value to be zero or bounded.