🤸Handling UserOperation

Clients vet incoming Ethereum UserOperations through checks and simulations, ensuring only valid transactions enter the system, thus preserving network integrity.

Client Behavior for Handling UserOperation

When the client receives a UserOperation, it needs to carefully and systematically vet it to ensure its correctness, coherence, and compatibility with the current system state. This involves a sequence of checks, simulation stages, and validations:

1. Basic Sanity Checks:

   • Ensure either:

     • The sender is a pre-existing contract.

     • The initCode is not devoid of data (but not both these conditions).

   • In case initCode has data:

     • Extract the first 20 bytes and interpret it as the factory address.

     • Determine whether the factory is staked, especially if the subsequent simulation implies it's mandatory. If the factory interacts with the global state, staking is obligatory. Check the reputation, throttling, and banning section for more specifics.

   • Confirm that:

     • verificationGasLimit does not exceed the set maximum (MAX_VERIFICATION_GAS).

     • preVerificationGas is adequately high, accounting for the gas costs of serializing the UserOperation plus an overhead (PRE_VERIFICATION_OVERHEAD_GAS).

   • Analyze paymasterAndData to ascertain:

     • It's either vacant or begins with the paymaster address.

     • The paymaster address corresponds to an active contract on-chain.

     • There are adequate deposits to foot the UserOperation bill.

     • The paymaster isn't blacklisted or banned.

     • Check the paymaster's stake during simulation considering its storage footprint (look into the reputation, throttling, and banning section).

   • Ensure that callgas covers at least the gas expenditure of a non-zero value CALL.

   • Validate that both maxFeePerGas and maxPriorityFeePerGas:

     • Are no less than a set threshold the client deems acceptable.

     • They adequately match or surpass the current block.basefee.

   • Verify that there isn't a duplicate UserOperation for the same sender in the pool, unless:

     • It substitutes an older entry with an identical sender and nonce.

     • It offers a heightened maxPriorityFeePerGas and a proportionally augmented maxFeePerGas.

     • Only one UserOperation for every sender is permitted in a single batch.

     • Notably, a staked sender can override this rule and submit multiple UserOperations (discussed in the reputation, throttling, and banning section). However, for standard accounts, this exemption is minimally beneficial.

2. Simulation Stage:

   • Once the UserOperation has successfully passed the sanity checks, initiate the first operation simulation.

   • If this initial simulation is successful, the client must proceed to add the operation to its pool.

   • However, a secondary simulation is crucial during bundling to revalidate the sustained validity of the UserOperation.

This systematic sequence ensures that all incoming UserOperations are thoroughly vetted and only genuine, valid, and compliant operations make it to the pool. This diligence protects the network, maintains its integrity, and ensures seamless execution of transactions.