--- title: "How Account Abstraction Lowers Gas Fees in DApps" date: 2023-12-13 description: "In 2016, Vitalik first introduced the idea of account abstractions, and seven years later, in March 2023, we saw its implementation as the ERC-4337 standard." author: "Nico Bordunenko" intro_image: "https://metalamp.io/images/AAwallet.png" fulltext_image: "https://metalamp.io/images/AAwallet.png" categories: - name: "Magazine" url: "https://metalamp.io/magazine.md" tags: - name: "ethereum" url: "https://metalamp.io/tags/ethereum.md" - name: "web3" url: "https://metalamp.io/tags/web3.md" --- # How Account Abstraction Lowers Gas Fees in DApps ![How Account Abstraction Lowers Gas Fees in DApps](https://metalamp.io/images/AAwallet.png) In 2016, Vitalik first introduced the idea of account abstractions, and seven years later, in March 2023, we saw its implementation as the ERC-4337 standard. This technology is quite promising and enables features like: - Gasless transactions for users, - Paying gas fees with a token (like USDT), - Recurring payments, - Wallet access recovery via email or SMS. - It all sounded so awesome that we could hardly believe it would work as intended. We spent loads of time getting to grips with how exactly it all works and how it's different from the usual seed-phrase accounts (EOA). Our Solidity developer Pavel Naydanov explained the technology in detail in his article [Account Abstraction: What It Is and Why the Crypto World Needs It.](https://metalamp.io/magazine/article/account-abstraction-what-is-it-and-why-is-it-necessary-to-crypto-world) And in this piece, we'll talk about how such technology is implemented and how it solved a problem for one of our long-time clients. ## Where we implemented it and why it was tough The client came to us with an age-old problem: using blockchain is a pain. Here's what they meant: - To send a token to someone, you need to get the native currency to pay for the gas fees. - Seed phrases are impossible to remember, so you have to write them down somewhere. And if you lose it, your funds are gone forever. So, the task they set for us was: Create a full-fledged Web3 wallet where blockchain newbies don't have to worry about gas and seed phrases, and can access a user-friendly ecosystem with tokens and NFTs. **In our team, we discussed two solutions:** - The already tried-and-tested relayer (based on ERC-2771), - The new, but enticing Account Abstraction (ERC-4337). ![](https://metalamp.io/images/unnamed 6.png) At first glance, it seems better to use a time-tested solution rather than a standard that's still in draft. But the client had big plans to collaborate with external DeFi protocols to arrange for sponsoring users' gas fees who would use the wallet. It's a brilliant idea! A perfect example of a win-win: protocols pay for the gas for using their service and gain more users due to better UX, while the user avoids up to 4 extra steps to acquire the native network token for gas fees. Instead, they would pay a comparable amount in the same token they are operating with. Also, our client planned an on-ramp integration (like MoonPay) that would allow buying crypto for the wallet using a credit card, Apple Pay, etc. For all this, a relayer wasn't suitable as it requires changes to be made in the smart contracts of the services we want to partner with. Let's be honest - those willing to adapt their applications for yet-to-be-released wallets were not exactly queuing up. But Account Abstraction required no changes on the part of other DeFi applications. We just needed to connect to our solution and set some rules, which is much simpler than rewriting and adding additional logic. Another feature of AA was bundling several transactions into one. While a meta-transaction from a relayer could only contain one transaction, an AA bundler allowed packing several user operations (UserOperations) into one transaction. This helps to save on costs for potential gas sponsors. ## What did we decide about the seed phrase? Another crucial requirement was to free the client from the risk of holding users' funds. This requirement was inspired by the still fresh-in-memory case of FTX. The client had no plans to manage user funds, so we suggested using Fireblocks as a custody provider. It's a proven and reliable service that would store users' private keys and provide transaction signatures upon request. **Here are a few reasons why we chose Fireblocks:** 1. **Key Segmentation:** Instead of creating one complete key, MPC (Multi-Party Computation) generates several key shares. Each key share is stored separately and securely. 2. **Transaction Management:** To carry out a transaction, all parties (like different modules of your service) must consent. This is done by combining their separate key shares, but without fully disclosing them. 3. **Security:** The private key is never fully assembled in one place. Even if a hacker accesses one part of the key, they can't use it without the other parts. 4. **Flexibility and Control:** MPC wallets allow setting rules and policies for transactions, providing additional control over funds. Having ensured we had all the resources and tools to tackle the tasks at hand, we got started on the development! ## Development To get everything up and running, we needed to launch our own service (a Bundler) to repack traditional transactions and set up contracts (like a wallet, wallet factory, paymaster, etc.). The big decision was whether to build everything from scratch or use a service provider. Building from scratch seemed too much for a project at this stage. It could make the project much more expensive and take a lot longer. Also, there were risks: there were no proven bundler implementations available at that time, and making our own would be too hard and could drag the project on for too long. So, we looked at service providers. There were a few choices, and they mainly differed in what they had managed to develop. For example, ZeroDev only supported gas payment with USDT and PEPE, which wasn't enough for us. We then considered Alchemy, which had just started developing their bundler and already had a partnership with our client. Alchemy is also a well-respected brand in Web3, so we went with them. We were one of the first to work with them, so we experienced all the early challenges alongside their team. ## Project Summary We completed the project in six weeks, including research and extensive communication with the provider team and other services. After setting up the infrastructure for AA, we handed the code over to the in-house team. They focused on the frontend, connecting the on-ramp service, and other features. Two full-time Node.js developers worked on the project, supported by a tech lead who conducted code reviews and developed the system design of the service. The client received all the required functionality within the set deadlines, along with documentation and a technical demo to show investors and partners that the promises in the pitch decks were substantial. A pleasant bonus and a karmic plus was working with Alchemy and contributing to a product that, in our opinion, will be used by millions of people. Now, the MetaLamp team has a nearly out-of-the-box solution for implementing AA in any wallet or dApp, making the lives of users of these applications easier. **Subscribe to our weekly newsletter to receive the most interesting materials in your inbox. We don't include any ads in our newsletter, just content from our Magazine :)** ![article-logo](https://metalamp.io/images/article/logo.svg) ## More articles about web3 ## Custom Fields **reading time:** 6 **Article type:** articles **Article description:** In 2016, Vitalik Buterin first introduced the idea of account abstractions, and seven years later, in March 2023, we saw its implementation as the ERC-4337 standard. And in this piece, we'll talk about how such technology is implemented and how it solved a problem for one of our long-time clients. **Author (copy):** Nico Bordunenko