Table of Contents:
Account abstraction (AA) is one of Web3’s biggest bets to fix its user experience issues.
Our industry is currently in the search for better products that allow it to compete with traditional alternatives. In this context, AA arises as a way to facilitate the building of complex business scenarios and applications, leading to swifter experiences for end users and more flexibility for developers.
AA represents a drastic improvement upon the existing Externally Owned Account (EOA) framework dominating the EVM ecosystem. However, its adoption necessarily needs to be bootstrapped via decentralized, organic growth, there is no direct roadmap to achieve it.
Meanwhile, WaaS tools allow end users to quickly create and manage wallets using only their Web2 credentials. They also simplify the experience of interacting with dApps by putting signatures and other activities directly in-app. Moreover, thanks to some technical solutions, like Particle's MPC-TSS, these wallets can also be fully non-custodial and secure.
WaaS tools, as they stand, represent a self-contained, straightforward solution to seamlessly onboard users into Web3. However, Particle Network sees the opportunity of incorporating AA into its WaaS offering as a way to accelerate account abstraction adoption, empower developers to build better apps, and upgrade Web3’s infrastructure.
Because of this, we’re thrilled to unveil Particle Network’s Smart Wallet-as-a-Service Modular Stack, dedicated to providing maximum flexibility for developers implementing AA into their applications. To introduce this release, let’s first take a look into the motivations for it, and WaaS tools’ current capabilities. We’ll then move on to our Smart WaaS Modular Stack’s features, and the benefits it can bring developers and the ecosystem as a whole.
The pitfalls of the EOA framework
To better showcase the differences between EOA-centric WaaS tools and Particle’s Smart Wallet-as-a-Service modular stack, it’s important to first understand the possibilities enabled by AA, and how the EOA framework difficults their creation.
The EOA framework’s root problem is that it falls short in scenarios that require advanced logic or multi-step procedures, critical for complex applications. For developers, this means repetitive coding, an inherent lack of ability to dictate how their users interact with their dApps, and a steep, prone-to-errors learning curve.
AA addresses these challenges through programmability, allowing for transactions that can automatically respond to on-chain events, execute routine multi-signature authorizations for enhanced security, and enable more flexible and secure user authentication protocols directly within the wallet infrastructure. For developers, this also means a fundamentally more flexible experience.
Some examples of dApps that are currently impractical to build within the EOA framework, but made possible by AA are:
- DeFi aggregators: These aggregators can play diverse functions, such as enabling users to interact with multiple platforms at once, set recurring interactions with those platforms, use more than one type of token at once for activities, and more. If the UX is attractive enough and fiat on/off-ramps are adequately implemented, AA opens the potential for non-custodial, fully decentralized, gasless platforms to fully replace centralized ones.
- P2P microtransaction-powered social and media platforms: Even in the low-fee environment of L2s, EOAs make the experience of interacting with a social platform uncomfortable. AA can simplify this, enabling designs that have long been dreamed of –such as P2P microtransaction platforms where viewers pay microtransactions to creators proportional to their viewing time– to come to life.
- X-to-Earn, gaming, and revenue democratization platforms: AA can facilitate interactions and enable seamless transactions via Session Keys, making it ideal for scenarios that require an ongoing, fast pace of transactions. X-to-Earn and Web3 gaming experiences can therefore become more practical to build and addictive (hopefully in a good sense!) for users. Democratized platforms re-distributing fees and revenue to users and token holders can also thrive in this environment.
When it comes to AA’s adoption, ERC-4337 was a pivotal achievement, as it allowed for the first working AA applications. However, as ERC-4337 is still not enshrined at a protocol level, the growth of AA is highly dependent on its decentralized, organic bootstrapping by the community. In this context, WaaS tools can play a critical role in accelerating this process, even acting as intermediate steps leading up to some suggested approaches, such as voluntary migration (EIP-7377).
WaaS tools and their transition into the AA paradigm
WaaS tools enable developers to concentrate their efforts on building better experiences, making it easier to deal with the underlying Web3 infrastructure. They do this by improving users’ experience in setting up and using wallets, but also can do a lot more, as we explained in this article. To summarize their virtues, WaaS tools can currently:
- Simplify the process of users creating wallets when they first land in Web3, allowing them to log in via Web2 credentials and creating a seamless transition.
- Streamline the process of signing transactions by putting them directly in-app.
- Provide developers with a modular stack to implement their desired features into their dApps. This can include built-in customization tools for their desired look and feel, as well as practical adaptations.
As the EVM ecosystem seeks to upgrade to an AA framework, WaaS tools natively adopting AA can accelerate this adoption. To fully grasp how, it’s critical to understand the key differences between native and non-native AA implementations at a WaaS level.
Non-native account abstraction implementations
In non-native implementations, the EOA WaaS provider acts as a Signer (owner) of a smart account. In this design, the Signer relies on a third-party application to be aligned with a specific smart account implementation (for which there are numerous). The Signer then manually authenticates the smart account’s interactions through the EOA, which is accessible through the WaaS service. This can result in the need to manually initialize accounts and sometimes also building/sponsoring/pushing UserOps, etc.
See an example for the initialization of a smart account using a non-native AA solution here.
Native account abstraction implementations
Native implementations of AA feature support on the user and developer side. In Particle’s case, this refers to allowing end users the option of choosing whether to use an EOA or smart account within the wallet itself. In this design, an EOA is still the Signer for a smart account, but the assignment and unification of these two accounts are handled by the WaaS provider. In our native implementation, the smart account is constant across applications that use Particle’s Smart Wallet-as-a-Service stack. This results in a more streamlined experience than non-native implementations and creates room for network effects.
For developers, native implementations are more natural and simple. Particle’s AA SDK automatically handles account initialization, UserOp building, and other prerequisites, eliminating the (somewhat common) requirement of manual UserOp and smart account management when working with numerous third-party AA stack components.
See this link for an example of an implementation using Particle’s AA SDK.
Native AA WaaS implementations as adoption drivers
Given AA’s current experimental stage, MetaMask and other market leaders are constrained by their size in their ability to incorporate it at scale. As such, WaaS services currently have the greatest incentive –as well as a straightforward path– to implement these features, aided by their position as leaders in UX-forward solutions. WaaS tools can be critical for Web3 adoption because of their seamless user onboarding, and, via native support, they can leverage this momentum and redirect it to the widespread adoption of AA.
Native support also means that WaaS tools create an ideal framework for developers exploring how to integrate AA into their tools. This opens the door for modularity to come into play, allowing developers to decide:
- Their target smart account implementations.
- What bundlers to use.
- Potentially, whether to plug into other third-party tools, e.g. Paymasters
Given the unique role WaaS tools play in Web3 UX, and how they can accelerate AA adoption, we envision Smart WaaS as a natural evolutionary step. In our vision, these tools can give developers the ability to supercharge their dApps with AA, allowing them to iterate faster in quantity and quality, leading to a creativity explosion that eventually attracts more users to Web3. The resulting timeline of AA adoption, all factors we’ve mentioned considered, could look as follows:
Particle Network’s Smart Wallet-as-a-Service modular stack
Given all the points discussed above, Particle’s Smart Wallet-as-a-Service modular stack sets out to create an ERC-4337 AA implementation that enables end-to-end onboarding and utilization of AA, empowering developers to build next-generation Web3 experiences. Particle’s goal is to create a flexible experience for developers, allowing them to interact natively with AA while directly tied to an instance of Particle’s WaaS.
Particle’s Smart WaaS aims to provide developers with every possible path to leverage WaaS + AA in their applications, regardless of their complexity, features, backend implementation, etc. Ultimately, this empowers them to choose the services and tools that best suit their applications’ needs. Regardless of a developer’s specific intended implementation of AA within a given application, we've built in the modularity required to enable complete utilization of ERC-4337 powered by Particle’s AA-SDK at any level of the underlying tech stack.
In building our Smart WaaS stack, we see the following as critical:
- Seamless onboarding via WaaS & non-custodial key management: Particle’s existing implementation of WaaS features MPC-TSS private key management. This, combined with social authentication, ensures that end users can be swiftly and securely onboarded –regardless of their level of familiarity with Web3.
- Leveraging AA’s flexibility without compromising application complexity: This empowers developers to build all kinds of applications, making the most out of AA’s capabilities. Particle’s AA-SDK enables very familiar mechanisms of interacting with smart accounts programmatically –such as familiar transaction structures, building, and account management, all handled seamlessly by the SDK. In implementation, this means a short path to start using AA with Particle’s WaaS for onboarding and account management –and subsequently, Particle’s AA SDK for post-onboarding AA, in tandem with WaaS.
- AA modularity via WaaS: Particle’s AA SDK allows developers to approach AA modularly, plugging into their preferred smart account implementations, Bundlers, Paymasters, etc. with ease. Particle as a WaaS provider can also be plugged into any initial/onboarding point within AA applications, even if they don’t natively use our AA SDK. As such, even non-native AA applications can leverage Particle’s WaaS for onboarding. This creates a wholly customizable building experience for native and non-native applications alike.
Particle’s modular approach to AA, and the implementation as a whole, are demonstrated in the diagram below:
To dive deeper into this modular stack, below, you can see a tutorial from Ethan Francis, Developer Relations @Particle Network, demonstrating how to build an application (in his example, gasless implementation) with minimal code. In this video, Ethan uses our native AA SDK with built-in Biconomy support.
You can also see the code used in the above example below or in this link.
In a very nascent AA field, with multiple smart account implementation options, introducing a comprehensive modular stack ensures even greater flexibility for developers. A modular approach means that they can also plug into their preferred components while staying friendly for builders who do not demand much customization.
Infrastructure components of Particle’s AA stack
At the moment, Particle’s official developer and user-facing support uses Biconomy’s smart accounts. However, in an effort to promote intrinsic modularity and cross-compatibility across the ecosystem, Particle will enable both users and developers to choose what specific smart account implementation they'd like to use natively within our SDK & UI, presenting an advanced solution that doesn’t automatically default to a single provider.
Particle’s native modular AA support (via a native SDK, Particle’s RPCs, etc.), while powerful on its own, is also inherently cross-compatible with other AA stack providers due to Particle’s nature as a WaaS provider.
The following are a few examples of utilizations of Particle’s stack.
- Using Particle’s AA SDK for account management, Paymaster, UserOp building, and pushing through Pimlico's bundler (see here).
- Using Particle’s AA SDK for account management, then manual UserOp building, sponsorship, and pushing through Pimlico's Bundler and Paymaster (see here) (demo)
- Using the EOA derived from our WaaS as the Signer in an alternative smart account implementation, choosing a Bundler and Paymaster (see here).
The Particle Bundler
Particle has also built a proprietary Paymaster and Bundler. Particle’s Bundler is fully open-source, and it facilitates scalable and reliable ERC-4337 interactions. In fact, the Particle Bundler has been used to bootstrap the large-scale adoption of account abstraction across numerous public chains through partner programs, facilitating hundreds of thousands of transactions for OpBNB, Scroll Sepolia, and the Combo Testnet.
The Particle Bundler streamlines user transactions by managing Smart Account Nonces and automating batch sending of User Operations. It simplifies deployment to new chains through a single command, enabling support for additional chains within five minutes. For developers, it offers features like Bundler Signer configuration, automatic recharging, and monitoring alerts. The Bundler handles high workloads efficiently, ensuring quick transaction processing. It maintains operational stability under various conditions, supported by a robust infrastructure.
Key features for the Particle Bundler include support for standard RPCs, configurable signers, multi-chain support, persistent User Operations, concurrent handling of UserOps, an integrated Gas Price Oracle, and a management system for multiple Bundler Signers. The Bundler also automatically replenishes Bundler Signers' balances and retries failed transactions, providing accurate transaction details amidst MEV effects. You can find more details about it in its open-sourcing announcement.
Particle’s Smart WaaS implementation also features MPC-TSS-enabled security features to protect users’ data and assets. These security considerations are diagrammed below:
Particle uses a 2/2 advanced TSS approach ensuring that users’ private keys security is never concentrated in a single location or entity throughout their lifecycle. This method involves splitting the key into two shares, stored separately, ensuring that each share reveals nothing about the full key. Particle also opens the possibility for the user to create a Master Password, used to encrypt their local key fragment, which can then be stored safely. This allows users to restore their wallets across devices with full security. To learn more about this mechanism and why it is the safest option to secure users’ private keys in a non-custodial way, see our “How to Choose a WaaS” article.
What’s next for Particle and Smart Wallet-as-a-Service?
Account Abstraction, when combined with Wallet-as-a-Service solutions, has the potential to transform the experience of developers and end-users of Web3, making our ecosystem more attractive.
Particle's Smart Wallet-as-a-Service modular stack represents a significant upgrade for an already attractive product, emphasizing practicality and simplifying the process of building friendly applications that leverage AA. In this regard, Particle’s ecosystem of integrations shines as one of the main strengths in our goal to pursue flexibility as a guiding principle.
In coming announcements, we’ll talk about Particle’s Omnichain Account Abstraction, which will play a significant role in Particle upcoming v2’s token-centric design. Surrounding this innovation, Particle will debut a new suite of developer and end-user-oriented products, contributing to a more integrated and versatile environment.
The advancements in Smart WaaS presented in this article are an opportunity for innovation and improved application performance. If you made it this far into this piece, we invite you to leverage Particle's resources, including our detailed tutorials and thorough documentation, to integrate these enhancements into your projects. As AA adoption increases, developers building AA-supercharged dApps certainly will play a pivotal role in accelerating Web3 adoption.
To start using Particle's Smart WaaS stack, click here.
Particle Network's Modular Smart Wallet-as-a-Service solutions are 100% free for developers and teams. If you have any inquiries about integrating with us, feel free to book a meeting with one of our agents!
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.