# If DAO updates forkEscrow before forkThreshold is reached, the user's escrowed Nouns will be lost

If a DAO proposal swaps forkEscrow during the escrow period, users' escrowed Nouns become stuck because withdrawFromForkEscrow calls the new escrow contract.

- Payout: Contest reward
- Severity: medium
- Program: Nouns DAO
- Credited: cccz
- Disclosed: 2023-07-31
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-07-nounsdao-findings/issues/56
- Library page: https://bugbountylibrary.com/r/c4%3A2023-07-nounsdao%3AM-02
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** NounsDAOV3Fork / NounsDAOForkEscrow governance contracts
**Root cause:** withdrawFromForkEscrow reads ds.forkEscrow at withdrawal time, but escrowed tokens live in the old escrow contract; returnTokensToOwner is onlyDAO so users cannot withdraw directly from the stale contract.
**Steps:**
1. User escrows Nouns into forkEscrow during escrow period
2. A proposal executes calling _setForkEscrow to a new address
3. User calls withdrawFromForkEscrow; it invokes the new forkEscrow.returnTokensToOwner
4. New escrow has no record of the tokens; old escrow still holds them and onlyDAO blocks direct withdrawal
**How found:** Code reading of withdrawFromForkEscrow and returnTokensToOwner, noticing the escrow address is read dynamically while tokens are held by the prior contract and withdrawal is DAO-gated.
**Exploitation:** Governance proposal changes forkEscrow while tokens are escrowed; affected users permanently lose access to their escrowed Nouns since only the DAO can call returnTokensToOwner on the old contract.
**Insight:** When a contract stores a mutable pointer to a token-holding contract, check whether user-facing withdrawal paths resolve that pointer at call time versus where the assets actually reside; admin-settable pointers plus onlyDAO withdrawal create stranded-asset bugs.