How to Set Up the Infrastructure for Smart Contract Wallets
Account abstraction introduces new components to smart contract wallets, including user operations, bundlers, paymasters, and entry point contracts. Learn how to build a custom infrastructure for smart contract wallets and bring these components together.
In this post
What do you get when you move away from the private-public key parings and move toward smart contracts? You get a simple, flexible, accessible, and more secure way to manage your transactions through smart contract wallets.
Standard smart contract wallets have proven to be complex due to their incompatibility and migration limitations. Prior to EIP-4337, they weren’t standardized, which hindered their adoption and flexibility.
Account-abstracted wallets, on the other hand, bring significant improvements in user experience. And instead of requiring any changes to Ethereum, smart contract wallets based on the account abstraction system introduce a few new components, specifying the actions and the flow when using them.
So, if you’re ready to build wallets that put users first, start by learning more about each component. Then, discover how to set up the infrastructure for your smart contract wallets without making any changes to your dapp.
What’s different about account-abstracted smart contract wallets?
Account abstraction introduces a few new components to the logic of smart account wallets. Let’s dive into each one. 🔎
User operations are one of the key differences between account-abstracted and regular smart contract wallets. In the case of account-abstracted wallets, users send transactions in the form of
UserOperation objects to the alternative mempool.
UserOperations contain the same parameters as regular transactions, including the sender, calldata, nonce, signature, and others. However, when compared to regular transactions,
UserOperations also include a few additional fields necessary for their validation, gas payments, and paymaster subsidization. They also cannot call certain forbidden opcodes.
Paymasters allow developers or third parties to subsidize users’ fees and enable gas payments in ERC-20 tokens. A paymaster can contain a deposit that’s used for paying gas fees and a stake that’s locked to prevent a malicious DoS attempt.
However, not all paymasters can send requests. Bundlers first need to accept a paymaster, so only whitelisted paymasters can provide support.
Bundlers can be block builders or users that can send transactions to block builders. They listen to the alternative mempool and gather the submitted UserOperations into a bundle. Bundlers gather
UserOperation objects in the form of a
Additionally, bundlers run simulations to ensure that a
UserOperation won’t revert because it calls the forbidden opcodes. It also uses simulations to estimate the amount of gas needed for the
UserOperation to be successful.
When managing transactions through account wallets, simulations ensure the validity of a
UserOperation and its ability to pay for its execution. Plus, running a simulation also helps ensure that everything would execute exactly the same once sent on-chain.
The simulation of a
UserOperation takes place before adding the
UserOperation to the mempool and submitting it into a bundle:
- Before sending it to the alternative mempool: The client receives a UserOperation and performs multiple checks to ensure everything is properly configured. Then, it runs an op simulation to ensure everything executes as planned. If it does, the client submits the
UserOperationto the alternative mempool.
- Before submitting it into a bundle: The client also runs a simulation upon bundling multiple
UserOperations. Bundlers perform the
simulateValidationfunction by calling an RPC method. This allows bundlers to validate the operation signature and ensure that all fees are paid.
Once the client runs the simulation, the method returns a successful response in the form of
ValidationResult. In the event of an error, the client can reject the submitted
validatePaymasterUserOp may return a specific time range during which a
UserOperation is valid on-chain. If a
UserOperation has a short time frame that wouldn’t last until the next block is mined, the client may drop the
Incorporating our simulation infrastructure into your wallet allows you to determine the validity of user operations and whether the paymaster would pay for them before initiating the entire flow on-chain.
Entry point contracts
An entry point contract executes UserOperation bundles. A bundler sends the
handleOps call to the entry point contract. The
handleOps then goes through the verification and execution loops:
- Verification loop: First, the
handleOpsfunction creates an account if it doesn’t exist yet. It then starts the verification process by calling
validateUserOpand requests the validation of the operation signature.
During this loop, the
handleOpsfunction checks whether the paymaster has enough deposit within the entry point contract to cover the costs. It also confirms whether the paymaster is willing to do so.
- Execution loop: The
handleOpscalls the account with the calldata of the submitted
UserOperation. The account parses the data and then executes the remaining calls, one by one.
The overview of the flow
Before you start setting up the infrastructure for all of the above, here’s a short overview of the entire process:
- You send your transaction a.k.a.
UserOperationand ask the paymaster to sponsor it.
- The paymaster simulates the
UserOperationto determine whether it meets the required criteria.
- If the
UserOperationmeets the criteria and is successfully simulated, the paymaster can accept to sponsor it.
- Once you receive the response from the paymaster, you need to approve that your
UserOperationcan spend a specified amount of tokens for its execution.
UserOperationgoes to the alternative mempool where any bundler can decide to include it in its bundle.
- The bundler that picks up your
UserOperationsimulates it to make sure it’s valid and that it doesn’t call any forbidden opcodes.
- The bundler gathers multiple
UserOperationsand sends them to the entry point smart contract.
handeOpsfunction of the entry point contract executes every
UserOperationon-chain after making sure they’re valid, signed, and not already executed.
How to set up the infrastructure for smart contract wallets with Web3 Actions
Okay, now that you’re familiar with all the components, let’s see how to set up the infrastructure for your smart contract wallet. With Tenderly’s full-stack infrastructure, you can automate and streamline the entire process, integrate all of the components into your dapp, and not make any changes to your existing logic along the way.
So, ready to set things in motion? We start with Tenderly Web3 Actions. 😎
For example, if you want to send a mint operation with a specific parameter, you can set up a Web3 Action to automatically call a simulation. It will simulate this transaction, validate the value of your
UserOperation, and then send it to the Paymaster if everything executes successfully.
By setting up a Web3 Action, you can automate the entire process of managing transactions through smart contract wallets. You can do this either by:
- Building everything from scratch: If you’d like to set up everything yourself, you can build your entire system on Tenderly’s infrastructure using Web3 Actions.
- Calling external APIs through Web3 Actions: In this case, you can use a webhook trigger for your Web3 Action that will interact with your external API endpoints.
How to set up the wallet infrastructure with Node Extensions
But what if you want to integrate the Web3 Action infrastructure into your dapp in a more flexible way? To achieve this, you can use Tenderly Node Extensions, an innovative way to build and deploy custom JSON-RPC methods.
Node Extensions are connected to Web3 Actions and allow you to call the Action you created for your wallet infrastructure through Tenderly Web3 Gateway, our Node-as-a-Service solution. This way, you actually customize how you interact with the blockchain while not having to modify your dapp logic at all.
Plus, Node Extensions come with a public library where you can find ready-to-use examples. So, aside from creating your own extensions, you can use three predefined extensions from Pimlico for Paymaster integration:
- The first Node Extension helps you fetch the list of supported entry point contracts on the network you’re working on.
- The second Node Extension checks whether the paymaster is willing to pay for a user operation.
- The third Node Extension asks the paymaster to pay for a user operation.
Feel free to submit it to our community-sourced library, and our team will review it. If approved, we’ll add it to our library so other developers in the community can integrate it into their smart contract wallets.
Build custom infrastructure for your smart account wallets
It’s only a matter of time before all smart contract wallets adopt the account abstraction functionalities. Why wait for this to happen when you can start building user-friendly wallets now and stay one step ahead? But instead of working around preset APIs and trying to think of alternative solutions, set up an infrastructure that fits your product, and not the other way around.
Tenderly’s full-stack infrastructure enables you to build a custom, flexible, and scalable infrastructure through Web3 Actions, Node Extensions, and simulations. Better yet, you can seamlessly connect different components using Tenderly without having to change your existing logic.
Start building with Tenderly and get greater control, flexibility, and support throughout the entire process.
Use Tenderly DevNets to build, test, and debug smart contracts against production data of 30+ EVM networks. Get an unlimited faucet, reusable YAML templates, and built-in debugging tools to deploy on-chain faster.Start building with DevNets!
Subscribe to our newsletter