Update EIP-6492: move to Review (ethereum#6668)

* Add EIP: Standard Signature Validation Method for Counterfactually Deployed Contracts (ethereum#6492)

* Update EIP-6492: Standard Signature Validation Method for Counterfactually Deployed Contracts

* Error fixes
* Readability improvements
* Better definitions

* Update EIP-6492: Signature Validation for Predeploy Contracts

* Moved counterfactual check to the beginning

* Update EIP-6492: Signature Validation for Predeploy Contracts

* Add a note about key invalidation

* Update EIP-6492: Signature Validation for Predeploy Contracts

* Propose a validation implementation that does not require pre-deploying singletons

* Update EIP-6492: Signature Validation for Predeploy Contracts

* Consistency in using verification/validation

* Suggest a library to use

* Update EIP-6492: Signature Validation for Predeploy Contracts

* Specify off-chain usage

* Change example contract to something a bit more compiler optimizable

* Update EIP-6492: Signature Validation for Predeploy Contracts

* Fix contract issue

* Update EIP-6492: Signature Validation for Predeploy Contracts

* Add on-chain validation singleton

* Update EIP-6492: Signature Validation for Predeploy Contracts

* Add on-chain validation singleton

* Update EIP-6492: Signature Validation for Predeploy Contracts

* Change status to review

* Update EIP-6492: Signature Validation for Predeploy Contracts

* Remove ERC-4337 link so that the EIP can be considered stable

* Update EIP-6492: Signature Validation for Predeploy Contracts

* Add Agustin Aguilar (@Agusx1211)

* Update EIP-6492: Signature Validation for Predeploy Contracts

* Reduce ambiguity

EIPS/eip-6492.md

@@ -2,9 +2,9 @@
 eip: 6492
 title: Signature Validation for Predeploy Contracts
 description: A way to verify a signature when the account is a smart contract that has not been deployed yet
-author: Ivo Georgiev (@Ivshti)
+author: Ivo Georgiev (@Ivshti), Agustin Aguilar (@Agusx1211)
 discussions-to: https://ethereum-magicians.org/t/eip-6492-signature-validation-for-pre-deploy-contracts/12903
-status: Draft
+status: Review
 type: Standards Track
 category: ERC
 created: 2023-02-10
@@ -21,14 +21,12 @@ We propose a standard way for any contract or off-chain actor to verify whether
 
 ## Motivation
 
-With the popularity of [ERC-4337](./eip-4337.md) and other account abstraction initiatives, we often find that the best user experience for contract wallets is to defer contract deployment until the first user transaction, therefore not burdening the user with an additional deploy step before they can use their account. However, at the same time, many dApps expect signatures, not only for interactions, but also just for logging in.
+With the rising popularity of account abstraction, we often find that the best user experience for contract wallets is to defer contract deployment until the first user transaction, therefore not burdening the user with an additional deploy step before they can use their account. However, at the same time, many dApps expect signatures, not only for interactions, but also just for logging in.
 
 As such, contract wallets have been limited in their ability to sign messages before their de-facto deployment, which is often done on the first transaction.
 
 Furthermore, not being able to sign messages from counterfactual contracts has always been a limitation of [ERC-1271](./eip-1271.md).
 
-The initial motivation is discussed in the eth-infinitism/account-abstraction repo.
-
 ## 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.
@@ -51,20 +49,20 @@ It is RECOMMENDED to use this ERC with CREATE2 contracts, as their deploy addres
 
 ### Signer side
 
-The signer will normally be a contract wallet, but it could be any other counterfactual contract as well.
+The signing contract will normally be a contract wallet, but it could be any contract that implements [ERC-1271](./eip-1271.md) and is deployed counterfactually.
 
 - If the contract is deployed, produce a normal [ERC-1271](./eip-1271.md) signature
-- If the contract is not deployed yet, wrap the signature as follows: `concat(abi.encodePacked((create2Factory, factoryCalldata, originalERC1271Signature), (address, bytes32, bytes, bytes, bytes)), magicBytes)`
+- If the contract is not deployed yet, wrap the signature as follows: `concat(abi.encode((create2Factory, factoryCalldata, originalERC1271Signature), (address, bytes32, bytes, bytes, bytes)), magicBytes)`
 
 Note that we're passing `factoryCalldata` instead of `salt` and `bytecode`. We do this in order to make verification compliant with any factory interface. We do not need to calculate the address based on  `create2Factory`/`salt`/`bytecode`, because [ERC-1271](./eip-1271.md) verification presumes we already know the account address we're verifying the signature for.
 
 ### Verifier side
 
 Full signature verification MUST be performed in the following order:
 
-- check if the signature ends with magic bytes, in which case do an `eth_call` to a multicall contract that will call the factory first with the `factoryCalldata` and deploy the contract; Then, call `contract.isValidSignature` as usual
+- check if the signature ends with magic bytes, in which case do an `eth_call` to a multicall contract that will call the factory first with the `factoryCalldata` and deploy the contract if it isn't already deployed; Then, call `contract.isValidSignature` as usual with the unwrapped signature
 - check if there's contract code at the address. If so perform [ERC-1271](./eip-1271.md) verification as usual by invoking `isValidSignature`
-- If all this fails, try `ecrecover` verification
+- if there is no contract code at the address, try `ecrecover` verification
 
 ## Rationale
 
@@ -217,14 +215,16 @@ You may also use a library to perform the universal signature validation, such a
 
 The same considerations as [ERC-1271](./eip-1271.md) apply.
 
-However, deploying a contract requires a `CALL` rather than a `STATICCALL`, which introduces reentrancy concerns. This is mitigated in the reference implementation by having the validation method always revert if there are side-effects, and capturing it's actual result from the revert data. For use cases where reentrancy is not a concern, we have provided the `isValidSigWithSideEffects` method.
+However, deploying a contract requires a `CALL` rather than a `STATICCALL`, which introduces reentrancy concerns. This is mitigated in the reference implementation by having the validation method always revert if there are side-effects, and capturing its actual result from the revert data. For use cases where reentrancy is not a concern, we have provided the `isValidSigWithSideEffects` method.
 
 Furthermore, it is likely that this ERC will be more frequently used for off-chain validation, as in many cases, validating a signature on-chain presumes the wallet has been already deployed.
 
 One out-of-scope security consideration worth mentioning is whether the contract is going to be set-up with the correct permissions at deploy time, in order to allow for meaningful signature verification. By design, this is up to the implementation, but it's worth noting that thanks to how CREATE2 works, changing the bytecode or contructor callcode in the signature will not allow you to escalate permissions as it will change the deploy address and therefore make verification fail.
 
 It must be noted that contract accounts can dynamically change their methods of authentication. This issue is mitigated by design in this EIP - even when validating counterfactual signatures, if the contract is already deployed, we will still call it.
 
+As per usual with signatures, replay protection should be implemented in most use cases. This proposal adds an extra dimension to this, because it may be possible to validate a signature that has been rendered invalid (by changing the authorized keys) on a different network as long as 1) the signature was valid at the time of deployment 2) the wallet can be deployed with the same factory address/bytecode on this different network.
+
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).