Announcing Particle Network’s Omnichain Account Abstraction Infrastructure

The last two months have been full of announcements and developments for Particle Network. From revealing our upcoming v2’s design with zero-knowledge and intent-centric features to details on its surrounding token-centric economy, we are gradually displaying our master plan to onboard the next billion users to Web3.

In light of these announcements, a recent article from our CTO discussed different existing approaches to solving challenges within the Account Abstraction (AA) field. This article also outlined Particle’s idea of combining several existing achievements and proposals for Omnichain Account Abstraction –an approach that addresses several user experience and robustness issues with AA infrastructure and its design. Furthermore, Omnichain Account Abstraction represents a solution for different cross-chain and interoperability pain points the industry has long been facing.

Without further ado, today we are officially announcing Particle’s Omnichain Account Abstraction infrastructure. Let’s jump right into the details!

TL;DR: Particle’s Omnichain Account Abstraction combines the best out of different proposals to improve account abstraction by decoupling the Storage and Code of smart accounts. This allows it to simultaneously address existing challenges in cross-chain transactions and multi-chain account abstraction. Omnichain AA introduces the Particle Chain (a zkEVM also empowering Particle to support other functionalities, such as confidential logins and transactions) as a central hub for account Storage. Within this framework, the Particle Chain synchronizes Storage changes via cross-chain messaging, enabling it to operate across chains. Omnichain AA uses Deployer Contracts for unified address generation and multi-chain Storage management. Cross-chain messaging solutions leverage existing messaging bridges to support interactions on different chains. Within this system, the Particle token acts as a unified gas token to address gas inefficiencies in multi-chain execution. This design simplifies the process of managing smart accounts across multiple chains and enhances the efficiency of cross-chain operations.

Motivations for Omnichain Account Abstraction

As detailed in our CTO’s analysis, the current ERC-4337 AA framework more closely resembles "transaction flow abstraction," as it primarily focuses on optimizing the underlying process for transaction execution rather than the accounts themselves. 

This is valuable in that it lays a foundation for smart wallets to be adopted and later implemented at a protocol level but creates a unique set of problems, namely: 

1. Hard-to-integrate AA solutions, leading developers to build custom implementations.
2. Poor account module compatibility, resulting in a fragmented ecosystem.
3. Fragmentation between different chains, making it difficult to provide end-users and developers with a unified and high-quality experience. This results in subpar UX implementations.

In light of these challenges, three approaches have emerged to deal with them:

1. Biconomy proposes a standardized approach to modularity for developers to build their own solutions on top of, instead of adapting ERC-4337 smart account implementations. This proposal also involves creating highly specialized markets for different modules that can be integrated with smart accounts (Bundlers, Paymasters, etc.)
2. Safe (prev. Gnosis Safe) proposes an approach with key differences and similarities. It intends to create a protocol for lightweight Smart Accounts that are as simple as EOAs. On top of this protocol, a Module Market would arise for different vendors to create their own implementations while retaining compatibility.
3. Vitalik Buterin has proposed a system that uses Ethereum or a highly secure zk-rollup as its source chain and deploys a Keystore contract to store users' global keys. In this system, users' smart contract accounts on L2s share the global keys stored in the Keystore contract.

The first two approaches above focus on modularity and compatibility, two necessary features for AA. Vitalik's, on the other hand, focuses on bootstrapping AA across a multi-chain ecosystem with multiple L2s and EVM chains. Let’s take a deeper look into the multi-chain implications of smart accounts under the current framework, as well as Vitalik’s proposed solution.

The multi-chain problems of smart accounts

The current multi-chain EVM environment results in users with smart accounts deployed independently on different chains. For each of them, information related to account management –including permissions– is stored in the contract's Storage. Updating this information requires users to initiate transactions on multiple chains, making it technically-challenging and time-consuming to ensure consistency across networks

Within the design of ERC-4337, smart accounts use a globally unique address determined by the initCode. The initial management permissions are encoded in the initCode, meaning that, if a user deploys a smart account on a new chain but has already made management permission changes on other chains, they would need to repeat these changes on the new chain. This poses a heavy demand on users and wallets in an increasingly complex environment.

To illustrate the importance and challenges of these issues, consider the following scenario:

1. Alice deploys a smart account with Owner1 on Polygon and Arbitrum. She periodically changes Owners as a habit. 
2. Alice replaces the smart account's Owner with Owner2 and forgets Owner1's private key.
3. Using her address, Bob transfers USDC to her on Linea.
4. Alices realizes that she needs Owner1's private key to initiate a transaction, as the initialization initCode depends on Owner1. Unfortunately, she has forgotten Owner1's private key, leaving her assets completely inaccessible.

Vitalik’s solution indeed solves the issue of managing addresses across multiple chains, especially regarding changes in account Storage, such as ownership transfer and social recovery. However, this solution is problematic in that it involves considerable costs. Besides non-trivial setup expenses, if the global key recorded in the Keystore contract on the source chain (Ethereum Mainnet) changes, every account on the L2/target chain would need to synchronize through cross-chain interactions. The cost for these interactions, involving Ethereum and L2s, would be too high for users to universally accept.

It is also important to note that smart contract accounts work differently than EOAs, making it difficult for users to retain the same address across chains, whether they are EVM compatible or not. As such, Particle Network derives inspiration from Buterin’s approach, but introduces key changes to minimize the impact on users.

Particle Network’s solution

Particle's own approach elaborates and provides a viable alternative that addresses multi-chain AA’s shortcomings and takes advantage of other infrastructure components of Web3.

Particle Network’s approach proposes the usage of an independent chain –the Particle Chain– as the full-chain Storage database for smart accounts. Through third-party cross-chain messaging solutions (such as LayerZero, CCIP, Axelar, Connext, etc.), changes to an account's Storage by a user will be eventually synchronized to the Account's local storage on other chains. Particle Network introduces cross-chain UserOperations to further abstract the concept of chains, facilitating seamless cross-chain interactions. It also features the Particle Network Token as a Unified Gas Token to abstract elaborate gas mechanisms, simplifying the usage of smart accounts across chains. This is depicted in the diagram below:

Particle Network's Omnichain Account Abstraction allows users to have a unified smart contract account address on different EVM chains. To achieve this, our design involves deploying a set of Deployer Contracts on each chain. Users must trigger the generation of a new account on the Particle Network Chain, which will cause it to trigger all Deployer Contracts on different chains. This ensures that the generated smart contract account addresses are consistent across them. Alternatively, users can interact with multiple chains through contracts on the Particle Chain without actively managing multiple addresses, and they can use Particle’s token as a unified fee payment method.

Omnichain Account Abstraction also enables cross-chain UserOperations by executing transactions on the target chain and paying the corresponding gas on the source chain. For example, this allows users to purchase NFTs on Base using Polygon $USDC.

Omnichain AA does require a high level of coordination between the Deployer Contracts and cross-chain message-passing components to achieve synchronization between multi-chain accounts and source chain storage. This places high demands on the oracle or cross-chain message bridge used –a common issue in solutions related to full-chain interoperability. However, synchronizing the user's cross-chain account can happen via flexibly configuring different combinations of Message Bridges, rather than relying on just one. For example, these can, be configured with a 2/3 strategy, where confirmation from any two of LayerZero, Axelar, and Connext is required to confirm the storage change on the target chain, solving the single-point-of-dependency problem.

Particle Network’s featured solution also addresses the additional issue of facilitating compatibility with chains that are EVM-compatible but that have different AA implementations and, as such, cannot be unified with ERC-4337 addresses.

Key components of Omnichain Account Abstraction

For additional depth and some critical considerations, the key components for Omnichain AA are:

The Particle Chain

By decoupling the management permissions and account logic of smart accounts –which can be simplified as the separation of Storage and Code (Logic)--, we require a secure chain to store the user's account management permissions (Storage/KeyStore). The Particle Chain, therefore, serves as the most critical component of Omnichain. It stores the data (Storage) of the user's smart account, coordinates Deployer Contracts across different chains, and handles cross-chain message passing components to ensure the storage and updates of the user's multi-chain smart account.

Deployer contract

For a multi-chain smart account, a unified address is needed, which is determined by the Deployer Contract (Create2). The Deployer Contract and cross-chain message-passing components work together to achieve unified Storage across multiple chains. For the initial deployment of a smart account, the Deployer Contract refuses deployment from chains other than the Particle Chain, ensuring that the initial deployment also has the same Storage.

Cross-chain messaging

Updating the Storage of an account on the Particle Chain requires support from cross-chain messaging components. We directly adopt implementations like LayerZero for this purpose. Users can call the xManage method of their smart accounts from Particle Chain to synchronize their state with any other chain, whether it's the initial deployment or subsequent updates. Users can also initiate a cross-chain UserOperation by calling xExecuteTx from any source chain where their Smart Account is deployed, ensuring that transactions are executed correctly on the target chain.

Token

We introduce the Particle Network token to address the gas consumption issue during multi-chain execution, further enhancing execution efficiency and user experience. Paymasters in 4337 ensure that any ERC-20 token can be used as a gas token. In cross-chain transactions, Particle tokens in any chain can be used to directly pay for gas fees on other chains.

Having a single payment unit for cross-chain transactions significantly reduces the cognitive load of managing multiple tokens. Currently, any cross-chain interaction necessitates at least 2 tokens to cover for gas on different chains, and routinely conducting said activities results in the need to hold as many tokens as the number of chains the user aims to interact with.

For users, Omnichain AA results in simplified scenarios such as the following:

1. Alice initiates a UserOperation on Chain A, consuming Particle tokens on Chain A.
2. Cross-chain execution on Chain B is initiated by calling the Smart Account's xExecuteTx on Chain A to complete the corresponding action on Chain B.

Further considerations and Particle Network’s evolution toward v2 

Wrapping up this announcement, it’s important to consider that, as Particle’s Omnichain AA is still in development, further enhancements can be made to its design. For example, we’re analyzing the use of optimistic cross-chain protocols to mitigate settlement delay issues, increasing the speed of Omnichain User Operations. Since Omnichain AA will be introduced within Particle’s v2, modularization and ecosystem adaptation are crucial components of its strategic release. 

Particle Network’s v2 will also feature an Intent-Centric approach with the goal of abstracting the underlying difficulties of dealing with different AA and smart account modules. Within this kind of architecture, Ethereum’s ERC-4337 ecosystem –or native account abstraction facilities of other chains such as zkSync– can be regarded as specific instances under the Solver/Reactor types.

Particle’s v2 will be released within the framework of a zero-knowledge Wallet-as-a-Service (zkWaaS) ecosystem with zero-knowledge features to improve users’ identity and transactional privacy. Thanks to v2’s zkWaaS easy development experience and modularity, dApps integrating Particle can leverage consistent, optimized transaction processes, reducing the developmental overhead associated with transactional logic. The WaaS model shoulders the burden of user experience optimizations and seamless onboarding, freeing developers to focus on core application logic and innovative features.

Notoriously, some of v2’s features, besides serving their own purpose, also serve to reduce the costs for users of Omnichain AA. Three factors help Omnichain AA reduce usage and setup expenses for users:

1. Aggregation of user activities via a confidential Paymaster/transaction bundling: Particle’s v2 Omnichain AA will implement a confidential Paymaster to enable transactional privacy, and through the aggregation of transactions, Particle can reduce fees for its users.
2. Intent-centric developments leading to ongoing optimization: Particle v2’s intent-centric design will incentivize a Solver market to ongoingly optimize the experience of users expressing their intents, resulting in cost savings for users.

For developers pioneering the next generation of dApps, the implications of v2 are profound. The Omnichain model provides an unparalleled multi-chain framework, vital for dApps demanding AA’s flexibility in a diverse ecosystem. Embracing intent-centric design, on the other hand, transforms how users engage with dApps.

We will continue to release information on v2 and Omnichain AA as we progress in our development. If you want to follow our progress, click the “Subscribe” button or follow us on our social media accounts!

About Particle Network

Particle Network is building the Intent-Centric Access Layer of Web3. Particle's Modular Smart Wallet-as-a-Service tools allow developers to tap into MPC-TSS and social logins to enable self-custodial, dApp-embedded wallets accessible through users' Web2 accounts. This also allows them to tap into ERC-4337 account abstraction, enabling a seamless experience with maximum flexibility. Particle's next evolutionary steps include the introduction of Omnichain Abstraction, a Confidential zkStack, and the Intent Fusion Protocol, elevating users' experience within dApps and paving the way for mass Web3 adoption.

Website | Docs | Discord | Twitter