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

## Abstract

[ERC-2771](./eip-2771.md) is a commonly-used standard for meta-transactions that uses one or more trusted forwarders. This EIP extends [ERC-2771](./eip-2771.md) 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](./eip-2771.md).

### Forwarder Interface

```solidity
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](./eip-2771.md#extracting-the-transaction-signer-address) 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](./eip-20.md)'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](./eip-20.md) would be extended with the following functions:

```solidity
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.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).