Why Most Smart Account Upgradability Designs Are Inherently Flawed

Most designs rely on a single admin key or multi-sig, creating a centralized failure point and violating the self-custody promise. This is a regression to web2 infrastructure.

• Single Point of Failure: A compromised admin key can upgrade all user accounts.
• Governance Paralysis: DAO-based upgrades are too slow for critical security patches.
• Vendor Lock-in: Users are trapped by the upgrade authority's policies and availability.

Fixing flaws in core account logic (like signature validation) requires a full migration, which is a UX nightmare and often results in abandoned, vulnerable wallets.

• Migration Friction: Users must manually move funds, a process with >30% drop-off.
• Fragmented State: Social recovery settings, session keys, and allowances don't transfer.
• Protocol Risk: DApps integrate with specific account addresses; a new address breaks everything.

Using EIP-2535 (Diamonds) for modular upgrades introduces severe complexity and opaque security audits, making accounts less secure, not more.

• Un-auditable Complexity: A diamond's full logic is a dynamic mapping, not a single contract.
• Storage Collision Risks: Improperly managed facets can corrupt user data.
• Gas Inefficiency: Every external call adds overhead, making simple actions ~40k gas more expensive.

The correct model is a decentralized network of upgrade signers where the user is the ultimate authority, not a protocol admin. Think ERC-4337 bundler networks for account management.

• User Consent: Every upgrade requires a signature from the user's current key.
• Fallback Guardians: A decentralized set of entities (like Safe{Wallet}'s ecosystem) can propose critical fixes.
• Graceful Migration: New logic is attached as a module; the old address and state persist.

The account's core verification logic must be immutable for security. All upgrades happen via EIP-2535 Diamond-like modules that are added, not replaced, with strict, user-controlled permissions.

• Verification Immutability: The validateUserOp function cannot be changed, preventing hijacks.
• Module Marketplace: Users opt into new features (e.g., Biconomy's session keys, ZeroDev's passkeys) as attached modules.
• Clear Audit Trails: Each module has a standalone, verifiable security audit.

The most secure upgrade path is through the account's own recovery mechanism. Changing logic requires the same consensus as changing ownership.

• Inherits Security: Leverages the battle-tested security of social recovery (e.g., Safe{Wallet}, Argent).
• No New Trust Assumptions: The same guardians that protect your assets approve upgrades.
• Universal Standard: Works for any account type, creating a unified upgrade UX across ERC-4337, Safe, and others.

Modular but creates a monolithic, centralized upgrade key. The admin key is a single point of failure that compromises the entire account's security model.

• Facet Logic: Enables hot-swapping of account modules.
• Centralized Risk: Admin key controls all upgrades, creating a $10B+ TVL honeypot for social engineering.
• Audit Nightmare: Every upgrade requires re-auditing the entire diamond, not just the new facet.

Delegates security to a social graph, trading cryptographic certainty for human reliability. This introduces coordination latency and social attack surfaces.

• Recovery Delay: Guardian consensus can take days, freezing funds during an emergency.
• Sybil Vulnerability: Guardians are often friends or centralized services, not cryptographically secure entities.
• Meta-Dependency: Shifts trust from code to off-chain social processes, the very problem crypto aims to solve.

Adds a delay to malicious upgrades but fails against sophisticated attackers. It's a theatrical security measure that users ignore and attackers bypass.

• False Sense of Security: Users rarely monitor pending upgrades, making the timelock ineffective.
• Bypass via Social Engineering: Attackers combine timelock proposals with phishing to gain legitimacy.
• UX Friction: Legitimate upgrades are slowed, punishing honest developers and users.

Standardizes module interfaces but inherits the proxy's centralization risk. The root validator or default handler becomes the new privileged singleton.

• Standardized Compromise: While interoperable, the architecture still requires a privileged entry point to authorize module execution.
• Complexity Explosion: Each new module expands the audit surface area multiplicatively.
• Bottlenecked Innovation: The root contract becomes a governance bottleneck, slowing protocol evolution.

Replaces a single admin key with a committee, trading one central point for N central points. This increases coordination overhead without eliminating trust.

• Collusion Risk: M-of-N signers can still collude, a proven failure mode in DAOs like The DAO hack.
• Governance Paralysis: Legitimate upgrades get stuck in political deadlock.
• Key Management Hell: Now you have N sensitive private keys to manage and secure, not one.

The only viable path forward. An immutable account core with cryptographically permissioned plugin slots. Upgrades are module installations, not logic replacement.

• No Upgrade Key: The core logic is immutable; security is invariant.
• Plugin Sandboxing: Modules run in isolated environments with strict capability boundaries.
• User-Centric Auth: Users cryptographically sign to install new plugins, making each upgrade a user-initiated transaction, not an admin privilege.