# DOS by Frontrunning NoteERC20 initialize() Function

NoteERC20 proxy deployed and initialized in separate transactions, letting an attacker front-run initialize() to seize ownership and repeatedly DoS deployment.

- Payout: Audit contest
- Severity: high
- Program: Notional
- Found by: leastwood
- Disclosed: 2021-10-01
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-08-notional-findings/issues/7
- Library page: https://bugbountylibrary.com/r/c4%3A2021-08-notional%3AH-08
- Tags: area:web3 domain:web3 impact:dos impact:privesc kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:race-window technique:source-review vuln:access-control vuln:dos

**Target:** ERC1967 upgradeable proxy / NoteERC20 initialize()
**Root cause:** Deployment script deploys the NoteERC20 proxy and calls initialize() in separate transactions instead of atomically, leaving the uninitialized proxy open to anyone calling initialize() first.
**Steps:**
1. Monitor Ethereum mempool/chain for bytecode matching the NoteERC20 implementation/proxy deployment.
2. Observe proxy deployed but initialize() not yet mined.
3. Front-run by calling `initialize()` on the proxy from attacker address, becoming owner.
4. Repeat on each redeploy attempt to block Notional's deployment and burn gas.
**How found:** Reviewed scripts/deployment.py and deploy_governance.py, noticed proxy deployment and initialize() were not in the same transaction, and reasoned about mempool front-running of the uninitialized proxy.
**Exploitation:** Attacker watches for the NoteERC20 proxy deployment, then submits initialize() with higher gas to take ownership before the legitimate deployer's initialize() lands; repeating this on every redeploy attempt denies deployment and wastes gas.
**Insight:** Audit deployment scripts, not just contracts: any proxy whose initialize() is a separate tx from deployment is front-runnable; check for atomic deploy+init or deployer-gated initializer.