Modular Smart Contract Account Design: Solving Practical Technical Challenges
TechFlow Selected TechFlow Selected
Modular Smart Contract Account Design: Solving Practical Technical Challenges
By leveraging a modular smart contract account stack, wallet providers and dApps can摆脱 the complexity of technical maintenance.
Navigating Web3 tides with focused insightsAuthor: Rui S (SevenX Ventures)
Translated by: TechFlow
Introduction
The shift from externally owned accounts (EOAs) to smart contract accounts (SCAs) is gaining momentum and has strong support from many enthusiasts, including Vitalik himself. Despite the excitement, SCA adoption hasn't reached the same level as EOAs. Key issues include challenges brought by bear markets, migration concerns, signature problems, gas overhead, and most critically, engineering difficulties.
One of the most important advantages of account abstraction (AA) is the ability to customize functionality through code. However, a major engineering challenge lies in the non-interoperability of AA features, where fragmentation hinders integration and opens the door to vendor lock-in. Additionally, ensuring security while simultaneously upgrading and combining functions can be complex.
The emergence of modular account abstraction—a subset of the broader AA movement—offers an innovative approach by decoupling smart accounts from their custom functionalities. The goal is to create a modular architecture for developing secure, seamlessly integrated wallets with diverse capabilities. In the future, it could enable a free "app store" for smart contract accounts, allowing wallets and dApps to focus less on building features and more on user experience.
A Brief Overview of AA
Traditional EOAs introduce numerous challenges such as seed phrases, gas fees, cross-chain operations, and multiple transactions. We never intended to add complexity, but the truth is that blockchain isn't exactly simple for mainstream users.
Account abstraction leverages smart contract accounts to enable programmable validation and execution, allowing users to approve a sequence of transactions in one go instead of signing and broadcasting each individually, unlocking additional functionalities. It brings benefits to user experience (e.g., gas abstraction and session keys), cost efficiency (e.g., batched transactions), and security (e.g., social recovery, multi-sig). Currently, there are two ways to implement account abstraction:
-
Protocol Layer: Some protocols natively support account abstraction. For example, ZKsync processes transactions uniformly whether they come from an EOA or SCA, using a single mempool and transaction flow to support AA. Starknet has removed EOAs entirely—all accounts are SCAs—and offers native smart contract wallets like Argent.
-
Contract Layer: For Ethereum and its equivalent L2s, ERC-4337 introduces a separate transaction entry point to support AA without modifying the consensus layer. Projects like Stackup, Alchemy, Etherspot, Biconomy, Candide, and Pimlico are building bundler infrastructure, while others like Safe, Zerodev, Etherspot, and Biconomy are building stacks and SDKs.
The Dilemma of SCA Adoption
Since 2015, the topic of account abstraction (AA) has been discussed, and this year, it was thrust into the spotlight by ERC-4337. Yet, the number of deployed smart contract accounts still lags far behind EOAs.
Let’s dive deeper into this dilemma:
-
Bear Market Impact:
Although AA introduces benefits like seamless login and gas abstraction, during the current bear market, the primary user base consists of educated EOA users rather than new adopters, so there's little incentive for dApps and wallets. Still, some leading applications are gradually adopting AA—for instance, CyberConnect introduced its AA system and gasless solution, driving approximately 360,000 UserOps (AA transactions) in just one month.
-
Migration Barriers:
For wallets and apps that have already accumulated users and assets, securely and conveniently migrating those assets remains challenging. However, initiatives like EIP-7377 allow EOAs to initiate one-time migration transactions.
-
Signature Issues:
Smart contracts naturally cannot sign messages because they lack private keys like EOAs. Efforts such as ERC-1271 make message signing possible, but signatures don’t work before the first transaction, posing a challenge for wallets using counterfactual deployment. ERC-6492, proposed by Ambire, is a backward-compatible successor to ERC-1271 that may resolve these prior issues.
-
Gas Overhead:
Deploying, simulating, and executing SCAs incurs higher costs compared to standard EOAs, creating a barrier to adoption. However, tests have been conducted—such as decoupling account creation from user operations and considering the removal of account salts and existence checks—to reduce these costs.
-
Engineering Challenges:
The ERC-4337 team has established the eth-infinitism repository, providing developers with a foundational implementation. However, as we branch out into more nuanced or specific use cases, integration and decoding become increasingly challenging.
In this article, we will delve into the fifth issue: engineering challenges.
Modular Smart Contract Accounts to Address Engineering Challenges
Further elaboration on the engineering challenges includes:
-
Fragmentation: Functionalities are currently enabled in various ways—either through specific SCAs or independent plugin systems. Each follows its own standards, forcing developers to choose which platforms to support. This can lead to vendor lock-in or duplicated efforts.
-
Security: While flexibility between accounts and functionalities offers advantages, it may also amplify security risks. Features might be collectively audited, but lack of independent evaluation increases the risk of account vulnerabilities.
-
Upgradability: As functionalities evolve, maintaining the ability to add, replace, or remove them is crucial. Re-deploying existing features with every update introduces complexity.
To address these issues, we need upgradable contracts to ensure secure and efficient upgrades, reusable cores to improve overall development efficiency, and standardized interfaces to allow smooth transitions across different frontends.
These concepts converge toward a shared vision: building a modular account abstraction (Modular AA) architecture.
Modular AA is a niche within the broader AA movement, envisioning modularized smart accounts that serve users with customized services and empower developers to seamlessly enhance functionality with minimal constraints.
However, in any industry, establishing and promoting new standards is a significant challenge. Before a dominant solution is widely accepted, the initial phase may see many competing approaches. Encouragingly, 4337 SDK teams, wallet developers, infrastructure providers, and protocol designers are all working together to accelerate this process.
Modular Structure: Master Account and Modules
Delegatecall and Proxy Contracts
External call vs. delegatecall:
While delegatecall is similar to call, it executes the target contract not in its own context, but within the calling contract’s current state. This means any state changes made by the target contract apply directly to the storage of the calling contract.
To achieve composable and upgradable structures, a fundamental concept known as “proxy contract” is required.
-
Proxy Contract: A regular contract stores both logic and state and cannot be updated after deployment. A proxy contract uses delegatecall to invoke another contract. By referencing the implementation function, it executes within the proxy’s current state.
-
Use Case: While the proxy contract remains unchanged, you can deploy new implementations behind it. Proxy contracts enable upgradability and are cheaper to deploy and maintain on public blockchains.
Security Architecture
Safe is a leading modular smart account infrastructure designed to deliver battle-tested security and flexibility, enabling developers to build diverse applications and wallets. Notably, many teams are building on top of or inspired by Safe. Biconomy launched its account by extending Safe with native 4337 and 1/1 multisig. Safe has deployed over 164,000 contracts and secured over $3.07 billion in value—undoubtedly making it the go-to choice in the space.
Safe’s Architecture
-
Safe Account Contract: Main proxy contract (stateful)
The Safe account is a proxy contract because it delegates calls (via delegatecall) to a singleton contract. The Safe account holds variables such as owners, threshold, and implementation address, defining its state.
-
Singleton Contract: Integration hub (stateless)
The singleton provides services to the Safe account and integrates and defines various components, including plugins, hooks, function handlers, and signature validators.
-
Module Contracts: Custom logic and functionality
Modules are powerful. As a modular type, plugins can define different functions such as payment flows, recovery mechanisms, and session keys, and act as bridges between Web2 and Web3 by fetching off-chain data. Other modules, like hooks, serve as security guards, and function handlers respond to any instructions.
What Happens When We Adopt Safe?
-
Upgradable Contracts:
Whenever a new plugin is introduced, a new singleton must be deployed. Users retain the autonomy to upgrade their Safe to the desired singleton version according to their preferences and requirements.
-
Composable and Reusable Modules:
The modular nature of plugins allows developers to independently build functionalities. They can then freely select and combine these plugins based on their use case, enabling highly customizable solutions.
ERC-2535 Diamond Proxy
About ERC-2535 and Diamond Proxy
ERC-2535 standardizes the Diamond proxy—a modular smart contract system that can be upgraded or extended post-deployment with virtually no size limit. So far, many teams have drawn inspiration from it, such as Zerodev’s Kernel and Soul Wallet’s experiments.
What Is the Diamond Structure?
-
Diamond Contract: Main proxy contract (stateful). The Diamond is a proxy contract that uses delegatecall to invoke functions from its implementations.
-
Module/Plugin/Facet Contract: Custom logic and functionality (stateless). A module, or facet, is a stateless contract whose functions can be deployed to one or more Diamonds. They are independent contracts that can share internal functions, libraries, and state variables.
What Happens When We Adopt Diamond?
-
Upgradable Contracts: Diamond provides a systematic way to isolate different plugins and connect them, allowing direct addition/replacement/removal via the diamondCut function. There is no practical limit to how many plugins can be added over time.
-
Modular and Reusable Plugins: A deployed plugin can be used by any number of Diamonds, significantly reducing deployment costs.
Differences Between Safe Smart Accounts and Diamond Approach
There are many similarities between Safe and Diamond architectures—both rely on proxy contracts as core components and reference logic contracts to achieve upgradability and modularity.
However, the key difference lies in how logic contracts are handled. Here's a detailed breakdown:
-
Flexibility: When enabling a new plugin, Safe requires redeploying its singleton contract to reflect changes in the proxy. In contrast, Diamond achieves this directly via the diamondCut function within its proxy. This methodological difference means Safe retains greater control, while Diamond introduces stronger flexibility and modularity.
-
Security: Both architectures currently use delegatecall, which allows external code to manipulate the main contract’s storage. In the Safe architecture, delegatecall points to a single logic contract, whereas Diamond uses delegatecall across multiple module contracts (plugins). Thus, a malicious plugin could potentially overwrite another, introducing storage collision risks that may compromise the proxy’s integrity.
-
Cost: The inherent flexibility of the Diamond approach comes with increased security concerns. This adds cost, requiring comprehensive audits whenever a new plugin is added. Ensuring these plugins do not interfere with each other’s functionality poses a challenge, especially for small and mid-sized teams striving to uphold robust security standards.
“Safe Smart Account approach” and “Diamond approach” are examples of different structures involving proxies and modules. Balancing flexibility and security is critical, and these two approaches may complement each other in the future.
Module Order: Validators, Executors, and Hooks
Let’s expand our discussion by introducing ERC-6900, a standard proposed by the Alchemy team, inspired by Diamond and specifically tailored for ERC-4337. It addresses modularity challenges in smart accounts by providing common interfaces and aligning collaboration between plugin and wallet developers.
Regarding the AA transaction process, there are three main stages: validation, execution, and hook. As previously discussed, these steps can be managed by having the proxy account invoke modules. Although different projects may use different names, understanding the underlying logic is essential.
-
Validation: Ensures the caller’s authenticity and permissions over the account.
-
Execution: Executes any custom logic permitted by the account.
-
Hook: A module that runs before or after another function. It can modify state or cause the entire call to be reverted.
Separating modules based on distinct logic is crucial. Standardized approaches should specify how validation, execution, and hook functions in smart contract accounts should be written. Whether it’s Safe or ERC-6900, standardization helps reduce the need for unique development efforts tied to specific implementations or ecosystems and prevents vendor lock-in.
Module Discovery and Security
A promising emerging solution involves creating a place where users can discover verifiable modules—we can call it a “registry.” This registry acts like an “app store,” aiming to foster a streamlined yet vibrant modular marketplace.
Safe{Core} Protocol
Safe{Core} Protocol is an open-source, interoperable smart contract account protocol designed to enhance accessibility for various vendors and developers through clearly defined standards and rules, while maintaining strong security.
-
Account: Within the Safe{Core} Protocol, the concept of an account is flexible and not restricted to a specific implementation, enabling participation from various account service providers.
-
Manager: The manager acts as a coordinator between accounts, registries, and modules. It also handles security, serving as a permission layer.
-
Registry: The registry defines security attributes and enforces module standards such as ERC-6900, aiming to create an open “app store” environment for discovery and security.
-
Module: Modules handle functionality and are available in various initial types, including plugins, hooks, signature validators, and function handlers. Developers can contribute as long as they meet established standards.
Rhinestone Design
The process unfolds as follows:
-
Create Pattern Definition: Patterns serve as predefined data structures for attestation. Enterprises can customize patterns based on their specific use cases.
-
Create Modules Based on Patterns: Smart contracts are registered as modules, acquiring bytecode and selecting a pattern ID. This data is then stored in the registry.
-
Obtain Attestations for Modules: Attestors/auditors can provide attestations for modules based on patterns. These attestations may include unique identifiers (UIDs) and references to other attestations for linking. They can propagate on-chain and verify whether specific thresholds are met on the target chain.
-
Implement Complex Logic Using Resolvers: Resolvers are optional components set within patterns. They can be invoked during module creation, attestation establishment, and revocation. These resolvers allow developers to incorporate complex and diverse logic while preserving the attestation structure.
-
User-Friendly Query Access: Queries provide users a way to access security information from the frontend. The EIP can be found here.
While this model is still in early stages, it has the potential to establish a standard in a decentralized and collaborative manner. Their registry enables developers to register modules, auditors to verify security, wallets to integrate, and users to easily find modules and validate attestation information. Future applications may include:
-
Attestors: Trusted entities like Safe could collaborate with Rhinestone as internal module attestors. Independent attestors could also join.
-
Module Developers: With an open market forming, module developers may commercialize their work through the registry.
-
Users: Through user-friendly interfaces like wallets or dApps, users can view module information and delegate trust to different attestors.
The concept of a “module registry” offers monetization opportunities for plugin and module developers. It may also pave the way for a “module marketplace.” Some aspects may be overseen by the Safe team, while others may manifest as decentralized markets, inviting contributions from all and providing transparent audit records. By adopting this approach, we can avoid vendor lock-in and support EVM scalability by attracting a broader audience through improved user experience.
While these methods ensure individual module security, the overall security of a smart contract account isn’t absolutely guaranteed. Combining legitimate modules and proving they have no storage conflicts may remain challenging, underscoring the importance of wallets or AA infrastructure in addressing such issues.
Conclusion
By leveraging modular smart contract account stacks, wallet providers and dApps can move beyond the complexities of technical maintenance. Meanwhile, external module developers gain opportunities to offer specialized services tailored to individual needs. However, challenges remain—including balancing flexibility and security, advancing modular standards, and implementing standardized interfaces that allow users to easily upgrade and modify their smart accounts.
Yet, modular smart contract accounts (SCAs) are only one piece of the adoption puzzle. To fully realize the potential of SCAs, protocol-level support from Layer 2 solutions is needed, along with robust bundler infrastructure and peer-to-peer mempools, more cost-effective and viable SCA signing mechanisms, cross-chain SCA synchronization and management, and user-friendly interface development.
We envision a future of broad participation, raising intriguing questions: Once SCA order flow becomes sufficiently profitable, how will traditional MEV (miner extractable value) actors enter the space, build bundlers, and capture value? When infrastructure matures, how can account abstraction (AA) become the foundational layer for intent-based transactions? Stay tuned—this field is rapidly evolving.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@SevenXVentures
