# Burning a User's Tokens for a Flash Proposal will not Deduct Their Balance

Behodler's burnFlashGovernanceAsset overwrites user state with config instead of deleting it, so burned tokens aren't deducted and unlock time passes immediately.

- Payout: Audit contest
- Severity: medium
- Program: Behodler
- Found by: kirk-baird
- Disclosed: 2022-03-24
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-01-behodler-findings/issues/157
- Library page: https://bugbountylibrary.com/r/c4%3A2022-01-behodler%3AM-03
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic vuln:governance

**Target:** FlashGovernanceArbiter governance contract
**Root cause:** burnFlashGovernanceAsset resets pendingFlashDecision to flashGovernanceConfig instead of deleting it, so amount reverts to the original deposit and unlockTime becomes a duration (e.g. 7 days) rather than now+duration, always satisfying the withdraw timestamp check.
**Steps:**
1. User calls assertGovernanceApproved() transferring `amount` tokens, storing pendingFlashDecision with amount and unlockTime.
2. A successful flash proposal calls BurnFlashStakeDeposit.execute() -> burnFlashGovernanceAsset(targetContract, user, asset, amount).
3. burnFlashGovernanceAsset calls Burnable(asset).burn(amount) but then sets `pendingFlashDecision[targetContract][user] = flashGovernanceConfig`.
4. User calls withdrawGovernanceAsset(); check `unlockTime < block.timestamp` passes since unlockTime is a small duration, and full original amount is returned.
**How found:** Code reading of burnFlashGovernanceAsset and BurnFlashStakeDeposit.execute, noticing the state overwrite with config rather than deletion, and that unlockTime stores a duration not a timestamp.
**Exploitation:** Attacker submits a flash governance proposal to burn their own staked tokens; the burn executes but state is reset to config, so the attacker withdraws the full original amount immediately, retaining funds while the burn is recorded.
**Insight:** When a function 'resets' state to a config struct, check whether config fields are durations vs absolute timestamps and whether the reset restores the pre-penalty amount; a burn that resets to config can refund the user.
