# ERC-4337 counterfactual wallet takeover occurs when factory CREATE2 salt does not depend on the initial owner credentials allowing attacker pre-deployment ERC-4337 enables "counterfactual" wallets: accounts at a deterministic address before on-chain deployment, with the address derived via CREATE2 from the factory address, salt, and initialization code. The vulnerability arises when the salt does not incorporate the intended owner's credentials. If the salt depends only on public values (a counter, user ID, or non-secret nonce), an attacker can observe the target address, compute the salt, and deploy their own contract at that address first with different owner credentials. A Code4rena/Biconomy audit finding of high severity demonstrated this scenario. Two invariants factories must satisfy: 1. **Salt depends on owner credentials**: The CREATE2 salt must derive from the owner's signature or public key, making it infeasible to predict without the private key 2. **Idempotency**: If the wallet is already deployed, `createWallet()` must return the existing address rather than reverting, preventing griefing by failed deployments Since [[CREATE2 enables contract recreation at the same address with different bytecode when the constructor queries external state]], additional scenarios exist where deployment determinism can be subverted. --- Relevant Notes: - [[CREATE2 enables contract recreation at the same address with different bytecode when the constructor queries external state]]: the broader CREATE2 determinism properties that factory security depends on - [[ERC-4337 EntryPoint singleton concentrates unconditional trust creating a single point of failure across the entire account abstraction ecosystem]]: the trust model that makes factory security critical to the whole AA ecosystem - [[openzeppelin initializable with initializer modifier prevents re-initialization attacks on proxy contracts]]: the analogous front-running risk in proxy initialization that this shares structural similarity with - [[non-atomic proxy deployment creates a front-running window where any actor can write to the ERC1967 implementation storage slot before the legitimate initialization transaction confirms]]: the structural analog in proxy deployment: same pre-deployment window exploitation pattern, different target (proxy slot vs factory address) - [[atomic proxy deployment by passing initialization data to the ERC1967Proxy constructor eliminates the CPIMP front-running window because deployment and initialization occur within a single transaction]]: the proxy-specific solution: combining deployment and initialization in one transaction, parallel to requiring salt-to-owner binding in AA factories Topics: - [[vulnerability-patterns]] - [[protocol-mechanics]]