How to Set Up the Infrastructure for Smart Contract Wallets

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

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

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

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 handleOps call.

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.

Simulations

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 UserOperation to the alternative mempool.
• Before submitting it into a bundle: The client also runs a simulation upon bundling multiple UserOperations. Bundlers perform the simulateValidation function 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 UserOperation.

Additionally, validateUserOp or 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 UserOperation.

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 handleOps function creates an account if it doesn’t exist yet. It then starts the verification process by calling validateUserOp and requests the validation of the operation signature.
  
  During this loop, the handleOps function 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 handleOps calls 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:

1. You send your transaction a.k.a. UserOperation and ask the paymaster to sponsor it.
2. The paymaster simulates the UserOperation to determine whether it meets the required criteria.
3. If the UserOperation meets the criteria and is successfully simulated, the paymaster can accept to sponsor it.
4. Once you receive the response from the paymaster, you need to approve that your UserOperation can spend a specified amount of tokens for its execution.
5. The UserOperation goes to the alternative mempool where any bundler can decide to include it in its bundle.
6. The bundler that picks up your UserOperation simulates it to make sure it’s valid and that it doesn’t call any forbidden opcodes.
7. The bundler gathers multiple UserOperations and sends them to the entry point smart contract.
8. The handeOps function of the entry point contract executes every UserOperation on-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. 😎

Web3 Actions are a serverless backend for your dapps. You can use JavaScript or Typescript to write custom code, and a Web3 Action will automatically execute it once specified conditions are met.

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:

1. 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.
2. 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:

1. The first Node Extension helps you fetch the list of supported entry point contracts on the network you’re working on.
2. The second Node Extension checks whether the paymaster is willing to pay for a user operation.
3. The third Node Extension asks the paymaster to pay for a user operation.

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.