# _currentIndex is incorrectly updated; breaking the ERC1155 enumerable implementation

Timeswap ERC1155Enumerable updates _currentIndex and _allTokensIndex in wrong order, so totalSupply and enumeration never decrease after burns.

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

**Target:** ERC1155Enumerable.sol token enumeration logic
**Root cause:** In _removeTokenEnumeration the _idTotalSupply check runs before decrementing, and _addTokenToOwnerEnumeration/_removeTokenFromOwnerEnumeration update _currentIndex in the wrong order, so indices never shrink.
**Steps:**
1. Deploy HelperERC1155 exposing _currentIndex, _allTokensIndex, _allTokens
2. Mint ids 0..9 with amounts 1..10
3. Burn each id fully
4. Observe idTotalSupply==0 but allTokensIndex(i)==i, totalSupply()==10, currentIndex==10 instead of 0
**How found:** Code review of the enumeration bookkeeping: noticed the zero-supply check precedes the supply decrement and that _currentIndex is incremented before being read as the index, then wrote a forge test asserting post-burn state.
**Insight:** In ERC721/1155 enumerable ports, verify the ordering of supply decrement vs. the ==0 removal check and whether the index is read before or after increment/decrement; a post-burn assertion on totalSupply and per-owner index catches these off-by-order bugs.