Potential issues with implementing EIP-4337 (Account Abstraction) in your project

Here is a great example of an EIP4337 implementation bug found in the Biconomy protocol. Have a look at the code below and tell me what you see:

function _createSenderIfNeeded(uint256 opIndex, UserOpInfo memory opInfo, bytes calldata initCode) internal {
	if (initCode.length != 0) {
		address sender = opInfo.mUserOp.sender;
    	if (sender.code.length != 0) revert FailedOp(opIndex, address(0), "AA10 sender already constructed");
      	address sender1 = senderCreator.createSender{gas: opInfo.mUserOp.verificationGasLimit}(initCode);
        if (sender1 == address(0)) revert FailedOp(opIndex, address(0), "AA13 initCode failed or OOG");
        if (sender1 != sender) revert FailedOp(opIndex, address(0), "AA14 initCode must return sender");
        if (sender1.code.length == 0) revert FailedOp(opIndex, address(0), "AA15 initCode must create sender");
        address factory = address(bytes20(initCode[0:20]));
      	emit AccountDeployed(opInfo.userOpHash, sender, factory, opInfo.mUserOp.paymaster);
	}
}

The statement in the EIP implies that if the account does not exist, the initcode must be used:

Create the account if it does not yet exist, using the initcode provided in the UserOperation. If the account does not exist, and the initcode is empty, or does not deploy a contract at the “sender” address, the call must fail.

In this case, it first check if the initcode exists, but this condition should be checked later.

This could be rewritten to:

function _createSenderIfNeeded(uint256 opIndex, UserOpInfo memory opInfo, bytes calldata initCode) internal {
@>	address sender = opInfo.mUserOp.sender;
	if (sender.code.length == 0) {
		require(initCode.length != 0, "empty initcode");
		address sender1 = senderCreator.createSender{gas: opInfo.mUserOp.verificationGasLimit}(initCode);
        ...
        address factory = address(bytes20(initCode[0:20]));
      	emit AccountDeployed(opInfo.userOpHash, sender, factory, opInfo.mUserOp.paymaster);
	}
}

Another problem was found in the return values of validateUserOp():

        try IAccount(sender).validateUserOp{gas : mUserOp.verificationGasLimit}(op, opInfo.userOpHash, aggregator, missingAccountFunds) returns (uint256 _deadline) {
            // solhint-disable-next-line not-rely-on-time
            if (_deadline != 0 && _deadline < block.timestamp) {
                revert FailedOp(opIndex, address(0), "AA22 expired");
            }
            deadline = _deadline;
        } catch Error(string memory revertReason) {
            revert FailedOp(opIndex, address(0), revertReason);
        } catch {
            revert FailedOp(opIndex, address(0), "AA23 reverted (or OOG)");
        }

The validateUserOp() should return a time range, as per the EIP specifications:

The return value is packed of sigFailure, validUntil and validAfter timestamps.

- sigFailure is 1 byte value of “1” the signature check failed (should not revert on signature failure, to support estimate).

- validUntil is 8-byte timestamp value, or zero for “infinite”. The UserOp is valid only up to this time.

- validAfter is 8-byte timestamp. The UserOp is valid only after this time.

And the last issue was found right in the validateUserOp():

    function validateUserOp(UserOperation calldata userOp, bytes32 userOpHash, address aggregator, uint256 missingAccountFunds)
    external override virtual returns (uint256 deadline) {
        _requireFromEntryPoint();
        deadline = _validateSignature(userOp, userOpHash, aggregator);
        if (userOp.initCode.length == 0) {
            _validateAndUpdateNonce(userOp);
        }
        _payPrefund(missingAccountFunds);
    }

validateUserOp() (inherited from IAccount interface) MUST verify the aggregator parameter is valid and the same as getAggregator.

The account should also support aggregator-specific getter (e.g. getAggregationInfo()). This method should export the account’s public-key to the aggregator, and possibly more info (note that it is not called directly by the entryPoint).


If an account uses an aggregator (returns it with getAggregator()), then its address is returned by simulateValidation() reverting with ValidationResultWithAggregator instead of ValidationResult.

The recomendation was simple: Refactor the code that is not compliant with the EIP.

Be carefull using complicated EIPs.

Read the full report here:

Link: https://solodit.xyz/issues/m-02-non-compliance-with-eip-4337-code4rena-biconomy-biconomy-smart-contract-wallet-contest-git