From Solidity’s Contract ABI Specification, we see:
Dynamically-sized types like […]
bytes […] are encoded without their length field.
In EIP-6492, we have:
abi.encodePacked((create2Factory, factoryCalldata, originalERC1271Signature), (address, bytes32, bytes, bytes, bytes))
I’m not a Solidity developer, so perhaps I’m misinterpreting the syntax, but if the lengths of
bytes variables aren’t encoded, how can the verifier know when the
factoryCalldata ends and the
The verifier algorithm doesn’t seem as flexible as it should be. What if, for example, a user signs multiple messages before deploying their contract, and some of those messages are verified after? My interpretation of the steps would mean:
- Check if the signature ends with the magic bytes (it does.)
- Call into the multicall+factory (it fails because the contract is already deployed.)
- Verification failed.
I think the intended behaviour is to fall through each of the bullets? If so, the proposal could make that more clear.
check if there’s contract code at the address. If so perform ERC-1271 verification as usual by invoking
Does the verifier have to unwrap the signature if it’s wrapped? Should mention that in the proposal.
If all this fails, […]
This is slightly ambiguous. If
isValidSignature returns false, the verifier is supposed to try an
ecrecover? That would make this proposal incompatible with any upgrade that allows code to be deployed at EOAs (e.g. EIP-5003, other approaches.)
Something you might want to add to your security considerations is using a signature for mainnet on other networks, like L2s. If the wallet is recreated on a different network (perhaps using a universal deployer), the permissions couldn’t have been updated to match the ones on mainnet, so old keys would still have authority there.