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
META TRANSACTIONS OVERVIEW

What are Meta Transactions (ERC-2771)?

Learn About Meta Transactions, How They're Used to Cover Gas Fees, and Why They're Not The Best Solution Anymore
Last Updated:
Table of Contents
Table of Contents
Table of Contents

{{aa-cta}}

All Ethereum transactions use gas, and the sender of each transaction must have enough Ether to pay for the gas spent. This forces new users to purchase Ether (which can be a daunting task) before they can start using a dapp. This is a major hurdle in user onboarding.

So-called “Meta transactions” made it possible to pay gas fees on behalf of users.

However, many such solutions are transitioning towards Account Abstraction (ERC-4337) infrastructure as it is a more promising and sophisticated way of gas abstraction with many more features!

What are Meta Transactions?

The idea of Meta Transactions is simple: a third party, called a Relayer, sends the transaction on behalf of the user and pays for the gas fees.

Users sign messages (preferably EIP-712 compliant) which have information about the transaction to be executed.

The signed message is passed to the Relayer who is then responsible to validate whether the Relayer will get paid or not (this could be optional more on this later), have enough funds to pay for gas fees, sign a native transaction and submit it for execution.

Let us understand Meta Transactions by taking OpenZepplin’s Relayer as an example:

a gif that shows how meta transactions work
A Step-by-step Guide on Meta Transactions

What Do Meta Transaction Request Look Like?

This is how a sample Meta Transaction Message looks...

code snippet of a meta transaction
Sample Meta Transaction

The above message mints an NFT and is to be signed by the from address 0x7099797...

Once the message is signed, the client (or user) can create a Meta Transaction request (seen below). This is sent as a POST request to the Autotask, a webhook that when invoked internally uses the Relayer private key to sign native transactions.

code snippet of meta transaction post request
Meta Transaction POST Request

What is the Meta Transaction Relayer?

A Relayer is an Ethereum Account containing the funds for sponsoring the user’s gas fees. The private key of the Account is stored in a secure vault on the provider’s server. 

The developer can then send funds to the Relayer, which will cover their user’s transaction fees.

Developers can spin up as many Relayers as they want, each of which need to be separately funded with ETH.

OZ Relay allows pausing the Relayer, accepting requests from Whitelisted Addresses, and Gas Price Capping. More conditional logic can be programmed into the Autotask if desired.

Keep in mind, the user-defined transaction now lives inside the data field of the Relayer’s native transaction. A Meta Transaction is this transaction inside of another transaction!

What is the MinimalForwarder in Meta Transactions?

Until now, no on-chain validation has been performed. This is where the MinimalForwarder comes in.

MinimalForwarder is an on-chain smart contract that validates the user-signed message to ensure validity and replay-protection.

struct ForwardRequest {
    address from;
    address to;
    uint256 value;
    uint256 gas;
    uint256 nonce;
    bytes data;
}

function verify(ForwardRequest calldata req, bytes calldata signature) public view returns (bool) {

    address signer = _hashTypedDataV4(
        keccak256(
            abi.encode(
                _TYPEHASH,
                req.from,
                req.to,
                req.value,
                req.gas,
                req.nonce,
                keccak256(req.data)
            )
        )
    ).recover(signature);

    return _nonces[req.from] == req.nonce && signer == req.from;
}

On successful validation, MinimalForwarder executes the transaction by making the call to the request contract with appropriate calldata

function execute(ForwardRequest calldata req, bytes calldata signature)
        public
        payable
        returns (bool, bytes memory)
{
    require(verify(req, signature), "MinimalForwarder: signature does not match request");
    _nonces[req.from] = req.nonce + 1;

    (bool success, bytes memory returndata) = req.to.call{gas: req.gas, value: req.value}(abi.encodePacked(req.data, req.from));

    // Validate that the relayer has sent enough gas for the call.
    // See 
    if (gasleft() <= req.gas / 63) {
        // We explicitly trigger invalid opcode to consume all gas and bubble-up the effects, since
        // neither revert or assert consume all gas since Solidity 0.8.0
        // 
        /// @solidity memory-safe-assembly
        assembly {
            invalid()
        }
    }

    return (success, returndata);
}

This is also where the disadvantages of Meta Transactions come into play because the contract being called by the MinimalForwarder needs to allow the MinimalForwarder to call the contract on behalf of the users.

What is ERC-2771?

Finally, when the call reaches the intended target contract, it needs to be able to figure the original user (msg.sender) and calldata (msg.data) which are nested inside of the Relayer’s transaction. To standardize this process ERC2771 was proposed.

OpenZepplin provides a utility contract called ERC2771Context to make it easy for the smart contract developer to extract the intended msg.sender and msg.data out of the data sent by the MinimalForwarder.

contract YourContract is ERC2771Context {
    constructor(MinimalForwarder forwarder, string memory uri_)
        ERC2771Context(address(forwarder))
    {}

    // Depending on whether the call is made by the `MinimalForwarder` or not the `msg.sender` and `msg.data` will be inferred accordingly

}

Because each smart contract must know how to read Meta Transactions, implementing them for already-deployed contracts is difficult and can lead to the introduction of bugs!

Even though there are many other Meta Transaction Infra services, all of them require the target contract to inherit EIP-712 or EIP-2771 based contract for deducing msg.sender and msg.data.

While this standard is great, it doesn’t work retroactively. This is why ERC-4337 was created, and is replacing most of the ERC-2771 solutions out there.

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
META TRANSACTIONS OVERVIEW

What are Meta Transactions (ERC-2771)?

Learn About Meta Transactions, How They're Used to Cover Gas Fees, and Why They're Not The Best Solution Anymore
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}}

All Ethereum transactions use gas, and the sender of each transaction must have enough Ether to pay for the gas spent. This forces new users to purchase Ether (which can be a daunting task) before they can start using a dapp. This is a major hurdle in user onboarding.

So-called “Meta transactions” made it possible to pay gas fees on behalf of users.

However, many such solutions are transitioning towards Account Abstraction (ERC-4337) infrastructure as it is a more promising and sophisticated way of gas abstraction with many more features!

What are Meta Transactions?

The idea of Meta Transactions is simple: a third party, called a Relayer, sends the transaction on behalf of the user and pays for the gas fees.

Users sign messages (preferably EIP-712 compliant) which have information about the transaction to be executed.

The signed message is passed to the Relayer who is then responsible to validate whether the Relayer will get paid or not (this could be optional more on this later), have enough funds to pay for gas fees, sign a native transaction and submit it for execution.

Let us understand Meta Transactions by taking OpenZepplin’s Relayer as an example:

a gif that shows how meta transactions work
A Step-by-step Guide on Meta Transactions

What Do Meta Transaction Request Look Like?

This is how a sample Meta Transaction Message looks...

code snippet of a meta transaction
Sample Meta Transaction

The above message mints an NFT and is to be signed by the from address 0x7099797...

Once the message is signed, the client (or user) can create a Meta Transaction request (seen below). This is sent as a POST request to the Autotask, a webhook that when invoked internally uses the Relayer private key to sign native transactions.

code snippet of meta transaction post request
Meta Transaction POST Request

What is the Meta Transaction Relayer?

A Relayer is an Ethereum Account containing the funds for sponsoring the user’s gas fees. The private key of the Account is stored in a secure vault on the provider’s server. 

The developer can then send funds to the Relayer, which will cover their user’s transaction fees.

Developers can spin up as many Relayers as they want, each of which need to be separately funded with ETH.

OZ Relay allows pausing the Relayer, accepting requests from Whitelisted Addresses, and Gas Price Capping. More conditional logic can be programmed into the Autotask if desired.

Keep in mind, the user-defined transaction now lives inside the data field of the Relayer’s native transaction. A Meta Transaction is this transaction inside of another transaction!

What is the MinimalForwarder in Meta Transactions?

Until now, no on-chain validation has been performed. This is where the MinimalForwarder comes in.

MinimalForwarder is an on-chain smart contract that validates the user-signed message to ensure validity and replay-protection.

struct ForwardRequest {
    address from;
    address to;
    uint256 value;
    uint256 gas;
    uint256 nonce;
    bytes data;
}

function verify(ForwardRequest calldata req, bytes calldata signature) public view returns (bool) {

    address signer = _hashTypedDataV4(
        keccak256(
            abi.encode(
                _TYPEHASH,
                req.from,
                req.to,
                req.value,
                req.gas,
                req.nonce,
                keccak256(req.data)
            )
        )
    ).recover(signature);

    return _nonces[req.from] == req.nonce && signer == req.from;
}

On successful validation, MinimalForwarder executes the transaction by making the call to the request contract with appropriate calldata

function execute(ForwardRequest calldata req, bytes calldata signature)
        public
        payable
        returns (bool, bytes memory)
{
    require(verify(req, signature), "MinimalForwarder: signature does not match request");
    _nonces[req.from] = req.nonce + 1;

    (bool success, bytes memory returndata) = req.to.call{gas: req.gas, value: req.value}(abi.encodePacked(req.data, req.from));

    // Validate that the relayer has sent enough gas for the call.
    // See 
    if (gasleft() <= req.gas / 63) {
        // We explicitly trigger invalid opcode to consume all gas and bubble-up the effects, since
        // neither revert or assert consume all gas since Solidity 0.8.0
        // 
        /// @solidity memory-safe-assembly
        assembly {
            invalid()
        }
    }

    return (success, returndata);
}

This is also where the disadvantages of Meta Transactions come into play because the contract being called by the MinimalForwarder needs to allow the MinimalForwarder to call the contract on behalf of the users.

What is ERC-2771?

Finally, when the call reaches the intended target contract, it needs to be able to figure the original user (msg.sender) and calldata (msg.data) which are nested inside of the Relayer’s transaction. To standardize this process ERC2771 was proposed.

OpenZepplin provides a utility contract called ERC2771Context to make it easy for the smart contract developer to extract the intended msg.sender and msg.data out of the data sent by the MinimalForwarder.

contract YourContract is ERC2771Context {
    constructor(MinimalForwarder forwarder, string memory uri_)
        ERC2771Context(address(forwarder))
    {}

    // Depending on whether the call is made by the `MinimalForwarder` or not the `msg.sender` and `msg.data` will be inferred accordingly

}

Because each smart contract must know how to read Meta Transactions, implementing them for already-deployed contracts is difficult and can lead to the introduction of bugs!

Even though there are many other Meta Transaction Infra services, all of them require the target contract to inherit EIP-712 or EIP-2771 based contract for deducing msg.sender and msg.data.

While this standard is great, it doesn’t work retroactively. This is why ERC-4337 was created, and is replacing most of the ERC-2771 solutions out there.

All Ethereum transactions use gas, and the sender of each transaction must have enough Ether to pay for the gas spent. This forces new users to purchase Ether (which can be a daunting task) before they can start using a dapp. This is a major hurdle in user onboarding.

So-called “Meta transactions” made it possible to pay gas fees on behalf of users.

However, many such solutions are transitioning towards Account Abstraction (ERC-4337) infrastructure as it is a more promising and sophisticated way of gas abstraction with many more features!

What are Meta Transactions?

The idea of Meta Transactions is simple: a third party, called a Relayer, sends the transaction on behalf of the user and pays for the gas fees.

Users sign messages (preferably EIP-712 compliant) which have information about the transaction to be executed.

The signed message is passed to the Relayer who is then responsible to validate whether the Relayer will get paid or not (this could be optional more on this later), have enough funds to pay for gas fees, sign a native transaction and submit it for execution.

Let us understand Meta Transactions by taking OpenZepplin’s Relayer as an example:

a gif that shows how meta transactions work
A Step-by-step Guide on Meta Transactions

What Do Meta Transaction Request Look Like?

This is how a sample Meta Transaction Message looks...

code snippet of a meta transaction
Sample Meta Transaction

The above message mints an NFT and is to be signed by the from address 0x7099797...

Once the message is signed, the client (or user) can create a Meta Transaction request (seen below). This is sent as a POST request to the Autotask, a webhook that when invoked internally uses the Relayer private key to sign native transactions.

code snippet of meta transaction post request
Meta Transaction POST Request

What is the Meta Transaction Relayer?

A Relayer is an Ethereum Account containing the funds for sponsoring the user’s gas fees. The private key of the Account is stored in a secure vault on the provider’s server. 

The developer can then send funds to the Relayer, which will cover their user’s transaction fees.

Developers can spin up as many Relayers as they want, each of which need to be separately funded with ETH.

OZ Relay allows pausing the Relayer, accepting requests from Whitelisted Addresses, and Gas Price Capping. More conditional logic can be programmed into the Autotask if desired.

Keep in mind, the user-defined transaction now lives inside the data field of the Relayer’s native transaction. A Meta Transaction is this transaction inside of another transaction!

What is the MinimalForwarder in Meta Transactions?

Until now, no on-chain validation has been performed. This is where the MinimalForwarder comes in.

MinimalForwarder is an on-chain smart contract that validates the user-signed message to ensure validity and replay-protection.

struct ForwardRequest {
    address from;
    address to;
    uint256 value;
    uint256 gas;
    uint256 nonce;
    bytes data;
}

function verify(ForwardRequest calldata req, bytes calldata signature) public view returns (bool) {

    address signer = _hashTypedDataV4(
        keccak256(
            abi.encode(
                _TYPEHASH,
                req.from,
                req.to,
                req.value,
                req.gas,
                req.nonce,
                keccak256(req.data)
            )
        )
    ).recover(signature);

    return _nonces[req.from] == req.nonce && signer == req.from;
}

On successful validation, MinimalForwarder executes the transaction by making the call to the request contract with appropriate calldata

function execute(ForwardRequest calldata req, bytes calldata signature)
        public
        payable
        returns (bool, bytes memory)
{
    require(verify(req, signature), "MinimalForwarder: signature does not match request");
    _nonces[req.from] = req.nonce + 1;

    (bool success, bytes memory returndata) = req.to.call{gas: req.gas, value: req.value}(abi.encodePacked(req.data, req.from));

    // Validate that the relayer has sent enough gas for the call.
    // See 
    if (gasleft() <= req.gas / 63) {
        // We explicitly trigger invalid opcode to consume all gas and bubble-up the effects, since
        // neither revert or assert consume all gas since Solidity 0.8.0
        // 
        /// @solidity memory-safe-assembly
        assembly {
            invalid()
        }
    }

    return (success, returndata);
}

This is also where the disadvantages of Meta Transactions come into play because the contract being called by the MinimalForwarder needs to allow the MinimalForwarder to call the contract on behalf of the users.

What is ERC-2771?

Finally, when the call reaches the intended target contract, it needs to be able to figure the original user (msg.sender) and calldata (msg.data) which are nested inside of the Relayer’s transaction. To standardize this process ERC2771 was proposed.

OpenZepplin provides a utility contract called ERC2771Context to make it easy for the smart contract developer to extract the intended msg.sender and msg.data out of the data sent by the MinimalForwarder.

contract YourContract is ERC2771Context {
    constructor(MinimalForwarder forwarder, string memory uri_)
        ERC2771Context(address(forwarder))
    {}

    // Depending on whether the call is made by the `MinimalForwarder` or not the `msg.sender` and `msg.data` will be inferred accordingly

}

Because each smart contract must know how to read Meta Transactions, implementing them for already-deployed contracts is difficult and can lead to the introduction of bugs!

Even though there are many other Meta Transaction Infra services, all of them require the target contract to inherit EIP-712 or EIP-2771 based contract for deducing msg.sender and msg.data.

While this standard is great, it doesn’t work retroactively. This is why ERC-4337 was created, and is replacing most of the ERC-2771 solutions out there.

{{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