# Burning a ERC1155Enumerable token doesn't remove it from the enumeration 

ERC1155Enumerable checks supply==0 before decrementing on burn, so burned token ids stay enumerated, corrupting totalSupply/tokenByIndex and duplicating entries on re-mint.

- Payout: Contest reward
- Severity: medium
- Program: Timeswap
- Credited: adriro
- Disclosed: 2023-03-10
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-01-timeswap-findings/issues/248
- Library page: https://bugbountylibrary.com/r/c4%3A2023-01-timeswap%3AM-02
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error

**Target:** ERC1155Enumerable base contract (TimeswapV2Token/TimeswapV2LiquidityToken)
**Root cause:** In _removeTokenEnumeration the _idTotalSupply[id]==0 check runs before subtracting the burned amount, so the removal branch is never taken when the last tokens are burned.
**Steps:**
1. Deploy ERC1155Enumerable-derived token; mint id 0 amount 1 to Alice.
2. Call burn(alice, 0, 1) -> _afterTokenTransfer -> _removeTokenEnumeration with to==address(0).
3. Observe _idTotalSupply[0]==1 at check time, so _removeTokenFromAllTokensEnumeration is skipped, then supply decremented to 0.
4. Assert tokenByIndex(0)==0 and totalSupply()==1 despite zero supply.
5. Mint id 0 again -> token re-added, totalSupply()==2 and tokenByIndex(0)==tokenByIndex(1)==0.
**How found:** Code review of the _afterTokenTransfer/_removeTokenEnumeration hook ordering, noticing the supply-zero check precedes the decrement.
**Insight:** In ERC1155/ERC721 enumerable extensions, verify the order of supply/balance mutation versus zero-checks in transfer hooks; off-by-one ordering leaves stale enumeration entries that duplicate on re-mint.