Enabling meta transactions inside your contract is a powerful addition. Requiring users to hold ETH to pay for gas has always been and still is one of the biggest user onboarding challenges. Who knows how many more people would be using Ethereum right now if it was just a simple click?

But sometimes the solution can be added meta transaction capability inside your contracts. The implementation might be easier than you think.



Let's took at the high-level description first.

Meta XKCD

What are meta-transactions?

A meta transaction is a regular Ethereum transaction which contains another transaction, the actual transaction. The actual transaction is signed by a user and then sent to an operator or something similar, no gas and blockchain interaction required. The operator takes this signed transaction and submits it to the blockchain paying for the fees himself.

The contract ensures there's a valid signature on the actual transaction and then executes it.

High-level overview

If we want to support generalized meta-transactions in our contract, it can be done with a few simple steps. On a high-level, there are two steps to it.

Step 1: Verify the signature of the meta-transaction. We'll do this by creating a hash following the EIP-712 standard and ecrecover.

solidity
Open in Remix 
bool isValidSignature = ecrecover(hash(transaction), v, r, s) == transaction.signerAddress

Step 2: After verifying the intended signed action, the historical design executes the encoded function through address(this).delegatecall. This is still a new EVM call frame. DELEGATECALL runs the target code in the caller’s storage and address context and preserves the calling frame’s msg.sender and msg.value; it does not automatically replace the relayer with the signer.

The design’s explicit sender context therefore needs careful scoping and cleanup. It must not leak across nested calls or be mistaken for independent authorization. Current forwarder/context libraries have their own documented trust and delegatecall constraints.

solidity
Open in Remix 
(bool didSucceed, bytes memory returnData) = address(this).delegatecall(transaction.data);

That's it for the most part. But there are some critical things to verify and also alternatives for the signature.

Let's look into more details.

Transaction execution in detail

As we've seen the heart of the execution is the delegatecall. This is where the actual transaction is executed. But to ensure proper execution, we have to make sure some things are correct.

Transaction Struct

First let's look at the data inside our Transaction struct on the right. It contains all the relevant requirements set by the user and the transaction itself which is to be executed as the bytes data. This is what's passed from the user to the operator to the contract.

solidity
Open in Remix 
struct Transaction {
    uint256 salt;
    uint256 expirationTimeSeconds;
    uint256 gasPrice;
    address signerAddress;
    bytes data;
}

Typed Transaction Hash

We'll further need to compute a hash over all this data. This is used for the signature scheme and to prevent double execution of the same transaction. For details about this look at the end in the signature explanation.

This is the transaction schema hash:

solidity
Open in Remix 
EIP712_TRANSACTION_SCHEMA_HASH = keccak256(
    abi.encodePacked("Transaction(uint256 salt,uint256 expirationTimeSeconds,uint256 gasPrice,address signerAddress,bytes data)")
);

This is the EIP712 schema hash and can be computed once in the constructor of the contract.

solidity
Open in Remix 
function _getTransactionTypedHash(
    Transaction memory transaction
) private view returns (bytes32) {
    return keccak256(abi.encode(
        EIP712_TRANSACTION_SCHEMA_HASH,
        transaction.salt,
        transaction.expirationTimeSeconds,
        transaction.gasPrice,
        transaction.signerAddress,
        keccak256(transaction.data)
    ));
}

We can use that to compute the full typed transaction hash using keccak256 and abi.encodePacked.

By hashing all relevant values, we can ensure that only exactly what the original user signed would result in a successful transaction execution. If  for example the operator was to change just 1 second inside expirationTimeSeconds, it would not work anymore.

This is just the first part of the hash, for the full details including the requirements for a secure signature, read the part about signatures below.

Setting correct msg.sender

If we just execute delegatecall, the msg.sender of the transaction would still be the operator of the meta transaction, not the original signer.

We can solve this by setting a context variable:

solidity
Open in Remix 
function _setCurrentContextAddressIfRequired(address contextAddress) private {
    currentContextAddress = contextAddress;
}

function _getCurrentContextAddress() private view returns (address) {
    return currentContextAddress == address(0) ? msg.sender : currentContextAddress;
}

Everywhere you would use the msg.sender in your contract, you would now instead call _getCurrentContextAddress().

The execution wrapper must restore the context on every successful path and revert coherently on failure. Every authorization-sensitive entry point must use the intended context consistently. A context variable plus delegatecall is not a complete forwarding framework; review the maintained ERC2771 implementation and its documented call-context constraints before choosing a new design.

Preventing multiple wrapped transactions

Matryoshka

Another thing we want to prevent is executing a meta-meta-transaction. (unless you want to be cool for no reason)

It serves no purpose and just wastes additional gas. So we can add the check before any transaction execution:

solidity
Open in Remix 
require(currentContextAddress == address(0), "META_TX: Transaction has context set already");

Ensuring transaction requirements are met

We'll further make sure that all defined requirements are met:

  • An expiration time is useful, so the user knows a transaction is not executed months later when he doesn't expect it anymore.
  • A transactionsExecuted mapping to ensure a meta transaction is only executed once. Note: Mark the transaction consumed before executing its calls, and revert the whole operation on failure.
  • A defined gas price by the user. This might not be required in your system. Since the gas is paid by the operator, the only reason for enforcing some gas price would be if the value has some further effect inside the transaction. For example in 0x the gas price will affect the fee prices.
solidity
Open in Remix 
require(block.timestamp < transaction.expirationTimeSeconds, "META_TX: Meta transaction is expired");
require(!transactionsExecuted[transactionHash], "META_TX: Transaction already executed");
require(tx.gasprice == transaction.gasPrice, "META_TX: Gas price not matching required gas price");

Verifying the signature

Of course we only want to execute transactions with a valid signature. A naive solution may only take the transaction.data and sign that.

But...

  • how do we ensure all additional transaction parameters are set correctly (expiration, salt, signer...) ?
  • how do we prevent a signed transaction from being used multiple times?


The first part is easy, we create a hash over all those values as shown above with the _getTransactionTypedHash function. The second part needs the application’s consumed-hash or nonce tracking; EIP-712 alone does not prevent replay. You can see how we create a hash from the transaction data and additional EIP-712 data below:

solidity
Open in Remix 
function _getFullTransactionTypedHash(Transaction memory transaction) private view returns (bytes32) {
    bytes32 transactionStructHash = _getTransactionTypedHash(transaction);

    bytes2 EIP191_HEADER = 0x1901;
    bytes32 schemaHash = keccak256(abi.encodePacked("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"));
    uint256 chainId = block.chainid;
    address verifyingContract = address(this);
    bytes32 domainHash = keccak256(abi.encode(
        schemaHash,
        keccak256(bytes("My Protocol Name")),
        keccak256(bytes("1.0.0")),
        chainId,
        verifyingContract
    ));
    
    return keccak256(abi.encodePacked(EIP191_HEADER, domainHash, transactionStructHash));
}

We put additional information into our hash, so that a signed transaction may only be used for exactly this contract with the given chainId. For all the details, check out the EIP or my previous post on ERC20-Permit.

Okay now we have the full transaction hash and the signature from the user. We can obtain the three values r and s which are the elliptic curve signature values inside our signature by extracting the bytes32 values with a helper. The uint8 v value requires only a simple conversion.

Using ecrecover with our given signature and the transaction hash, we compute a signer address. If this address matches the set transaction.signerAddress, the signature is indeed valid.

solidity
Open in Remix 
// Import @openzeppelin/contracts/utils/cryptography/SignatureChecker.sol.
// Fragment: Transaction and the correctly computed digest are defined above.
function _isValidTransactionWithHashSignature(
    Transaction memory transaction,
    bytes32 txHash,
    bytes memory signature
) private view returns (bool) {
    return transaction.signerAddress != address(0) &&
        SignatureChecker.isValidSignatureNow(
            transaction.signerAddress, txHash, signature
        );
}
solidity
Open in Remix 
function _readBytes32(
        bytes memory b, uint256 index
) private pure returns (bytes32 result) {
    require(
        b.length >= index + 32,
        "META_TX: Invalid index for given bytes"
    );

    // Arrays are prefixed by
    // a 256 bit length parameter
    index += 32;

    // Read the bytes32 from array memory
    assembly {
        result := mload(add(b, index))
    }
    return result;
}

This is the regular signature scheme. It works perfectly if you have a user signing his own transaction.

But what if you want to allow smart contracts to create valid signatures?

Advanced signature schemes

An arguably more advanced use case is having smart contracts sign meta transactions, but imagine a user has his funds inside a multi signature smart contract. This is already quite common for certain wallets. This user cannot sign a transaction with the EIP-712 scheme to create a valid v, r, s signature.

This is where EIP-1271 comes in. It allows a smart contract to verify a signature. The standard itself doesn't say anything about how the contract may do this. The only definition is the function signature, given as:
solidity
Open in Remix 
function isValidSignature(
    bytes32 hash,
    bytes memory signature
) public view returns (bytes4);

where the return value is 0x1626ba7e for a valid signature. It is up to the smart contract developer to decide on how to implement the signature logic.

So how can we verify such a signature?

You can see an example implementation on the right. Using staticcall, we can ensure no further state modifications happen in the call. If the result succeeds and has a valid returnData length (this is very critical, see the previous 0x bug), we can check if the return value matches 0x1626ba7e.

solidity
Open in Remix 
function _staticCallEIP1271Wallet(
    address verifyingContractAddress,
    bytes32 data,
    bytes memory signature
) private view returns (bool) {
    bytes memory callData = abi.encodeWithSelector(
        IEIP1271Wallet.isValidSignature.selector,
        data,
        signature
    );

    (bool didSucceed, bytes memory returnData)
       = verifyingContractAddress.staticcall(callData);
    require(
        didSucceed && returnData.length == 32,
        "META_TX: EIP1271 call failed"
    );

    bytes4 returnedValue = _readBytes4(returnData, 0);
    return returnedValue == 0x1626ba7e;
}

You may want to allow further methods for signatures like pre-signing or having operators that can sign on behalf of a user. See the existing types in 0x here for some inspiration.

Implementing it yourself

So far we've seen the critical parts for all the implementation. This should give you a good idea on how to implement this. I would further recommend looking at

  1. the 0x meta transaction implementation here
  2. the Openzeppelin EIP-712 support here
  3. the npm eip-712 lib to implement the signing part here


The OpenZeppelin EIP712 library is now part of the regular library, but has additional support for the case of forks where the chain id could change. Also take a look at the 0x code where a lot of the implementation in this blog post comes from.