# Mint limit is not reduced when the Vault is burning TAU

TAU burn decrements currentMinted[msg.sender] using currentMinted[account], so vaults burning on behalf of users never free mint limit.

- Payout: Contest reward
- Severity: medium
- Program: Taurus
- Credited: 8olidity
- Disclosed: 2023-02-08
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-03-taurus-judging/issues/149
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-03-taurus%3AM-2
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity vuln:accounting-error

**Target:** TAU ERC20 token contract, _decreaseCurrentMinted
**Root cause:** _decreaseCurrentMinted reads accountMinted = currentMinted[account] but writes currentMinted[msg.sender]; when a vault burns on behalf of a user, account != msg.sender so the vault's counter is decremented by 0.
**Steps:**
1. Vault calls burn on behalf of user, so account=user, msg.sender=vault
2. accountMinted = currentMinted[user] = 0
3. check accountMinted >= amount fails, currentMinted[vault] unchanged
4. Vault's mint limit never freed despite burning TAU
**How found:** Code reading of _decreaseCurrentMinted revealed the account vs msg.sender mismatch in the index used for read vs write.
**Insight:** In mint/burn accounting, verify the same address key is used for both the read and the write; delegated burns (account != msg.sender) silently no-op the limit decrement.