# Griefing/DOS of withdrawals by EOAs from treasury (TRSRY) possible

TreasuryCustodian.revokePolicyApprovals() treats EOA calls to isActive() as false, letting anyone zero out an EOA's approved treasury withdrawal amounts, griefing withdrawals.

- Payout: Contest reward
- Severity: medium
- Program: Olympus DAO
- Credited: minhtrng
- Disclosed: 2022-10-26
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-08-olympus-findings/issues/317
- Library page: https://bugbountylibrary.com/r/c4%3A2022-08-olympus%3AM-12
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic vuln:dos

**Target:** TreasuryCustodian.revokePolicyApprovals() in Olympus treasury policy contract
**Root cause:** revokePolicyApprovals() only checks isActive() on the passed address; calling it on an EOA returns 0/false without reverting, so the revert condition is not met and approved withdrawal amounts are set to 0.
**Steps:**
1. Identify an approved EOA with a nonzero treasury withdrawal approval.
2. Watch mempool for the EOA's withdrawal transaction.
3. Call `TreasuryCustodian.revokePolicyApprovals(eoa)` before it lands; `isActive()` on the EOA returns false (0) without reverting.
4. Approval amount is set to 0, causing the victim's withdrawal to revert.
**How found:** Code review of revokePolicyApprovals() noting the only guard is an isActive() call that silently returns false for EOAs, plus team TODO comments acknowledging the missing check.
**Exploitation:** Front-run a pending EOA withdrawal from the treasury by calling revokePolicyApprovals() on that EOA, zeroing its approval and causing the withdrawal to fail (griefing/DOS).
**Insight:** When a guard calls a function on an arbitrary address expecting a revert for non-contracts, remember low-level/interface calls to EOAs return empty data (0/false) rather than reverting—so 'isActive' style checks can be bypassed by passing an EOA.
