# Merging EOA and AA Roadmaps

## Abstract
Making ERC-4337 compatible with EOA accounts using ERC-3074

## Motivation
There is an activate debate on the next steps towards account abstraction as well as for EOA accounts.
The consensus is that we want the improvements to be aligned in the same direction and eventually meet.

The leading EOA improvement proposals on the table are EIP-3074 and EIP-5806.
EIP-3074 allows for execution delagation and gas sponsorship while EIP-5806 allows only for execution delagation.

### Solving EIP-3074's centralization risks
There were some concerns that only centralized relayers will enable EIP-3074 and so the ecosystem will be pushed towards them.
This proposal enables EOAs using EIP-3074 to leverage ERC-4337's decentralized ecosystem of relayers and paymasters.

### Standardizing user operation intents around ERC-4337
Having EIP-3074 transactions fully compatible with the standard execution flow of ERC-4337 userops, leverages all the developer tools and ecosystem that has emerged to support it.
Making it much easier to be supported by explorers, wallets, and SDKs.
As well as making the path simpler to implement protocol level inclusion lists.

## Specification

### UserOperation Changes
Add a new property to `PackedUserOperation`: `invoker` of type `address`

### EntryPoint Changes
If `invoker` is specified:
* In the validation loop, verify the signature field is a valid EIP-3074 AUTH signature for the `invoker` address, with the `commit` being equal to the `userOpHash`, signed by `sender`
* In the execution loop, call `validateUserOp` and the `UserOperation`'s calldata to the `invoker` adress instead of to the `sender` address

Note: it's alternatively possible to pack the `invoker` into the `signature` field for gas eficiency for non EIP-3074 UserOps.

## Benefits
### Short term
1. Sponsored transcations, batching and general execution of EVM code on EOA accounts using EIP-3074
2. Decentralized relay and paymaster option using modified EIP-4337
3. Minimal change to EIP-4337 with - impacting mostly the `EntryPoint` (and UO)
4. Security risk of EIP-3074 reduced to be similar to EIP-5806

### Long Term
1. Battle testing for IAccount smart accounts via EOAs as well as AA users
2. ERC-4337 and EIP-3074 are both advancing IAccount compatible smart account implementations - making it easier for the ecosystem to adopt it
3. Enshrining of ERC-4337 will be easier following wide adoption
4. Simpler path to protocol level inclusion lists

## Security Considerations
### Security risk of indefinite authorization to an ERC-3074 Invoker contract
It has been suggested, but we don't believe it was documented that EIP-3074 can be amended so that the authorization is limited to one call - in similar fashion to EIP-5806. That can be part of the overall solution described here.

**Update:** limiting AUTH to current nonce has been introduced to the EIP-3074 proposal.

## Disclaimer
The approach described here is a high level design idea meant to initiate a more detailed discussion.