ERC-7758: Transfer With Authorization

Abstract

---

A set of functions to enable meta-transactions and atomic interactions with ERC-20 token contracts via signatures conforming to the EIP-712 typed message signing specification.

This enables the user to:

• delegate the gas payment to someone else,
• pay for gas in the token itself rather than in ETH,
• perform one or more token transfers and other operations in a single atomic transaction,
• transfer ERC-20 tokens to another address, and have the recipient submit the transaction,
• batch multiple transactions with minimal overhead, and
• create and perform multiple transactions without having to worry about them failing due to accidental nonce-reuse or improper ordering by the miner.

Motivation

---

There is an existing spec, EIP-2612, that also allows meta-transactions, and it is encouraged that a contract implements both for maximum compatibility. The two primary differences between this spec and EIP-2612 are that:

• EIP-2612 uses sequential nonces, but this uses random 32-byte nonces, and that
• EIP-2612 relies on the ERC-20 approve/transferFrom ("ERC-20 allowance") pattern.

The biggest issue with the use of sequential nonces is that it does not allow users to perform more than one transaction at time without risking their transactions failing, because:

• DApps may unintentionally reuse nonces that have not yet been processed in the blockchain.
• Miners may process the transactions in the incorrect order.

This can be especially problematic if the gas prices are very high and transactions often get queued up and remain unconfirmed for a long time. Non-sequential nonces allow users to create as many transactions as they want at the same time.

The ERC-20 allowance mechanism is susceptible to the multiple withdrawal attack, and encourages antipatterns such as the use of the "infinite" allowance. The wide-prevalence of upgradeable contracts have made the conditions favorable for these attacks to happen in the wild.

The deficiencies of the ERC-20 allowance pattern brought about the development of alternative token standards such as the ERC-777. However, they haven't been able to gain much adoption due to compatibility and potential security issues.

Specification

---

Event

Optional:

The arguments v, r, and s must be obtained using the EIP-712 typed message signing spec.

Example:

With the domain separator, the typehash, which is used to identify the type of the EIP-712 message being used, and the values of the parameters, you are able to derive a Keccak-256 hash digest which can then be signed using the token holder's private key.

Example:

Smart contract functions that wrap receiveWithAuthorization call may choose to reduce the number of arguments by accepting the full ABI-encoded set of arguments for the receiveWithAuthorization call as a single argument of the type bytes.

Example:

Use with web3 providers

The signature for an authorization can be obtained using a web3 provider with the eth_signTypedData{_v4} method.

Example:

Rationale

---

Unique Random Nonce, Instead of Sequential Nonce

One might say transaction ordering is one reason why sequential nonces are preferred. However, sequential nonces do not actually help achieve transaction ordering for meta transactions in practice:

• For native Ethereum transactions, when a transaction with a nonce value that is too-high is submitted to the network, it will stay pending until the transactions consuming the lower unused nonces are confirmed.
• However, for meta-transactions, when a transaction containing a sequential nonce value that is too high is submitted, instead of staying pending, it will revert and fail immediately, resulting in wasted gas.
• The fact that miners can also reorder transactions and include them in the block in the order they want (assuming each transaction was submitted to the network by different meta-transaction relayers) also makes it possible for the meta-transactions to fail even if the nonces used were correct. (e.g. User submits nonces 3, 4 and 5, but miner ends up including them in the block as 4,5,3, resulting in only 3 succeeding)
• Lastly, when using different applications simultaneously, in absence of some sort of an off-chain nonce-tracker, it is not possible to determine what the correct next nonce value is if there exists nonces that are used but haven't been submitted and confirmed by the network.
• Under high gas price conditions, transactions can often "get stuck" in the pool for a long time. Under such a situation, it is much more likely for the same nonce to be unintentionally reused twice. For example, if you make a meta-transaction that uses a sequential nonce from one app, and switch to another app to make another meta-transaction before the previous one confirms, the same nonce will be used if the app relies purely on the data available on-chain, resulting in one of the transactions failing.
• In conclusion, the only way to guarantee transaction ordering is for relayers to submit transactions one at a time, waiting for confirmation between each submission (and the order in which they should be submitted can be part of some off-chain metadata), rendering sequential nonce irrelevant.

Valid After and Valid Before

• Relying on relayers to submit transactions for you means you may not have exact control over the timing of transaction submission.
• These parameters allow the user to schedule a transaction to be only valid in the future or before a specific deadline, protecting the user from potential undesirable effects that may be caused by the submission being made either too late or too early.

EIP-712

• EIP-712 ensures that the signatures generated are valid only for this specific instance of the token contract and cannot be replayed on a different network with a different chain ID.
• This is achieved by incorporating the contract address and the chain ID in a Keccak-256 hash digest called the domain separator. The actual set of parameters used to derive the domain separator is up to the implementing contract, but it is highly recommended that the fields verifyingContract and chainId are included.

Backwards Compatibility

---

New contracts benefit from being able to directly utilize this proposal in order to create atomic transactions, but existing contracts may still rely on the conventional ERC-20 allowance pattern (approve/transferFrom).

In order to add support for this proposal to existing contracts ("parent contract") that use the ERC-20 allowance pattern, a forwarding contract ("forwarder") can be constructed that takes an authorization and does the following:

1. Extract the user and deposit amount from the authorization
2. Call receiveWithAuthorization to transfer specified funds from the user to the forwarder
3. Approve the parent contract to spend funds from the forwarder
4. Call the method on the parent contract that spends the allowance set from the forwarder
5. Transfer the ownership of any resulting tokens back to the user

Example:

Reference Implementation

---

EIP7758.sol

IERC20Transfer.sol

EIP712Domain.sol

EIP712.sol

Security Considerations

---

Use receiveWithAuthorization instead of transferWithAuthorization when calling from other smart contracts. It is possible for an attacker watching the transaction pool to extract the transfer authorization and front-run the transferWithAuthorization call to execute the transfer without invoking the wrapper function. This could potentially result in unprocessed, locked up deposits. receiveWithAuthorization prevents this by performing an additional check that ensures that the caller is the payee. Additionally, if there are multiple contract functions accepting receive authorizations, the app developer could dedicate some leading bytes of the nonce could as the identifier to prevent cross-use.

When submitting multiple transfers simultaneously, be mindful of the fact that relayers and miners will decide the order in which they are processed. This is generally not a problem if the transactions are not dependent on each other, but for transactions that are highly dependent on each other, it is recommended that the signed authorizations are submitted one at a time.

The zero address must be rejected when using ecrecover to prevent unauthorized transfers and approvals of funds from the zero address. The built-in ecrecover returns the zero address when a malformed signature is provided.

Copyright

---

Copyright and related rights waived via CC0.