A way to verify a signature when the account is a smart contract that has not been deployed yet.
Signatures from ERC-4337 wallets cannot be validated until they are deployed. This means that new wallets can't sign transactions, which is a problem when we want to create a new wallet and start using it. ERC-6492 provides a way to do this. A dapp looks at a smart contract while it has not yet been deployed, simulates it and then gets its valid signature to sign and validate the signature of that contract.
Contracts can sign verifiable messages via ERC-1271.
However, if the contract is not deployed yet, ERC-1271 verification is impossible, as you can't call the isValidSignature function on said contract.
We propose a standard way for any contract or off-chain actor to verify whether a signature on behalf of a given counterfactual contract (that is not deployed yet) is valid. This standard way extends ERC-1271.
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.
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.
The words "validation" and "verification" are used interchangeably.
Quoting ERC-1271,
isValidSignaturecan call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), EOA dependent (e.g. signers authorization level within smart wallet), signature scheme Dependent (e.g. ECDSA, multisig, BLS), etc.This function should be implemented by contracts which desire to sign messages (e.g. smart contract wallets, DAOs, multisignature wallets, etc.) Applications wanting to support contract signatures should call this method if the signer is a contract.
We use the same isValidSignature function, but we add a new wrapper signature format, that signing contracts MAY use before they're deployed, in order to allow support for verification.
The signature verifier MUST perform a contract deployment before attempting to call isValidSignature if the wrapper signature format is detected.
The wrapper format is detected by checking if the signature ends in magicBytes, which MUST be defined as 0x6492649264926492649264926492649264926492649264926492649264926492.
It is RECOMMENDED to use this ERC with CREATE2 contracts, as their deploy address is always predictable.
The signing contract will normally be a contract wallet, but it could be any contract that implements ERC-1271 and is deployed counterfactually.
concat(abi.encode((create2Factory, factoryCalldata, originalERC1271Signature), (address, bytes, bytes)), magicBytes)concat(abi.encode((prepareTo, prepareData, originalERC1271Signature), (address, bytes, bytes)), magicBytes); prepareTo and prepareData must contain the necessary transaction that will make the contract ready to verify using ERC-1271 (e.g. a call to migrate or update)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 verification presumes we already know the account address we're verifying the signature for.
Full signature verification MUST be performed in the following order:
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 signatureisValidSignaturefactory was skipped due to the wallet already having code, execute the factoryCalldata transaction and try isValidSignature againecrecover verificationWe believe that wrapping the signature in a way that allows to pass the deploy data is the only clean way to implement this, as it's completely contract agnostic, but also easy to verify.
The wrapper format ends in magicBytes, which ends with a 0x92, which makes it is impossible for it to collide with a valid ecrecover signature if packed in the r,s,v format, as 0x92 is not a valid value for v. To avoid collisions with normal ERC-1271, magicBytes itself is also quite long (bytes32).
The order to ensure correct verification is based on the following rules:
magicBytes MUST happen before the usual ERC-1271 check in order to allow counterfactual signatures to be valid even after contract deploymentmagicBytes MUST happen before ecrecover in order to avoid trying to verify a counterfactual contract signature via ecrecover if such is clearly identifiableecrecover MUST NOT happen before ERC-1271 verification, because a contract may use a signature format that also happens to be a valid ecrecover signature for an EOA with a different address. One such example is a contract that's a wallet controlled by said EOA.We can't determine the reason why a signature was encoded with a "deploy prefix" when the corresponding wallet already has code. It could be due to the signature being created before the contract was deployed, or it could be because the contract was deployed but not ready to verify signatures yet. As such, we need to try both options.
This ERC is backward compatible with previous work on signature validation, including ERC-1271 and allows for easy verification of all signature types, including EOA signatures and typed data (EIP-712).
The wrapper format described in this ERC can be used for all contract signatures, instead of plain ERC-1271. This provides several advantages:
create2Factory and factoryCalldata, just like ecrecoverBelow you can find an implementation of a universal verification contract that can be used both on-chain and off-chain, intended to be deployed as a singleton. It can validate signatures signed with this ERC, ERC-1271 and traditional ecrecover. EIP-712 is also supported by extension, as we validate the final digest (_hash).
For on-chain validation, you could use two separate methods:
UniversalSigValidator.isValidSig(_signer, _hash, _signature): returns a bool of whether the signature is valid or not; this is reentrancy-safeUniversalSigValidator.isValidSigWithSideEffects(_signer, _hash, _signature): this is equivalent to the former - it is not reentrancy-safe but it is more gas-efficient in certain casesBoth methods may revert if the underlying calls revert.
The ValidateSigOffchain helper allows you to perform the universal validation in one eth_call, without any pre-deployed contracts.
Here's example of how to do this with the ethers library:
You may also use a library to perform the universal signature validation, such as Ambire's signature-validator.
The same considerations as ERC-1271 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 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, checking against the current live version of the contract.
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 and related rights waived via CC0.