# Users can exploit the batch minting feature to avoid paying minting fees for tokens

Edition.mintBatch charges mint fee on amount_ once but mints amount_ per receiver, letting minters pay for one token and receive many.

- Payout: Contest reward
- Severity: high
- Program: Titles
- Credited: 0x486776
- Disclosed: 2024-04-17
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-04-titles-judging/issues/264
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-04-titles%3AH-1
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:business-logic vuln:fee-bypass

**Target:** Edition.sol mintBatch batch minting function
**Root cause:** collectMintFee is called with amount_ only, while the loop issues amount_ tokens to each of receivers_.length addresses, so fee scales with amount_ but minted supply scales with amount_ * receivers_.length.
**Steps:**
1. Call `mintBatch(receivers_, tokenId_, amount_, data_)` with `receivers_` = array of 1000 copies of attacker address and `amount_` = 1.
2. collectMintFee computes fee for amount_=1 (e.g. 0.001 ETH) instead of 1000 tokens.
3. Loop `_issue(receivers_[i], tokenId_, amount_, data_)` mints 1 token to each of 1000 receivers.
4. Attacker receives 1000 tokens while paying fee for 1; excess refunded via `_refundExcess()`.
**How found:** Code reading of mintBatch: noticed collectMintFee uses amount_ while the issuance loop multiplies by receivers_.length, a fee-accounting mismatch.
**Exploitation:** Attacker submits a single mintBatch transaction with a large receivers_ array of their own addresses and amount_=1, paying msg.value for one token's fee while receiving receivers_.length tokens, avoiding fees owed to creator and fee recipients.
**Insight:** In batch functions, check that fee/accounting parameters scale with the same multiplier as the state-changing loop; a single amount_ argument reused per-receiver is a classic undercharge.