# TRSRY: front-runnable setApprovalFor

TRSRY.setApprovalFor overwrites allowances, letting a withdrawer front-run an allowance reduction and spend both the old and new amounts.

- Payout: Contest reward
- Severity: high
- Program: Olympus DAO
- Credited: zzzitron
- Disclosed: 2022-10-26
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-08-olympus-findings/issues/410
- Library page: https://bugbountylibrary.com/r/c4%3A2022-08-olympus%3AH-03
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:business-logic vuln:race-condition

**Target:** TRSRY treasury module / TreasuryCustodian grantApproval
**Root cause:** setApprovalFor assigns the new amount directly instead of adjusting the existing allowance, so a pending reduction can be front-run and the old allowance spent before the new one is set.
**Steps:**
1. Alice holds withdrawApproval of 100 for a token.
2. Custodian submits grantApproval/setApprovalFor reducing allowance to 50.
3. Alice front-runs the tx and withdraws the full 100 under the old approval.
4. After the reduction tx lands, Alice withdraws another 50 under the new approval.
5. Total withdrawn: 150 vs intended 50.
**How found:** Code reading of TRSRY.setApprovalFor and TreasuryCustodian.grantApproval noting the assignment overwrites rather than decrements, combined with mempool front-running reasoning.
**Exploitation:** Attacker with withdrawer role watches the mempool for a setApprovalFor reduction, front-runs it to drain the prior allowance, then drains the reduced allowance afterward, extracting up to the sum of both.
**Insight:** When auditing allowance/approval setters, check whether they assign absolute values vs adjust deltas; any absolute set of a permissioned allowance is front-runnable to spend both old and new values.