Check for `msg.sender.code.length` before the account is deployed

[gabrielstoica]

Hi!

I'm trying to make a call to a method in a contract that's guarded by a modifier which checks if the sender (ERC-4337 SA) is a valid non-zero code size contract, as follows:

    /// @dev Allow only calls from contracts implementing the {ISpace} interface
    modifier onlySpace() {
        // Checks: the sender is a valid non-zero code size contract
        if (msg.sender.code.length == 0) {
            revert SpaceZeroCodeSize();
        }

        // Checks: the sender implements the ERC-165 interface required by {ISpace}
        bytes4 interfaceId = type(ISpace).interfaceId;
        if (!ISpace(msg.sender).supportsInterface(interfaceId)) revert SpaceUnsupportedInterface();
        _;
    }

, where ISpace is our own ERC-4337 compliant implementation.

When calling the method for the first time, due to the fact that the account is not deployed yet, it will fail with SpaceZeroCodeSize(). Therefore, we first need to send an empty UserOp to deploy and then call the target method. This adds some traction to the overall workflow.

Is there a better way or workaround to address this behavior e.g. bypassing the initial validation? Thanks!

[drortirosh]

please describe the scenario where this method is indeed called on-chain, before the account is deployed.
With the first UserOp of a new account, the entrypoint will:

1. call the account's factory to deploy it
2. call validateUserOp on that new account
3. verify that this account indeed paid (because validateUserOp has to send the max possible gas to the EntryPoint, before any execution is done
4. actual account execution is done by entryoint calling the execute() or executeBatch() or similar method on the account. In any case, the account is obviously already deployed at that point.

The only case I can think of that the above check would fail, is if you do an "eth_call", with the "counterfactual" address of your account: that is, with the calculated address of your account, before you issued your first transaction, and thus before it is deployed.

So if you want to make this view call prior installing your account, you need somehow to have the contract available.
one way is provide a "stateOverride" parameter to eth_call, with the deployed contract call.

[gabrielstoica]

Hi @drortirosh,

We're using a wallet integrator service to create SAs for our users when they join the app. You're right - the first transaction will be an eth_call with their counterfactual address, therefore the account will not be deployed at that point, resulting in the msg.sender.code.length check to fail.

You can see the modifier in action here. The reserve() is supposed to be called after the user joins the platform as the first transaction with their Space (smart account).

Due to the limitations of the wallet integrator, I'm not sure if we can provide the stateOverride parameter to eth_call as you've suggested so I guess the only way around it is to remove the onlySpace modifier for now, at least for the method that will be called first.

Thanks for the support!