Utility to determine if an address is an EOA

[pcaversaccio]

I was wondering if it makes sense to have a utility function that can determine if an address is an EOA. With EIP-7702 we have now also (0xef0100 || address) as code for an EOA. So the function could check if the code length is either zero or the first 3 bytes is ef_01_00. I haven't thought this completely through, but dropping this as an idea here for now.

bytes3 internal constant _DELEGATION_PREFIX = 0xef0100;
function isEOA(address target) internal view returns (bool) {
    bytes memory code = target.code;
    // Add here a comment addressing the normal disclaimers around
    // construction-time issues and zero-length contracts.
    return (code.length == 0 || bytes3(code) == _DELEGATION_PREFIX);
}

The reason why I don't check for the length of 23 bytes is that you cannot deploy a contract starting with 0xef according to EIP-3541.

[ernestognw]

Sounds like a great idea @pcaversaccio. The delegation prefix 0xef00 should be unambiguous given EIP-3541.
Even if an EOA delegates to an empty contract (not sure if possible) should work

[frangio]

I think there's utility in a function to confirm that an account is EIP-7702 delegated and to get the delegation target (this is useful for paymasters IIUC), but this is not what's proposed here. What would be the use of checking if an account is an EOA like this issue proposes?

[pcaversaccio]

One example use case could be this line:

openzeppelin-contracts/contracts/utils/cryptography/SignatureChecker.sol

Line 23 in e342516

if (signer.code.length == 0) {

You can argue this is still accepted pattern as it's now a a smart contract wallet and not a "simple" EOA anymore. The delegation contracts like the one from MM (https://etherscan.io/address/0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B#code) will return a valid EIP-1271 magic for such case.

Another one could be here:

openzeppelin-contracts/contracts/token/ERC20/utils/SafeERC20.sol

Line 118 in e342516

if (to.code.length == 0) {

So the question is how to deal with .code.length == 0 checks after delegation and if isEOA would be useful to have here.

[ernestognw]

You can argue this is still accepted pattern as it's now a a smart contract wallet and not a "simple" EOA anymore.

Yes, this would be my main argument. Users sign a delegation message that literally means "execute this code in my EOA's context", and that's the way it should be treated IMO. If they delegated to a contract that doesn't implement 1271, then wasn't that their intention? They can always redelegate to a contract that does implement ERC1271 and will be ready to go. No harm to anyone. (Just as recommended by default in Wizard, though)

On the other hand, I would argue that using an isEOA utility is overkill, the protocol should already be designed with considerations about code.length == 0. Delegated contracts should behave no differently, and IMO current protocols have no reasons to implement this check (new ones may, but I feel everyone is overthinking it).

So the question is how to deal with .code.length == 0 checks after delegation and if isEOA would be useful to have here.

Right, I'm looking for an actual use case because other than that, the current assumptions in smart contracts about empty addresses should remain. For protocols there's conceptually no difference in how accounts are interacting with them