# Approved gscApprove allowance to an address may not able to be decreased

ArcadeTreasury.gscApprove decrements internal gscAllowance by the full new amount, so re-approving a lower allowance to the same spender underflows and reverts.

- Payout: Audit contest
- Severity: medium
- Program: Arcade.xyz
- Found by: Juntao
- Disclosed: 2023-10-25
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2023-07-arcade#m-08
- Library page: https://bugbountylibrary.com/r/c4%3A2023-07-arcade%3AM-08
- Tags: area:web3 domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity vuln:accounting-error

**Target:** ArcadeTreasury treasury contract (Solidity)
**Root cause:** gscApprove subtracts the entire new amount from gscAllowance[token] instead of the delta versus the spender's current allowance, so a second approval for a smaller amount underflows when remaining gscAllowance is below the new amount.
**Steps:**
1. Set gscAllowance[token] = 100 via setGSCAllowance.
2. As GSC_CORE_VOTING_ROLE call `gscApprove(token, spender, 60 ether)`; gscAllowance becomes 40.
3. Call `gscApprove(token, spender, 50 ether)` to lower the allowance; transaction reverts with arithmetic underflow since 40 < 50.
**How found:** Reading gscApprove's accounting: the comment 'Will underflow if amount is greater than remaining allowance' plus the unconditional `gscAllowance[token] -= amount` suggested the internal allowance tracks cumulative approvals rather than per-spender allowance, so re-approval cannot reduce it.
**Insight:** When a contract mirrors ERC20 allowances in internal accounting, check whether re-approval subtracts the new amount or the delta from the previous allowance; the latter is required to support decreasing an allowance.