EIP-4337 validation phases: account, paymaster, aggregator ordering

EIP-4337 validation phases: account, aggregator, paymaster ordering. Debug stuck UserOperations and tune bundler policies with traces. Practical notes for.

3 min read

Who this is for

  • Support engineers
  • Smart contract devs
  • Bundler operators

Pros / cons

ProsCons
  • Phases make failures easier to localize when traced
  • Encourages structured account design
  • Aligns audits with explicit checkpoints
  • Ordering details vary by EntryPoint version
  • Cross-phase interactions confuse newcomers
  • Verbose traces require good tooling

Key takeaways

  • Label traces per phase in internal tools
  • Build runbooks mapping revert selectors to phases
  • Test paymaster and account failures independently

High-level phase model

Validation under EIP-4337 is intentionally staged so bundlers can reason about failure points and gas consumption in a structured manner before execution occurs. While exact ordering and helper methods should be verified against the deployed EntryPoint source for your chain, the conceptual model begins with assembling the UserOperation context, proceeds through sender account validation logic, optionally engages aggregator verification when present, and then may invoke paymaster validation to finalize fee arrangements before marking the operation as valid for inclusion. Each stage has distinct revert messages and gas accounting, which observability systems can surface to engineers if instrumented properly. Execution is a separate later stage that runs the user calldata through the account after validation succeeds, and failures there should not be mislabeled as validation issues in analytics. IBEx Network debugging guides emphasize capturing the full trace subtree for each phase rather than only the outer revert string. Wallets should test scenarios where each phase fails independently to ensure user messaging stays accurate. Security audits benefit when threat models explicitly enumerate attacker goals per phase, such as griefing bundlers during paymaster validation versus stealing funds during execution.

Account validation: signatures, nonces, and modules

Account validation typically checks the UserOperation signature according to account policy, verifies nonce progression or keyed nonce rules, and may consult modules or guardians depending on architecture. Gas limits for this portion must be sized so that honest users succeed while still bounding attacker work. Modular accounts should document how modules participate in validation and in what order, because subtle differences affect both security and simulation outcomes. IBEx teams recommend property tests that ensure invalid signatures never pass, even when other fields appear well-formed. When accounts support session keys, validation must confirm scopes such as target contracts, value limits, and time windows before accepting an operation. Traces should identify which internal module reverted to speed support. Some failures reflect configuration mistakes, such as uninitialized implementations, that wallets can detect early with static checks before submission.

Paymaster and aggregator validation interplay

When aggregators are used, their verification must align with account expectations so that aggregated proofs match what validateUserOp anticipates. Paymaster validation confirms sponsorship rules, token payments, or signature-backed policies, reverting if budgets are exhausted or calldata does not match signed digests. Ordering between aggregator checks and paymaster checks matters for debugging; misconfigured interactions can yield confusing reverts where the deepest failing contract is not the root cause logically. IBEx bundler configurations sometimes allow toggling optional phases off for testing in controlled environments, though production must mirror spec-compliant ordering. Gas exhaustion during paymaster validation is a common incident during traffic spikes when budgets are too tight; monitoring should alert before depletion. Fraud analysts should watch for patterns where paymaster validation succeeds but execution later fails repeatedly, indicating possible probing behavior.

Operationalizing phase knowledge in runbooks

Runbooks should list steps to capture traces, identify phase, inspect relevant storage slots, and compare simulation versus on-chain execution for the same block context. Include escalation paths when failures cluster after client upgrades or hard forks. Training modules for support engineers should include screenshots of trace viewers with phase labels. IBEx postmortem templates require stating which phase failed and what configuration change resolved the issue. Automated linters on UserOperation JSON can catch missing fields before they waste simulation cycles. Long-term, standardizing structured error envelopes from bundlers that include phase hints will reduce mean time to resolution industry-wide.

Frequently asked questions

Why does my error mention paymaster when I think the account broke?

Nested calls can bubble revert data. Read the trace to see which contract actually reverted first and in which phase.

Can I skip validation phases locally?

Only in controlled mocks. Production bundlers enforce the full pipeline; skipping locally hides real failures.

Do phases affect gas refunds?

Gas accounting rules apply to validation and execution separately in the EntryPoint design. Consult your EntryPoint version for refund details.