# Wrong handling of ERC20 denoms in ERC20Keeper::BurnCoins

ERC20Keeper.BurnCoins passed the entire coin set to FundCommunityPool instead of the single ERC20 coin, double-crediting the community pool on multi-denom burns.

- Payout: Contest reward
- Severity: high
- Program: Initia
- Credited: 0xAlix2
- Disclosed: 2025-04-10
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2025-02-initia-cosmos#h-01
- Library page: https://bugbountylibrary.com/r/c4%3A2025-02-initia-cosmos%3AH-01
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:high tech:evm technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Cosmos SDK ERC20Keeper BurnCoins in minievm/x/evm/keeper/erc20.go
**Root cause:** Inside the per-coin loop, the ERC20Denom branch calls FundCommunityPool with the full `amount` slice rather than the single `coin`, so every ERC20 denom in the set is funded on each iteration while the loop also proceeds to burn the non-ERC20 coins.
**Steps:**
1. Deploy two ERC20 contracts via ERC20Factory to get denoms `evm/<addr1>` and `evm/<addr2>`.
2. Mint 100 of each denom to a user via mintERC20.
3. Call `erc20Keeper.BurnCoins(ctx, addr, sdk.NewCoins(NewCoin(fooDenom_1,50), NewCoin(fooDenom_2,50)))`.
4. Observe community pool balance of each denom is 100 (50*2) instead of 50.
**How found:** Code reading of BurnCoins loop: noticed the ERC20Denom branch passes `amount` (whole set) to FundCommunityPool instead of `coin`, then wrote a two-denom test to confirm double funding.
**Exploitation:** Any account holding multiple ERC20 denoms can call burn with a multi-coin set; each ERC20 denom iteration funds the community pool with the whole set, inflating community pool balances relative to actual burned amounts and mis-accounting supply.
**Insight:** In Cosmos SDK keepers, per-coin loops that call bank/community-pool helpers must pass `sdk.NewCoins(coin)`, not the outer `amount` slice; grep for `FundCommunityPool(ctx, amount` patterns in multi-denom loops.