Update EIP-5806: refactor motivations

Merged by EIP-Bot.

EIPS/eip-5806.md

@@ -17,18 +17,22 @@ This EIP adds a new transaction type that allows EOAs to execute arbitrary code
 
 ## Motivation
 
-Account abstraction has been extensively discussed but the path toward mainstream adoption is still unclear. Some approaches, such as [EIP-4337](./eip-4337.md) hope to improve the usability of smart wallets, without addressing the issue of smart wallet support by applications. [EIP-3074](./eip-3074.md) proposes another approach that favors existing EOAs but comes with replay risks.
+EOA are the most widely used of account, yet their ability to perform operation is limited to deploying contracts and sending call transaction. It is currently not possible for an EOA to execute arbitrary code, which greatly limits the interractions users can have witht he blockchain. Account abstraction has been extensively discussed but the path toward mainstream adoption is still unclear. Some approaches, such as [ERC-4337](./eip-4337.md) hope to improve the usability of smart wallets, without addressing the issue of smart wallet support by applications. [EIP-3074](./eip-3074.md) proposes another approach that favors existing EOAs but comes with replay risks.
 
-This EIP proposes a simpler approach that addresses some of the objectives of account abstraction for EOAs with minimal change over the EVM. By allowing EOAs to perform delegate calls to a contract (similarly to how contracts can delegate calls to other contracts using [EIP-7](./eip-7.md)), EOAs will be able to have more control over what operations they want to execute.
+While smart contract wallets have a lot to offer in terms of UX, it is unlikelly that all users will migrate any time soon because of the associated cost and the fact that some EOA have custody of non-transferable assets.
 
-Performing a delegate call to a multicall contract (such as the one deployed to `0xcA11bde05977b3631167028862bE2a173976CA11`), EOAs would be able to batch multiple transactions into a single one, while being the `msg.sender` of all the sub calls. Other unforeseen logic could be implemented in smart contracts and used by EOA. This includes emitting events, using storage under the EOA's account, or even deploying contracts using `create2`.
+This EIP proposes an approach to allow EOA executing abritrary code, with minimal change over the EVM, and using the same security model users are used to. By allowing EOAs to perform delegate calls to a contract (similarly to how contracts can delegate calls to other contracts using [EIP-7](./eip-7.md)), EOAs will be able to have more control over what operations they want to execute. This proposal goal is NOT to provide an account abstraction primitive, though it would enable some usescases that fall in the scope of account abstraction.
+
+Performing a delegate call to a multicall contract (such as the one deployed to `0xcA11bde05977b3631167028862bE2a173976CA11`), EOAs would be able to batch multiple transactions into a single one, while being the `msg.sender` of all the sub calls. Other unforeseen logic could be implemented in smart contracts and used by EOA. This includes deploying contracts using `create2`, emitting events or using storage under the EOA's account.
 
 This EIP doesn't aim to replace other account abstraction proposals. It hopes to be an easy-to-implement alternative that would significantly improve the user experience of EOA owners in the near future.
 
 ## Specification
+
 The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
 
 ### Parameters
+
 - `FORK_BLKNUM` = `TBD`
 - `TX_TYPE` = TBD, > 0x02 ([EIP-1559](./eip-1559.md))
 
@@ -58,7 +62,9 @@ This EIP would drastically expand the ability of EOAs to interact with smart con
 
 ## Backwards Compatibility
 
-No known backward compatibility issues thanks to the transaction envelope ([EIP-2718](./eip-2718.md))
+No known backward compatibility issues thanks to the transaction envelope ([EIP-2718](./eip-2718.md)).
+
+Due to the inclusion logic and the gas cost being similar to type 2 transactions, it should be possible to include this new transaction type in the same mempool.
 
 ## Security Considerations
 
@@ -67,4 +73,5 @@ The nonce mechanism, already used in other transaction types, prevents replay at
 Contracts being called through this mechanism can execute any operation on behalf of the signer. Signers should be extremely careful signing this transaction (just like any other transaction).
 
 ## Copyright
+
 Copyright and related rights waived via [CC0](../LICENSE.md).