# StandardPolicyERC1155.sol returns amount == 1 instead of amount == order.amount

Blur's StandardPolicyERC1155 hardcodes amount=1, so buyers paying full price for ERC1155 orders with amount>1 receive only one token.

- Payout: Contest reward
- Severity: high
- Program: Blur Exchange
- Credited: dipp
- Disclosed: 2022-12-08
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-10-blur-findings/issues/666
- Library page: https://bugbountylibrary.com/r/c4%3A2022-10-blur%3AH-01
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** StandardPolicyERC1155 matching policy / BlurExchange.execute
**Root cause:** canMatchMakerAsk and canMatchMakerBid return a hardcoded amount of 1 instead of order.amount, and that value flows into _executeTokenTransfer.
**Steps:**
1. Mint 10 ERC1155 tokens of tokenId to alice
2. Create sell order with amount=10 and buy order with amount=10 using standardPolicyERC1155
3. Call exchange.execute(sellInput, buyInput)
4. Observe bob's ERC1155 balance is 1 while full price is paid
**How found:** Code review of the matching policy return values, noticing the literal 1 in the returned amount tuple and tracing it into _executeTokenTransfer.
**Exploitation:** A buyer matching an ERC1155 sell order with amount>1 pays the full order price but receives only 1 token; excess ETH/WETH goes to the seller.
**Insight:** When auditing order-matching policies, verify every returned field (especially amount) is derived from order parameters rather than hardcoded, and trace it into the transfer call.