The Hidden Cost of Smart Account Upgradability

Most ERC-4337 accounts use a single, immutable logic contract proxy. This creates a single point of failure for millions of accounts. A critical bug in the singleton logic contract is catastrophic, not isolated.\n- Risk: A single exploit can drain $10B+ TVL across all dependent accounts.\n- Cost: Forces ultra-conservative, slow upgrades, negating the agility promise of account abstraction.

Upgrade governance is often centralized with the account provider (e.g., Safe{DAO}, ZeroDev). Users outsource security decisions, creating meta-transaction risk. A malicious or compromised upgrade can be pushed to all users.\n- Risk: Governance attacks or insider threats become existential.\n- Cost: Users bear the audit and monitoring burden, or blindly trust a multisig of ~5-9 entities they don't control.

ERC-4337's EntryPoint is designed to be immutable for security. However, this locks the entire ecosystem into v0.6/0.7. Any protocol-level upgrade (e.g., new opcode, signature scheme) requires a hard fork or a parallel, fragmented EntryPoint system.\n- Risk: Stagnation of core infrastructure; inability to adopt future EIPs efficiently.\n- Cost: Fragmented liquidity and user experience across multiple, incompatible EntryPoint versions.

Each new signature scheme (e.g., Passkeys, Multi-Party Computation) requires custom verifier modules. Bundlers must support them all or lose users, increasing their operational overhead. This cost is passed to users as higher priority fees.\n- Risk: Bundler centralization as only large players can afford to integrate every new scheme.\n- Cost: ~20-30% higher gas overhead per transaction for modular signature verification vs. native EOA.

Every smart account stores its logic and state on-chain. Mass adoption means millions of persistent contract slots on Ethereum L1, not just ephemeral EOAs. This exponentially increases historical state size, worsening node sync times and hardware requirements.\n- Risk: Accelerates Ethereum's state growth crisis, pushing node operation further towards centralization.\n- Cost: Increased sync times and storage costs for all network participants, a negative externality.

The fix is architectural: move from singleton proxies to isolated, per-account logic contracts. Inspired by diamond proxies (EIP-2535) or Rhinestone's modular account, this isolates risk. A bug affects one user's logic module, not the entire system.\n- Benefit: Enables aggressive, permissionless innovation in modules (signatures, recovery).\n- Benefit: Aligns incentives; users audit/choose their own upgrade risk, removing systemic contagion.

The dominant EIP-1967 upgrade pattern creates a persistent, centralized risk vector. Every ERC-4337 smart account and DeFi protocol uses it, concentrating systemic risk.

• Single Point of Failure: Admin key compromise can drain all user funds.
• Governance Lag: DAO votes for upgrades are slow, creating vulnerability windows.
• Storage Collision Risk: Improper implementation can corrupt user data.

Starknet's approach sidesteps proxy complexity by baking upgradability into the L2 sequencer. User accounts are immutable, but the entire chain state can be migrated.

• User Sovereignty: No single admin key controls your account logic.
• Atomic Migration: Upgrades happen at the chain level, ensuring consistency.
• Hidden Cost: Relies entirely on StarkWare's integrity for safe state transitions.

zkSync Era implements a compromise: accounts have immutable core logic but can declare support for future, pre-agreed version upgrades via Account Abstraction.

• Explicit Opt-In: Users must sign to upgrade, preventing surprise changes.
• Backwards Compatibility: Old account versions remain functional on-chain.
• Fragmentation Risk: The network must support multiple account versions simultaneously.

EIP-2535 Diamonds allow unlimited, modular upgrades via a proxy with multiple logic facets. Used by projects like Aave and Uniswap v4.

• Granular Upgrades: Swap specific functions without full contract replacement.
• Reduced Blast Radius: A bug in one facet doesn't compromise the entire system.
• Audit Nightmare: Exponential increase in interaction surfaces and upgrade paths to review.

Cosmos SDK chains treat the application as the upgradeable unit via hard forks and state exports. This is the model for dYdX Chain and Osmosis.

• Total Flexibility: Can change any logic, VM, or consensus rule.
• Validator Consensus: Requires supermajority of validator stake to execute.
• Extreme Friction: A hard fork is a social and technical coordination event, not a simple transaction.

The endgame may be eliminating on-chain upgrades entirely. Systems like UniswapX and CowSwap process intents off-chain; only settlement is immutable.

• Zero Upgrade Risk: Core matching logic exists off-chain, can be changed freely.
• User Empowerment: Solvers compete, users get best execution without protocol changes.
• New Centralization: Relies on a robust network of off-chain solvers and fillers.

Most smart accounts rely on a centralized admin key for upgrades, creating a honeypot for attackers and a target for state-level coercion.

• Billions in TVL can be frozen or drained by a single compromised key.
• No time-locks or multi-sig delays on upgrades are common, enabling instant rug-pulls.
• The social contract of immutability is broken, undermining a core blockchain value proposition.

If an L2's sequencer or governance is compromised, it can force malicious upgrades to all smart accounts on its chain.

• Protocols like Arbitrum, Optimism, and zkSync become central authorities over user accounts.
• This creates chain-level systemic risk, far exceeding individual contract bugs.
• It inverts the security model: the chain secures the user, until the chain attacks the user.

Users cannot audit the upgrade logic for every dApp's custom smart account, creating a massive hidden attack surface.

• Each dApp (Uniswap, Aave, Friend.tech) may deploy its own wallet logic with unique admin controls.
• Security assumptions are non-composable; a safe DeFi position can be drained via a wallet upgrade in a unrelated social app.
• This fragmentation makes comprehensive risk assessment impossible for users and insurers.

A malicious upgrade will force a contentious chain fork to revert it, but user state and DeFi positions may be irrecoverably corrupted.

• Can the fork accurately revert all cross-chain messages via LayerZero, Axelar, or Wormhole?
• Oracle prices (Chainlink) and liquidity pools will diverge, making portfolio reconciliation chaotic.
• The result is permanent loss of consensus on what constitutes the valid state, a fatal blow to any chain.

The only viable architecture separates an immutable, audited core (kernel) from upgradeable, permissionless logic modules.

• Kernel = Immutable. No admin key. Defines a strict, limited interface for modules.
• Modules = Upgradeable & Permissionless. Anyone can deploy a new signer or feature module, but they cannot corrupt the kernel.
• Users opt-in to new modules, shifting risk from systemic to individual choice. See ERC-6900 and Rhinestone for implementations.

Replace a single admin key with a decentralized security council or a timelock enforced by a network of watchers.

• Multi-sig with >7/10 signers from geographically/jurisdictionally diverse entities.
• Enforced timelocks (e.g., 7 days) broadcast all upgrade intent, allowing users and protocols like MakerDAO or Compound to exit.
• Attestation networks (e.g., EigenLayer) can slash council members for malicious actions, aligning incentives.

ERC-4337 EntryPoint and most smart accounts use a proxy pattern for upgrades. The admin key controlling this is a catastrophic single point of failure. A compromise allows an attacker to upgrade the logic to a malicious contract, draining all associated user accounts in a single transaction.

• Risk: A single key compromise can lead to $100M+ TVL losses.
• Mitigation: Implement time-locked, multi-signature upgrade controls with strict social consensus.

Upgrading logic contracts can inadvertently overwrite or corrupt existing user storage slots if the new layout isn't backward compatible. This breaks the core promise of non-custodial immutability, as user state can be altered by the upgrade itself.

• Problem: A "safe" upgrade can brick user accounts or freeze funds.
• Solution: Enforce EIP-1967 storage slots and rigorous upgrade simulations using tools like Foundry fuzzing.

Not all wallets, bundlers, or indexers immediately support new account logic versions. A successful on-chain upgrade can lead to network fragmentation, where users on outdated clients cannot interact with the protocol, creating a poor UX and security blind spots.

• Consequence: ~30% of users could be stranded post-upgrade.
• Architect's Move: Design graceful degradation and maintain multiple active logic versions with clear deprecation schedules.

The entity with upgrade power (often the core dev team) holds ultimate control, creating a regulatory and moral hazard. This contradicts the decentralized ethos of account abstraction and exposes the project to legal scrutiny as a potential custodian.

• Hidden Cost: You become a de facto custodian with associated liability.
• Path Forward: Explore decentralized upgrade governance (e.g., DAO votes) or immutable, modular plugins as seen in Rhinestone's module marketplace.

Every upgradeable call adds ~5k-20k gas for delegatecall overhead and storage slot management. For frequent, simple operations, this can double transaction costs compared to a monolithic, immutable contract, eroding the UX benefits of AA.

• Metric: +40% gas cost for common user operations.
• Optimization: Use immutable core with pluggable, ERC-7579-standard modules to minimize runtime overhead.

Upgradability is often justified to patch bugs, but the upgrade mechanism itself is complex code prone to bugs. A flawed upgrade can be worse than the original bug, permanently disabling recovery. The industry standard for secure upgrades is still nascent.

• Reality: The upgrade path is attack surface.
• Requirement: Mandate formal verification (e.g., with Certora) for all upgrade logic and maintain a cancellable timelock as an emergency brake.