Meta Transactions

This document is better viewed at https://docs.openzeppelin.com/contracts/api/metatx

Core

ERC2771Context 

import "@openzeppelin/contracts/metatx/ERC2771Context.sol";

Context variant with ERC2771 support.

Functions

constructor(address trustedForwarder) internal

isTrustedForwarder(address forwarder) → bool public

_msgSender() → address sender internal

_msgData() → bytes internal

Utils

ERC2771Forwarder 

import "@openzeppelin/contracts/metatx/ERC2771Forwarder.sol";

A forwarder compatible with ERC2771 contracts. See ERC2771Context.

This forwarder operates on forward requests that include:

  • from: An address to operate on behalf of. It is required to be equal to the request signer.

  • to: The address that should be called.

  • value: The amount of native token to attach with the requested call.

  • gas: The amount of gas limit that will be forwarded with the requested call.

  • nonce: A unique transaction ordering identifier to avoid replayability and request invalidation.

  • deadline: A timestamp after which the request is not executable anymore.

  • data: Encoded msg.data to send with the requested call.

Relayers are able to submit batches if they are processing a high volume of requests. With high throughput, relayers may run into limitations of the chain such as limits on the number of transactions in the mempool. In these cases the recommendation is to distribute the load among multiple accounts.

Security Considerations

If a relayer submits a forward request, it should be willing to pay up to 100% of the gas amount specified in the request. This contract does not implement any kind of retribution for this gas, and it is assumed that there is an out of band incentive for relayers to pay for execution on behalf of signers. Often, the relayer is operated by a project that will consider it a user acquisition cost.

By offering to pay for gas, relayers are at risk of having that gas used by an attacker toward some other purpose that is not aligned with the expected out of band incentives. If you operate a relayer, consider whitelisting target contracts and function selectors. When relaying ERC-721 or ERC-1155 transfers specifically, consider rejecting the use of the data field, since it can be used to execute arbitrary code.

Functions
Nonces
EIP712
Events
IERC5267

constructor(string name) public

See EIP712.constructor.

verify(struct ERC2771Forwarder.ForwardRequestData request) → bool public

Returns true if a request is valid for a provided signature at the current block timestamp.

A transaction is considered valid when it hasn’t expired (deadline is not met), and the signer matches the from parameter of the signed request.

A request may return false here but it won’t cause executeBatch to revert if a refund receiver is provided.

execute(struct ERC2771Forwarder.ForwardRequestData request) public

Executes a request on behalf of `signature’s signer using the ERC-2771 protocol. The gas provided to the requested call may not be exactly the amount requested, but the call will not run out of gas. Will revert if the request is invalid or the call reverts, in this case the nonce is not consumed.

Requirements:

  • The request value should be equal to the provided msg.value.

  • The request should be valid according to verify.

executeBatch(struct ERC2771Forwarder.ForwardRequestData[] requests, address payable refundReceiver) public

Batch version of execute with optional refunding and atomic execution.

In case a batch contains at least one invalid request (see verify), the request will be skipped and the refundReceiver parameter will receive back the unused requested value at the end of the execution. This is done to prevent reverting the entire batch when a request is invalid or has already been submitted.

If the refundReceiver is the address(0), this function will revert when at least one of the requests was not valid instead of skipping it. This could be useful if a batch is required to get executed atomically (at least at the top-level). For example, refunding (and thus atomicity) can be opt-out if the relayer is using a service that avoids including reverted transactions.

Requirements:

  • The sum of the requests' values should be equal to the provided msg.value.

  • All of the requests should be valid (see verify) when refundReceiver is the zero address.

Setting a zero refundReceiver guarantees an all-or-nothing requests execution only for the first-level forwarded calls. In case a forwarded request calls to a contract with another subcall, the second-level call may revert without the top-level call reverting.

_validate(struct ERC2771Forwarder.ForwardRequestData request) → bool alive, bool signerMatch, address signer internal

Validates if the provided request can be executed at current block timestamp with the given request.signature on behalf of request.signer.

_recoverForwardRequestSigner(struct ERC2771Forwarder.ForwardRequestData request) → address internal

Recovers the signer of an EIP712 message hash for a forward request and its corresponding signature. See ECDSA.recover.

_execute(struct ERC2771Forwarder.ForwardRequestData request, bool requireValidRequest) → bool success internal

Validates and executes a signed request returning the request call success value.

Internal function without msg.value validation.

Requirements:

  • The caller must have provided enough gas to forward with the call.

  • The request must be valid (see verify) if the requireValidRequest is true.

Emits an ExecutedForwardRequest event.

Using this function doesn’t check that all the msg.value was sent, potentially leaving value stuck in the contract.

ExecutedForwardRequest(address indexed signer, uint256 nonce, bool success) event

Emitted when a ForwardRequest is executed.

An unsuccessful forward request could be due to an invalid signature, an expired deadline, or simply a revert in the requested call. The contract guarantees that the relayer is not able to force the requested call to run out of gas.
← Interfaces
Proxy →