AA-524: Update ERC-4337 and ERC-7769 with EIP-712 and EIP-7702 support

ERCS/erc-4337.md

@@ -8,7 +8,7 @@ status: Draft
 type: Standards Track
 category: ERC
 created: 2021-09-29
-requires: 7562
+requires: 712, 7562, 7702, 7769
 ---
 
 ## Abstract
@@ -210,7 +210,9 @@ The entry point method is `handleOps`, which handles an array of userOps
 
 The entry point's `handleOps` function must perform the following steps (we first describe the simpler non-paymaster case). It must make two loops, the **verification loop** and the **execution loop**. In the verification loop, the `handleOps` call must perform the following steps for each `UserOperation`:
 
-* **Create the account if it does not yet exist**, using the initcode provided in the `UserOperation`. If the account does not exist, _and_ the initcode is empty, or does not deploy a contract at the "sender" address, the call must fail.
+* **Create the account if it does not yet exist**, using the initcode provided in the `UserOperation`.
+  * If the account is an EOA with an [EIP-7702](./eip-7702.md) authorization designation, the EntryPoint validates the authorized address matches the one specified in the UserOperation signature (see [Support for [EIP-7702] authorizations](support-for-eip-7702-authorizations)).
+  * If the account does not exist, _and_ the initcode is empty, or does not deploy a contract at the "sender" address, the call must fail.
 * calculate the maximum possible fee the account needs to pay (based on validation and call gas limits, and current gas values)
 * calculate the fee the account must add to its "deposit" in the EntryPoint
 * **Call `validateUserOp` on the account**, passing in the `UserOperation`, its hash and the required fee. The account should verify the operation's signature, and pay the fee if the account considers the operation valid. If any `validateUserOp` call fails, `handleOps` must skip execution of at least that operation, and may revert entirely.
@@ -230,6 +232,37 @@ In the execution loop, the `handleOps` call must perform the following steps for
 Before accepting a `UserOperation`, bundlers should use an RPC method to locally call the `simulateValidation` function on the entry point, to verify that the signature is correct and the operation actually pays fees; see the [Simulation section below](#simulation) for details.
 A node/bundler SHOULD drop (not add to the mempool) a `UserOperation` that fails the validation
 
+
+### Support for [EIP-712](./eip-712.md) signatures
+
+The `userOpHash` is calculated as an [EIP-712] typed message hash with the following parameters:
+
+```solidity
+bytes32 constant TYPE_HASH =
+    keccak256(
+        "EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"
+    );
+
+bytes32 constant PACKED_USEROP_TYPEHASH =
+    keccak256(
+        "PackedUserOperation(address sender,uint256 nonce,bytes initCode,bytes callData,bytes32 accountGasLimits,uint256 preVerificationGas,bytes32 gasFees,bytes paymasterAndData)"
+    );
+```
+
+### Support for [EIP-7702] authorizations
+
+On networks with the EIP-7702 enabled, the `eth_sendUserOperation` method accepts an extra `eip7702auth` parameter.
+If this parameter is set, the bundler should add it to the authorizationList for for this transaction.
+Seperately, the hash calculation is updated to include the current [EIP-7702] delegate
+
+If the `initCode` field starts with `0xef0100`, and this account was deployed using an EIP-7702 transaction, then the hash is calculated as follows:
+
+* For the purpose of hash calculation, the first 20 bytes of the `initCode` field of the `UserOperation` are set to account's EIP-7702 delegate address (fetched with EXTCODECOPY)
+* The `initCode` is not used to call a factory contract.
+* If the `initCode` is longer than 20 bytes (and starting with `0xef0100`), then the rest of the initCode is used to call an initialization function in the acocunt itself.
+
+Note that a UserOperation may still be executed without such initCode. In this case the EntryPoint doesn't hash the current [EIP-7702 delegate], and can be potentially executed against a modified account.
+
 ### Extension: paymasters
 
 We extend the entry point logic to support **paymasters** that can sponsor transactions for other users. This feature can be used to allow application developers to subsidize fees for their users, allow users to pay fees with [ERC-20] tokens and many other use cases. When the paymasterAndData field in the UserOp is not empty, the entry point implements a different flow for that UserOperation:

ERCS/erc-7769.md

@@ -54,6 +54,7 @@ If the validation, simulation, or UserOperation pool inclusion fails,
 1. **UserOperation** a full user-operation struct.\
   All fields MUST be set as hex values.\
   Empty `bytes` block (e.g. empty `initCode`) MUST be set to `"0x"`\
+  On networks with [EIP-7702](./eip-7702) activated, the `UserOperation` object may also contain an `eip7702Auth` tuple.
 2. **factory** and **factoryData**\
   Must provide either both of these parameters, or none.
 3. **paymaster**, **paymasterData**, **paymasterValidationGasLimit**, **paymasterPostOpGasLimit**\
@@ -90,13 +91,14 @@ If the validation, simulation, or UserOperation pool inclusion fails,
 
 Request:
 
-```json
+```js
 {
   "jsonrpc": "2.0",
   "id": 1,
   "method": "eth_sendUserOperation",
   "params": [
     {
+      eip7702Auth, // an EIP-7702 authorization tuple
       sender, // address
       nonce, // uint256
       factory, // address