# If a MIMOProxy owner destroys their proxy, they cannot deploy another from the same address

MIMOProxyRegistry blocks redeployment when a stale destroyed proxy address remains in _currentProxies, locking the owner out of creating a new proxy from the same EOA.

- Payout: Contest reward
- Severity: medium
- Program: Mimo DeFi
- Credited: horsefacts
- Disclosed: 2022-10-17
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-08-mimo-findings/issues/162
- Library page: https://bugbountylibrary.com/r/c4%3A2022-08-mimo%3AM-08
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** MIMOProxyRegistry / MIMOProxyFactory proxy deployment
**Root cause:** deployFor checks currentProxy.owner() on a stale mapping entry; if the proxy was selfdestructed, the static call reverts, blocking redeployment.
**Steps:**
1. Deploy MIMOProxyRegistry and call deploy() to create a proxy for owner.
2. Have the proxy delegatecall a helper with matching storage layout exposing `selfDestruct()` (selector `0x9cb8a26a`) that calls `selfdestruct`.
3. Proxy is destroyed; `proxy.owner()` now reverts.
4. Call `mimoProxyRegistry.deploy()` again from same owner; reverts because `currentProxy.owner()` static call fails on zero-codesize address.
**How found:** Code review of deployFor's existence check: noticed it calls owner() on the stored proxy without verifying the address still has code, so a selfdestructed proxy would revert the check.
**Exploitation:** Owner (or anyone with delegatecall permission) triggers selfdestruct via a delegatecall target; the stale _currentProxies entry then permanently blocks redeployment from that EOA.
**Insight:** When a registry caches contract addresses, existence checks that call methods on the cached address break after selfdestruct; check code.length before invoking methods on stored addresses.