DCIPs/eip-6315.md at 5600364df7ae65d4922220be8637caeb47b826d1

3.4 KiB

Raw Blame History

eip	title	description	author	discussions-to	status	type	category	created	requires
6315	ERC-2771 Account Abstraction	A variant of ERC-2771 that does not require forwarders to be trusted	Gavin John (@Pandapip1)	https://ethereum-magicians.org/t/trustless-eip-2771/12497	Draft	Standards Track	ERC	2023-01-11	2771

Abstract

ERC-2771 is a commonly-used standard for meta-transactions that uses one or more trusted forwarders. This EIP extends ERC-2771 to provide support for trustless account abstraction.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

The key words "Trusted Forwarder", and "Recipient" in this document are to be interpreted as described in ERC-2771.

Forwarder Interface

pragma solidity ^0.8.0;

interface IForwarder {
    function isForwardedTransaction() external view returns (bool)
}

Extracting the Sender and Forwarder

When a function of a Recipient is called, the Recipient MUST staticcall the isForwardedTransaction() function of the caller. If this either reverts or returns the boolean value false, the transaction MUST be treated normally, with the sender being the caller, and the Forwarder set to the zero address. If this returns the boolean value true, the transaction MUST be considered a forwarded transaction with the sender being extracted using the same procedure that ERC-2771 uses to extract the "Transaction Signer", and the Forwarder set to the caller.

Recipient Extensions

When a Recipient contract takes, as a parameter of a function, an address, the Recipient should include a new function with the same name as the the original function, but with Abstract appended to the end, that takes two addresses there instead. The first address represents the Forwarder, and the second address represents the address under the control of that Forwarder. If more than one address parameter is taken (for example, ERC-20's transferFrom), only the function that takes two addresses for each address parameter is needed. The original function should have the same effect as the overloaded function with the forwarder addresses set to the zero address.

For example, ERC-20 would be extended with the following functions:

function transferAbstract(address toForwarder, address toAddress, uint256 amount);
function approveAbstract(address spenderForwarder, address spenderAddress, uint256 amount);
function transferFromAbstract(address fromForwarder, address fromAddress, address toForwarder, address toAddress, uint256 amount);

Rationale

The choice to simply add new address parameters to every existing EIP instead of making new interfaces for the most commonly used EIPs is to maximize the general applicability of this EIP.

Backwards Compatibility

Existing contracts will not be able to take advantage of this EIP. This is also true of ERC-2771.

Security Considerations

A tradeoff is made: Forwarders do not need to be trusted by Recipients, but do need to be trusted by the users that use them with one or more accounts.

3.4 KiB Raw Blame History