Account Abstraction on EVMs
Last updated
Last updated
Ethereum and other Ethereum virtual machine (EVM) compatible networks require transactions to be originated from an externally owned account (EOA) and for that account to pay the gas fees for the transaction in the native cryptocurrency of the chain (for example, Ether in the case of Ethereum). Blockchain users pay gas in order to purchase scarce block space and fund the chain, incentivizing validators to participate in securing the network.
For projects operating primarily over tokens or NFTs, however, requiring a native cryptocurrency balance to fund transactions introduces onboarding friction. Additionally, ensuring end-user wallets are sufficiently funded to execute transactions creates ongoing operational overhead. For these reasons, the notion of “gasless” or "sponsored" transactions has been an area of ongoing debate for a number of years. Unfortunately, the Ethereum community has failed to settle on a single standard nor enshrined this capability in the layer 1 protocol, leaving developers to contend with various approaches and weigh trade-offs depending on their specific use case.
Various approaches to achieving sponsored transactions are outlined below.
One of the newest approaches to enabling sponsored transactions on EVM chains is to use paymasters as specified in , Account Abstraction (AA). AA separates (or abstracts) authentication against smart contract wallets from the requirements of the underlying protocol (specifically ECDSA/secp256k1 signatures). Additionally, it specifies standards for executing sponsored transactions using smart contracts called paymasters.
Transactions in AA are encapsulated in a higher level format called user operations and submitted to an off chain network of bundlers which batch and send them to the chain through a singleton entry point contract. Every user operation must be signed before it can be submitted to the chain. Increasingly, Dfns customers are relying on our advanced MPC solution to ensure secure and highly available signing of user operations.
The Dfns engineering team has built proofs of concept (POCs) to demonstrate how to integrate our MPC signing with various partners offering AA platforms.
Biconomy is a web3 infrastructure provider offering a full stack solution for AA. You can read about their solution . Dfns has built a sample integration which processes a gasless transaction on the Mumbai testnet. You can find a Readme and the full code as well as in the Biconomy documentation .
In addition to being the industry-leading Smart Account, Safe also supports ERC-4337 via Modules and the FallbackHandler with a flow documented . The extends the Safe Smart Account to enable ERC-4337 compliant transactions, received via the proxy contract. This functionality is exposed via the Relay Kit in the Safe{Core} SDK - check on how to integrate it. To use Dfns with Safe AA, simply use our to sign User Operations sent through your bundler to the Safe proxy.
If you control the target smart contact and can support this interface or if you have validated your target contract already supports 2771, there are a number of relayer providers you can work with in order to sponsor transactions on behalf of your users and provide a gasless user experience while signing transactions with Dfns. The following are a few examples.
The final approach to enabling gasless transactions is simply to transfer the required amount of the native cryptocurrency into each end users' wallet, relieving them from the responsibility of acquiring it themselves. In most cases, implementations of this approach specify a "gas tank" wallet which automatically sends cryptocurrency to other wallets when they fall below a given threshold.
The primary problem with this approach is the cost of sending each individual "refuel" transaction on chain. Looking at the economics on the Ethereum L1, it does not scale well as demonstrated in the calculations below:
ZeroDev is a 4337 provider offering Bundler and Paymaster services as described in . Dfns has built a sample integration demonstrating a sponsored transaction using our viem wrapper which is available . Follow to begin an integration.
Meta-transactions are an earlier attempt to enable sponsored transactions as specified in . In this approach, end user transactions are forwarded off-chain to relayers that fund gas cost in exchange for a fee. The primary caveat is the target contract must support the standard by implementing the interface which replaces the built in msg.sender variable with a _MsgSender() function. This implementation extracts the original sender from the call data to prevent the relayer address from being used in its place.
GSN is an open-source public good funded by the Ethereum Foundation and built by the authors of ERC-2771 to help promote the standard. They offer detailed on configuring a relayer and have published a sample to demonstrate the changes required to make a smart contract compatible with 2771. They even have a . You can reach out to the GSN team in with any questions.
Biconomy is one of the longest standing players in the relayer market. They offer a to enable sponsored transactions. They have on implementing the 2771 standard as well as funding deposits via their . They also cover the steps required to . Feel free to with any questions specific to their offering.
Gelato describes themselves as "web3’s decentralized backend" and provides a number of services to enhance smart contracts, including 2771 compatible relayers. They expose a centralized funding service called . Once an account is funded, it can be used to sponsor transactions on behalf of users by implementing as detailed in their documentation. Please contact Gelato directly with questions pertaining to their specific configuration.
If you're interested in implementing sponsored transactions or have a novel approach to the problem, don't hesitate to reach out to us as this is one of our favorite topics of discussion. As always, feel free to send us feedback at .
