The Unseen Cost of 'Set and Forget' Smart Account Upgrades

Multi-sig upgrade mechanisms create a single, high-value attack surface. A compromised signer or a rushed governance vote can push a malicious upgrade to millions of accounts instantly. This centralizes failure, contradicting the decentralized ethos of the underlying L1.

• Attack Vector: Compromised admin key or governance exploit.
• Blast Radius: 100% of managed accounts are vulnerable in a single transaction.
• Historical Precedent: Proxy pattern exploits have led to $100M+ losses.

Fully immutable logic modules are secure but crippling. They prevent critical security patches and adaptation to new standards (e.g., quantum-resistant signatures). This forces a trade-off between security and longevity, a flaw not present in EOAs.

• Core Dilemma: Security vs. Future-Proofing.
• Consequence: Accounts become technically obsolete within a 3-5 year horizon.
• Mitigation Cost: Requires complex, risky migration to a new account factory.

Upgrades often don't migrate storage layouts cleanly. Incompatible state variables between logic versions can brick accounts or cause silent data corruption. This risk is amplified in complex accounts with nested modules and cross-chain state.

• Root Cause: Storage collision and layout incompatibility.
• Impact: User funds are locked or permanently lost.
• Testing Gap: Formal verification tools like Certora struggle with state migration paths.

The EntryPoint is a singleton, upgradeable contract that validates all UserOperations. A malicious upgrade here could censor transactions, drain wallets via modified validation, or brick the entire ecosystem. Its security is now a shared dependency for all 4337 accounts.

• Systemic Risk: A single contract failure breaks all ERC-4337 wallets.
• Attack Surface: ~$1B+ TVL reliant on one EntryPoint version.
• Mitigation: Requires slow, opt-in migration to a new EntryPoint, creating fragmentation.

Smart accounts compose functionality from third-party modules (recovery, session keys, yield). An upgrade to a core account can break downstream modules, and a malicious module upgrade can compromise the account. This creates a fragile web of transitive trust.

• Complexity Risk: N-dependencies increase attack vectors exponentially.
• Audit Surface: Each new module requires a full security re-audit of integration points.
• Real Example: A compromised social recovery module is a backdoor to the vault.

Adopt a minimal, immutable core wallet (like a hardened EOA) that delegates authority to ephemeral, sandboxed modules. Modules are non-upgradeable and can be revoked atomically by the core. This mirrors the security model of Cosmos SDK or Linux kernel modules.

• Core Principle: Least privilege and atomic revocation.
• Benefit: Limits blast radius of any module compromise to its specific permissions.
• Implementation: Use DELEGATECALL with strict storage isolation and time-bound sessions.

ERC-4337's EntryPoint and most smart account implementations centralize upgrade authority to a single admin key. This creates a $10B+ TVL honeypot for attackers and a catastrophic governance failure mode. The industry is repeating the Proxy Admin vulnerabilities seen in early DeFi, but at the wallet layer.

• Risk: A compromised admin key can rug all associated user accounts.
• Reality: Most teams treat this key as an ops afterthought, not a core security primitive.

Adding a 7-day timelock to upgrades (like Safe{Wallet}) only mitigates blatant theft, not sophisticated attacks. It fails against:

• Governance Capture: A malicious proposal that looks benign.
• User Apathy: The vast majority will not monitor or challenge upgrades.
• Emergency Paralysis: A genuine critical bug requires immediate action, which the timelock prevents. You're choosing between security theater and operational rigidity.

The solution is a modular security council modeled on mature L1/L2 governance (e.g., Arbitrum Security Council). Decouple the upgrade logic from a single key.

• Implementation: Use a multi-sig of trusted, pseudonymous entities or a decentralized committee.
• Progression: Allow for emergency fast-track votes and community vetoes.
• Ecosystem Examples: This is the implicit model behind zkSync's Boojum upgrade and Starknet's governance, applied at the account level.

You audited the initial smart account factory, but the upgrade mechanism introduces infinite new, unaudited code. This dynamic attack surface is why protocols like MakerDAO have dedicated spell review processes. For wallets, every upgrade is a new, high-value contract deployment that bypasses initial security checks.

• Blind Spot: Auditors rarely analyze the governance process for the upgrade key itself.
• Requirement: You need continuous audit streams, not a one-time report.

Mitigate trust in the upgrade multi-sig by requiring on-chain, verifiable proof of a legitimate decision. Anchor upgrades to a canonical record, similar to how optimistic rollups use fraud proofs or Polygon zkEVM uses validity proofs for state transitions.

• Method: Upgrade transaction must include a proof of a successful Snapshot vote or DAO execution.
• Benefit: Creates a cryptographically-verifiable audit trail that the upgrade was community-sanctioned, not a key leak.
• Framework: Look to Aztec's state transition proofs for inspiration on verifiable governance.

Rollup teams learned you cannot decentralize the sequencer (the operator) on day one. The same applies to smart account upgrade keys. Start with a pragmatic, transparent multi-sig controlled by founding entities, but encode a sunset clause and migration path to more decentralized governance (e.g., token vote) in the contract itself. Optimism's Bedrock upgrade and Arbitrum Nitro followed this playbook for core tech; apply it to account security.