# Handling UserOperation

**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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://mau-eth.gitbook.io/mau/account-abstraction/handling-useroperation.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.