Network
Launch Date
Consensus
Note
Sepolia
Oct 2021
PoW
Like-for-like representation of Ethereum
Görli
Jan 2019
PoA
Proof-of-Authority
Kiln
Mar 2022
PoS
Post-Merge (for ETH2), shadow fork of the mainnet
Kintsugi
Dec 2021
PoS
DEPRECATED, use Kiln; post-Merge (for ETH2)
Ropsten
Nov 2016
PoW
DEPRECATED, use Sepolia; the Merge to happen on Jun 8, 2022
Rinkeby
Apr 2017
PoA
DEPRECATED, use Görli and Görli Faucet
Kovan
Mar 2017
PoA
DEPRECATED, use Sepolia or Görli
List of active and deprecated Ethereum testnets, including Kintsugi.
Features
Optimistic rollup 
ZK-rollup 
Proof
Uses fraud proofs to prove transaction validity. 
Uses validity (zero-knowledge) proofs to prove transaction validity. 
Capital efficiency
Requires waiting through a 1-week delay (dispute period) before withdrawing funds. 
Users can withdraw funds immediately because validity proofs provide incontrovertible evidence of the authenticity of off-chain transactions. 
Data compression
Publishes full transaction data as calldata to Ethereum Mainnet, which increases rollup costs. 
Doesn't need to publish transaction data on Ethereum because ZK-SNARKs and ZK-STARKs already guarantee the accuracy of the rollup state. 
EVM compatibility
Uses a simulation of the Ethereum Virtual Machine (EVM), which allows it to run arbitrary logic and support smart contracts. 
Doesn't widely support EVM computation, although a few EVM-compatible ZK-rollups have appeared. 
Rollup costs
Reduces costs since it publishes minimal data on Ethereum and doesn't have to post proofs for transactions, except in special circumstances. 
Faces higher overhead from costs involved in generating and verifying proofs for every transaction block. ZK proofs require specialized, expensive hardware to create and have high on-chain verification costs. 
Trust assumptions
Doesn't require a trusted setup. 
Requires a trusted setup to work. 
Liveness requirements
Verifiers are needed to keep tabs on the actual rollup state and the one referenced in the state root to detect fraud. 
Users don't need someone to watch the L2 chain to detect fraud. 
Security properties 
Relies on cryptoeconomic incentives to assure users of rollup security. 
Relies on cryptographic guarantees for security. 
Start building
on Alchemy.
Sign up for free
Start building on Optimism.
Sign up for free
Start building on Arbitrum.
Sign up for free
Start building on Ethereum.
Sign up for free
Start building on Polygon.
Sign up for free
Start building on Starknet.
Sign up for free
Start building on Flow.
Sign up for free
kiln faucet
Get free Kiln ETH.
Start building today
Goerli faucet
Get free Goerli ETH.
Start building today
SEPOLIA FAUCET
Get free Sepolia ETH.
Start Building Today
mumbai faucet
Get free Mumbai Matic.
Start building today
rinkeby faucet
Get free Rinkeby
ETH.
Start building today
Start building on Ethereum.
Get started for free
Start building on Ethereum.
Get started for free
Start building on Flow.
Get started for free
Start building on Polygon.
Get started for free
Start building on Starknet.
Get started for free
Start building on Optimism.
Get started for free
Start building on Solana.
Get started for free
Start building on Solana.
Sign up for beta access
Start building on Solana.
Join the waitlist
Arbitrum logo
Start building on Arbitrum.
Get started for free
Build with Alchemy's
Gas Manager & Bundler APIs
Learn
Solidity at
Alchemy
University
Get started today
Build with Alchemy's
Gas Manager & Bundler APIs
curl 
https://release.solana.com/v1.10.32/solana-install-init-x86_64-pc-windows-msvc.exe 
--output 
C:\solana-install-tmp\solana-install-init.exe 
--create-dirs
Account Abstraction
ERC-4337 vs. ERC-2771

Account Abstraction (ERC-4337) vs. Meta Transactions (ERC-2771)

Learn The Reasons Why Developers Are Adopting Account Abstraction Over Meta Transactions
Last Updated:
Table of Contents
Table of Contents
Table of Contents

{{aa-cta}}

Meta Transactions and Account Abstraction are different techniques for improving the user experience of Ethereum’s gas fees.

How is Account Abstraction different from Meta Transactions?

Account Abstraction aims to abstract away more complexities of the Ethereum Account than just gas fees. 

From a technical perspective, the difference between meta transactions and Account Abstraction lies in the structure of the message and its backwards compatibility.

What are UserOps in Account Abstraction?

In the case of Meta Transactions, the industry standard was to use EIP712-based messages, which required all smart contracts to be upgraded. 

Account Abstraction standardizes a special transaction format called UserOperations.

UserOperation contains all the information needed to figure out what transaction the user intends to perform, including fields to decide which Paymaster to use, how much the user is willing to pay (in case of self-sponsorship), and the signed UserOperation.

What are Paymasters in Account Abstraction?

The Gas abstraction portion of the ERC-4337 Account Abstraction standard introduces Paymasters.

Paymasters are onchain smart contracts that have arbitrary validation logic which can be used to define a valid gas sponsorship. Again, the difference here is the execution is onchain.

DAOs, dapps, and other teams can deploy their own custom paymasters with features such as ERC-20 gas payments and more.

These custom Paymasters can use ERC-4337 to plug and play with existing Bundler Services. This is different from Meta Transactions which require Provider adoption.

Relayers vs. Paymasters

While Relayers in the Meta Transaction concept are private keys under the control of Infra providers, Account Abstraction Bundlers are standardized nodes. Switching between different Bundlers is as simple as changing API keys and API URLs.

There is no concept of MinimalForwarder in Account Abstraction as sponsorship validation is done onchain inside the Paymaster contract.

Instead of having only one transaction inside a native transaction in the case of Meta Transaction, Bundlers bundle multiple UserOperations into one bundle (one native transaction)!

5 Benefits of Account Abstraction over Meta Transactions

1. No Smart Contract Changes are Required

While Meta Transactions require updates to all existing contracts that would adopt them, Account Abstraction builds on existing infrastructure. This means that all smart contracts by default support Account Abstraction, which makes it a preferred option over Meta Transactions.

2. Frictionless Switching Between Bundler and Paymaster Services

Under ERC-4337, all Bundlers and Paymasters communicate following specific standards. Teams can even create their own Paymasters with conditional logic for their application.

3. No Need to Adopt Proprietary Relayers

Proprietary Relayers lack consistency; each Relayer can have their own message format for their use case. This leads to smart contract changes being required to become compatible with each different Relayer.

4. More Decentralization

As more providers make their Bundler services available, the developer gains the ability to decentralize their transaction flow. This also affords the developer the opportunity to abandon any sub-par Bundlers. 

5. No Developer Tooling Lock-in

When using Meta Transactions you also need to use the Infra provider’s SDK. This leads to tooling lock-in that adds to the friction when migrating Relayers.

In the case of Account Abstraction, all the standard functionality is supported by all SDKs allowing one to select based on their expertise and switch based on preference!

Moreover, since the UserOperation standard is to be adopted by every vendor, building tools like UserOperation Explorers is also feasible.

How to Update Meta Transactions to Account Abstraction?

If you have already made changes to your smart contracts in order to support Meta Transactions, the migration process is simple to revert those changes.

Unlike Meta Transactions, msg.sender and msg.data can be used as-is with Account Abstraction.

If custom Paymasters or Account Factories are desired, their development becomes the next step in migrating.

For standard implementations, we recommended using well-audited, existing AA providers in order to reduce development time and self-imposed bugs.

Alchemy’s Gas Manager provides granular controls like Per Address Gas Usage limits, Max number of UserOperations to sponsor, Allowlisting addresses, Sponsorship deadlines, and Domain level allowlisting!

Alchemy Gas Manager's Spending Rules UI
Alchemy Gas Manager's Spending Rules UI
Gas Manager's UI Continued
Gas Manager's UI Continued

Gas Manager Admin API allow programmatically creating, reading and updating the Gas policies. On top of everything, the developer gets a great visual dashboard of every UserOperation sponsored!

Gas Manager Spending Dashboard
Gas Manager Spending Dashboard
Gas Manager Operations View
Gas Manager Operations View

Conclusion

Account Abstraction (ERC-4337) is the new and better way of incorporating gasless transactions into your dapps with benefits like avoiding contract-level code changes, frictionless vendor switching, composability with other existing infrastructure, and more decentralization.

ALCHEMY SUPERNODE - ETHEREUM NODE API

Scale to any size, without any errors

Alchemy Supernode finally makes it possible to scale blockchain applications without all the headaches. Plus, our legendary support will guide you every step of the way.

Get started for free
Supernode footer
Account Abstraction
ERC-4337 vs. ERC-2771

Account Abstraction (ERC-4337) vs. Meta Transactions (ERC-2771)

Learn The Reasons Why Developers Are Adopting Account Abstraction Over Meta Transactions
Last Updated:
Last Updated:
June 1, 2023
Don't miss an update
Sign up for our newsletter to get alpha, key insights, and killer resources.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Table of Contents

Talk to an Expert

Learn how Alchemy's blockchain developer tools can help your business succeed in web3!
Valid number
Thank you! An Alchemy expert will be in touch with you shortly!
Oops! Something went wrong while submitting the form.

{{aa-cta}}

Meta Transactions and Account Abstraction are different techniques for improving the user experience of Ethereum’s gas fees.

How is Account Abstraction different from Meta Transactions?

Account Abstraction aims to abstract away more complexities of the Ethereum Account than just gas fees. 

From a technical perspective, the difference between meta transactions and Account Abstraction lies in the structure of the message and its backwards compatibility.

What are UserOps in Account Abstraction?

In the case of Meta Transactions, the industry standard was to use EIP712-based messages, which required all smart contracts to be upgraded. 

Account Abstraction standardizes a special transaction format called UserOperations.

UserOperation contains all the information needed to figure out what transaction the user intends to perform, including fields to decide which Paymaster to use, how much the user is willing to pay (in case of self-sponsorship), and the signed UserOperation.

What are Paymasters in Account Abstraction?

The Gas abstraction portion of the ERC-4337 Account Abstraction standard introduces Paymasters.

Paymasters are onchain smart contracts that have arbitrary validation logic which can be used to define a valid gas sponsorship. Again, the difference here is the execution is onchain.

DAOs, dapps, and other teams can deploy their own custom paymasters with features such as ERC-20 gas payments and more.

These custom Paymasters can use ERC-4337 to plug and play with existing Bundler Services. This is different from Meta Transactions which require Provider adoption.

Relayers vs. Paymasters

While Relayers in the Meta Transaction concept are private keys under the control of Infra providers, Account Abstraction Bundlers are standardized nodes. Switching between different Bundlers is as simple as changing API keys and API URLs.

There is no concept of MinimalForwarder in Account Abstraction as sponsorship validation is done onchain inside the Paymaster contract.

Instead of having only one transaction inside a native transaction in the case of Meta Transaction, Bundlers bundle multiple UserOperations into one bundle (one native transaction)!

5 Benefits of Account Abstraction over Meta Transactions

1. No Smart Contract Changes are Required

While Meta Transactions require updates to all existing contracts that would adopt them, Account Abstraction builds on existing infrastructure. This means that all smart contracts by default support Account Abstraction, which makes it a preferred option over Meta Transactions.

2. Frictionless Switching Between Bundler and Paymaster Services

Under ERC-4337, all Bundlers and Paymasters communicate following specific standards. Teams can even create their own Paymasters with conditional logic for their application.

3. No Need to Adopt Proprietary Relayers

Proprietary Relayers lack consistency; each Relayer can have their own message format for their use case. This leads to smart contract changes being required to become compatible with each different Relayer.

4. More Decentralization

As more providers make their Bundler services available, the developer gains the ability to decentralize their transaction flow. This also affords the developer the opportunity to abandon any sub-par Bundlers. 

5. No Developer Tooling Lock-in

When using Meta Transactions you also need to use the Infra provider’s SDK. This leads to tooling lock-in that adds to the friction when migrating Relayers.

In the case of Account Abstraction, all the standard functionality is supported by all SDKs allowing one to select based on their expertise and switch based on preference!

Moreover, since the UserOperation standard is to be adopted by every vendor, building tools like UserOperation Explorers is also feasible.

How to Update Meta Transactions to Account Abstraction?

If you have already made changes to your smart contracts in order to support Meta Transactions, the migration process is simple to revert those changes.

Unlike Meta Transactions, msg.sender and msg.data can be used as-is with Account Abstraction.

If custom Paymasters or Account Factories are desired, their development becomes the next step in migrating.

For standard implementations, we recommended using well-audited, existing AA providers in order to reduce development time and self-imposed bugs.

Alchemy’s Gas Manager provides granular controls like Per Address Gas Usage limits, Max number of UserOperations to sponsor, Allowlisting addresses, Sponsorship deadlines, and Domain level allowlisting!

Alchemy Gas Manager's Spending Rules UI
Alchemy Gas Manager's Spending Rules UI
Gas Manager's UI Continued
Gas Manager's UI Continued

Gas Manager Admin API allow programmatically creating, reading and updating the Gas policies. On top of everything, the developer gets a great visual dashboard of every UserOperation sponsored!

Gas Manager Spending Dashboard
Gas Manager Spending Dashboard
Gas Manager Operations View
Gas Manager Operations View

Conclusion

Account Abstraction (ERC-4337) is the new and better way of incorporating gasless transactions into your dapps with benefits like avoiding contract-level code changes, frictionless vendor switching, composability with other existing infrastructure, and more decentralization.

Meta Transactions and Account Abstraction are different techniques for improving the user experience of Ethereum’s gas fees.

How is Account Abstraction different from Meta Transactions?

Account Abstraction aims to abstract away more complexities of the Ethereum Account than just gas fees. 

From a technical perspective, the difference between meta transactions and Account Abstraction lies in the structure of the message and its backwards compatibility.

What are UserOps in Account Abstraction?

In the case of Meta Transactions, the industry standard was to use EIP712-based messages, which required all smart contracts to be upgraded. 

Account Abstraction standardizes a special transaction format called UserOperations.

UserOperation contains all the information needed to figure out what transaction the user intends to perform, including fields to decide which Paymaster to use, how much the user is willing to pay (in case of self-sponsorship), and the signed UserOperation.

What are Paymasters in Account Abstraction?

The Gas abstraction portion of the ERC-4337 Account Abstraction standard introduces Paymasters.

Paymasters are onchain smart contracts that have arbitrary validation logic which can be used to define a valid gas sponsorship. Again, the difference here is the execution is onchain.

DAOs, dapps, and other teams can deploy their own custom paymasters with features such as ERC-20 gas payments and more.

These custom Paymasters can use ERC-4337 to plug and play with existing Bundler Services. This is different from Meta Transactions which require Provider adoption.

Relayers vs. Paymasters

While Relayers in the Meta Transaction concept are private keys under the control of Infra providers, Account Abstraction Bundlers are standardized nodes. Switching between different Bundlers is as simple as changing API keys and API URLs.

There is no concept of MinimalForwarder in Account Abstraction as sponsorship validation is done onchain inside the Paymaster contract.

Instead of having only one transaction inside a native transaction in the case of Meta Transaction, Bundlers bundle multiple UserOperations into one bundle (one native transaction)!

5 Benefits of Account Abstraction over Meta Transactions

1. No Smart Contract Changes are Required

While Meta Transactions require updates to all existing contracts that would adopt them, Account Abstraction builds on existing infrastructure. This means that all smart contracts by default support Account Abstraction, which makes it a preferred option over Meta Transactions.

2. Frictionless Switching Between Bundler and Paymaster Services

Under ERC-4337, all Bundlers and Paymasters communicate following specific standards. Teams can even create their own Paymasters with conditional logic for their application.

3. No Need to Adopt Proprietary Relayers

Proprietary Relayers lack consistency; each Relayer can have their own message format for their use case. This leads to smart contract changes being required to become compatible with each different Relayer.

4. More Decentralization

As more providers make their Bundler services available, the developer gains the ability to decentralize their transaction flow. This also affords the developer the opportunity to abandon any sub-par Bundlers. 

5. No Developer Tooling Lock-in

When using Meta Transactions you also need to use the Infra provider’s SDK. This leads to tooling lock-in that adds to the friction when migrating Relayers.

In the case of Account Abstraction, all the standard functionality is supported by all SDKs allowing one to select based on their expertise and switch based on preference!

Moreover, since the UserOperation standard is to be adopted by every vendor, building tools like UserOperation Explorers is also feasible.

How to Update Meta Transactions to Account Abstraction?

If you have already made changes to your smart contracts in order to support Meta Transactions, the migration process is simple to revert those changes.

Unlike Meta Transactions, msg.sender and msg.data can be used as-is with Account Abstraction.

If custom Paymasters or Account Factories are desired, their development becomes the next step in migrating.

For standard implementations, we recommended using well-audited, existing AA providers in order to reduce development time and self-imposed bugs.

Alchemy’s Gas Manager provides granular controls like Per Address Gas Usage limits, Max number of UserOperations to sponsor, Allowlisting addresses, Sponsorship deadlines, and Domain level allowlisting!

Alchemy Gas Manager's Spending Rules UI
Alchemy Gas Manager's Spending Rules UI
Gas Manager's UI Continued
Gas Manager's UI Continued

Gas Manager Admin API allow programmatically creating, reading and updating the Gas policies. On top of everything, the developer gets a great visual dashboard of every UserOperation sponsored!

Gas Manager Spending Dashboard
Gas Manager Spending Dashboard
Gas Manager Operations View
Gas Manager Operations View

Conclusion

Account Abstraction (ERC-4337) is the new and better way of incorporating gasless transactions into your dapps with benefits like avoiding contract-level code changes, frictionless vendor switching, composability with other existing infrastructure, and more decentralization.

{{aa-cta}}

Contact Us

Talk to an expert at Alchemy to answer all of your product questions.
Valid number
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Build blockchain magic with Alchemy

Alchemy combines the most powerful web3 developer products and tools with resources, community and legendary support.

Get started for free