How to Design a User Operation Mempool Monitoring System

A UserOperation mempool monitoring system is a critical infrastructure component for ERC-4337 account abstraction. Unlike a standard Ethereum transaction mempool, the UserOperation mempool is a peer-to-peer network where Bundlers and other nodes gossip pending UserOperation objects before they are bundled and submitted on-chain. Monitoring this mempool provides real-time visibility into pending user intents, enabling services like transaction simulation, frontrunning protection, and gas optimization analytics. The core challenge is designing a system that can connect to, parse, and process this high-volume, unstructured P2P data stream reliably.

The system architecture typically involves three core layers: the Data Ingestion Layer, the Processing & Enrichment Layer, and the Storage & Query Layer. The ingestion layer connects to the P2P network using a client like @account-abstraction/sdk or by running a modified Bundler node to listen for gossiped UserOperation objects. Each ingested operation must be validated against ERC-4337 rules—checking signatures, verifying paymaster deposits, and ensuring the sender is a valid smart contract account—to filter out invalid spam before further processing.

In the processing layer, each valid UserOperation should be simulated using eth_call to a Bundler RPC endpoint. This step is non-negotiable for security; it predicts the operation's on-chain outcome and reverts, identifying potential failures or malicious patterns. The system should also enrich data with context: resolving ENS names for addresses, fetching current gas prices from an oracle like Etherscan or Blocknative, and calculating potential profitability for searchers. This enriched data forms the actionable intelligence for downstream applications.

For storage, a time-series database like TimescaleDB or InfluxDB is ideal for the high-write volume of mempool events. Key fields to index include sender, nonce, paymaster, maxPriorityFeePerGas, and the target contract addresses. To expose this data, build a GraphQL or REST API that supports real-time subscriptions via WebSockets for live updates and efficient historical queries. For example, a query might fetch all operations targeting a specific NFT contract in the last hour, filtered by a minimum gas tip.

Implementing robust error handling and observability is crucial. The system must gracefully handle network partitions, Bundler RPC failures, and chain reorgs. Instrument everything with metrics (using Prometheus) and structured logging (using Pino or Winston). Track ingestion rates, simulation success/failure ratios, and P99 processing latency. Set up alerts for sudden drops in ingested operations or spikes in simulation failures, which could indicate a network issue or a new attack vector.

Finally, consider the operational use cases. A well-designed monitor can power a public explorer like JiffyScan, provide data for a dashboard showing mempool health and congestion, or feed a risk engine that scores operations for wallet providers. By open-sourcing your monitoring tools or publishing aggregate stats, you contribute to the ecosystem's transparency and security. Start with a simple listener, add validation and simulation, then iteratively build out the enrichment and analytics features based on the specific needs of your application.

A User Operation mempool monitoring system tracks pending user operations before they are bundled and submitted on-chain. Unlike a standard Ethereum transaction mempool, the ERC-4337 mempool is a peer-to-peer network where Bundlers, Clients (like wallets), and Paymasters broadcast and relay these intent-based messages. Your system's primary goal is to listen to this network, parse the data, and provide insights into pending activity, failed operations, and gas dynamics. Key prerequisites include a solid grasp of the ERC-4337 specification, familiarity with Node.js or Python for backend services, and experience with WebSocket connections for real-time data.

The core architecture revolves around connecting to mempool provider services. You typically don't run a P2P client yourself. Instead, you connect to a provider's WebSocket endpoint, such as those offered by Alchemy, Stackup, or Biconomy. Your service will subscribe to events like userOperationEvent to receive new UserOperation objects. Each object contains critical fields: sender, nonce, initCode, callData, callGasLimit, verificationGasLimit, preVerificationGas, maxFeePerGas, maxPriorityFeePerGas, paymasterAndData, and signature. Your system must decode and index these fields for analysis.

A robust monitoring system requires several key components. First, a data ingestion layer handles the WebSocket stream, validates incoming data against the ERC-4337 ABI, and pushes it to a message queue like Redis or Kafka for decoupling. Second, a processing engine enriches the data—it might simulate the operation using a bundler's RPC method (eth_estimateUserOperationGas) to predict failure or check paymaster sponsorship status. Third, a storage layer (e.g., PostgreSQL or TimescaleDB) persists operations for historical querying and aggregation. Finally, an API layer exposes endpoints for frontend dashboards or alerting systems.

You must also design for the network's specific challenges. User Operations can be replaced-by-fee by increasing maxPriorityFeePerGas and maxFeePerGas, so your system needs to track these updates to the same sender and nonce pair. Furthermore, operations have an expiry time; monitoring their time-in-mempool is crucial. Implementing a modular design allows you to swap out providers or add new analysis modules, such as detecting potential phishing attempts by analyzing callData for known malicious contract addresses.

For a basic implementation, start by setting up a Node.js service that connects to a provider's WebSocket. Use the @account-abstraction/utils package to parse User Operations. Listen for events and log them to a console or database. Gradually add modules for gas estimation simulation and duplicate detection. This foundational system can scale into a full dashboard showing metrics like mempool size, average confirmation time, top paymasters, and failure rate by reason, providing invaluable data for bundler operators, wallet developers, and security analysts.

In the ERC-4337 standard, a UserOperation represents a user's intent, packaged for execution by a Bundler. Unlike a standard Ethereum transaction, it contains fields like sender, nonce, callData, and signature. The mempool (memory pool) is a decentralized, peer-to-peer network where Bundlers share and receive these pending UserOperations before including them in a bundle for on-chain execution. Monitoring this mempool is critical for analyzing network activity, detecting spam, and understanding gas market dynamics specific to account abstraction.

The lifecycle of a UserOperation in the mempool follows a specific flow. First, a smart account client (like a wallet) creates and signs a UserOperation, then broadcasts it to the mempool via a Bundler's RPC endpoint. Bundlers perform simulation using the eth_call RPC to verify the operation will succeed and pay fees. Valid operations are gossiped to other Bundlers in the network. Finally, a Bundler selects operations, creates a bundle transaction, and submits it to an EntryPoint contract on-chain. Failed simulations or operations outbid on gas are dropped from local mempools.

Designing a monitoring system requires subscribing to the P2P network. Implement a bundler client that connects to peers using the ERC-4337 mempool protocol (a modified version of Ethereum's devp2p). Your client must validate incoming UserOperations against rules in ERC-4337's specification and the EntryPoint contract's validateUserOp function. Key metrics to track include: operation volume, average gas premiums (maxPriorityFeePerGas), simulation failure rates, and the time from submission to inclusion. Log the userOpHash for tracing.

For effective analysis, structure your database schema around core entities. Store each UserOperation with its full fields and computed userOpHash. Link it to a BundleTransaction record when included. Create a MempoolEvent log for each state change: RECEIVED, SIMULATED, DROPPED, BUNDLED. This allows you to calculate dwell times and identify bottlenecks. Use the EntryPoint's UserOperationEvent emission on-chain to reconcile mempool data with final on-chain execution and fee payment.

In practice, you'll need to handle network specifics. The mempool is not standardized; different Bundler implementations (like Stackup, Alchemy, Pimlico) may have minor behavioral differences. Your monitor should be tolerant of these. Furthermore, implement rate limiting and spam detection by analyzing patterns in paymasterAndData usage or repetitive callData from the same sender. This monitoring data is invaluable for building better gas estimators, wallet dashboards, and network health tools for the Account Abstraction ecosystem.

To monitor the UserOperation mempool, you must first establish a connection to a bundler's event emission system. Most ERC-4337-compliant bundlers, such as those built on the account-abstraction/sdk or pimlicolabs/permissionless.js frameworks, expose a WebSocket endpoint or a similar real-time interface. This is your primary source of truth for pending user operations before they are included in a bundle and submitted on-chain. Subscribing to events like UserOperationEvent or UserOperationRevertReason provides the raw data—operation hash, sender, paymaster, nonce, and calldata—required for analysis.

The implementation typically involves initializing a WebSocket client and listening for specific event logs. For a bundler using a standard JSON-RPC provider, you can use the eth_subscribe method with a filter for the bundler's contract address and the relevant event signatures. Here's a conceptual Node.js snippet using ethers.js:

javascriptCopy
const provider = new ethers.providers.WebSocketProvider('wss://bundler-rpc.example.com');
const filter = {
  address: BUNDLER_CONTRACT_ADDRESS,
  topics: [ethers.utils.id('UserOperationEvent(bytes32,address,address,uint256,bool,uint256,uint256)')]
};
provider.on(filter, (log) => {
  // Parse and process the UserOperationEvent log
  console.log('New UserOperation detected:', log.transactionHash);
});

This creates a persistent listener that pushes new events to your processing pipeline.

Key considerations for production systems include connection resilience and data validation. Implement automatic reconnection logic with exponential backoff to handle network instability. Validate each incoming event against the expected ABI to prevent malformed data from entering your system. It's also crucial to monitor the chain reorg events from the underlying execution client (e.g., Geth, Erigon), as a reorg can invalidate previously received mempool data, requiring your system to reset its state for affected blocks.

The lifecycle of a UserOperation begins when a client, like a wallet, constructs and submits it to a bundler. The bundler receives the operation into its mempool, a holding area for pending transactions. Your monitoring system's first job is to detect this entry. This is typically done by subscribing to the eth_subscribe RPC method on the bundler's JSON-RPC endpoint, listening for the userOperation event. Capturing the raw operation data at this point provides a baseline timestamp and the initial state of its fields, such as sender, nonce, callData, and maxFeePerGas.

After entering the mempool, the operation awaits selection by the bundler to be included in a bundle. Monitoring must track this pending state. Key metrics to log include the time spent in the mempool and any changes to the operation's gas parameters, as users or relay services may replace-by-fee. You should also watch for operations that are dropped from the mempool, which can happen if they become invalid (e.g., a nonce mismatch) or if gas prices spike beyond the set maxFeePerGas. Implementing alerts for prolonged pending times or sudden drops is crucial for diagnosing network congestion or bundler issues.

The critical transition occurs when the bundler includes the operation in a bundle and submits it to an EntryPoint contract on-chain. Your monitor must track this on-chain submission by watching the EntryPoint contract for the UserOperationEvent. The event log contains the definitive outcome: success or failure. Parsing the event's success boolean and any reason string is essential. A successful event means the user's intent was executed; a failure could be due to validation or execution errors within the smart contract wallet. Correlating the on-chain transaction hash with the original mempool entry completes the lifecycle trace.

For comprehensive analysis, store each lifecycle event in a structured database. A simple schema might include fields for userOpHash, status ("received", "pending", "bundled", "succeeded", "failed"), timestamp, transactionHash, and gasUsed. This data enables powerful analytics: you can calculate average bundling latency, identify which smart contract wallets have high failure rates, and monitor gas cost trends. Tools like The Graph for indexing or time-series databases like TimescaleDB are well-suited for this type of telemetry data, allowing you to build dashboards that visualize the health and performance of the ERC-4337 ecosystem.

Finally, implement alerting and logging based on this tracked data. Set thresholds for abnormal conditions, such as a spike in failed operations or mempool delays exceeding 60 seconds. Use the lifecycle data to provide clear error reporting to end-users; instead of "transaction failed," your system can report "Execution reverted in your wallet contract due to insufficient token balance." This level of visibility is what transforms a simple tracker into a critical operational tool for developers building on, or interacting with, account abstraction.

The core function of a monitoring system is to poll the mempool for UserOperation events and track their state transitions. You need to listen for key events like UserOperationEvent emitted by the EntryPoint contract (v0.6). Each UserOperation has a unique hash, which serves as its primary identifier. The system should maintain an internal database or cache mapping these hashes to their current status: PENDING, INCLUDED, FAILED, or STUCK. A simple polling interval, such as every 3-5 seconds, is often sufficient for most networks, but this can be adjusted based on block time and load.

To detect a stuck transaction, implement logic that flags a UserOperation when it remains in the PENDING state for an abnormally long time. This requires defining a threshold, typically measured in blocks or seconds. For example, if the average block time is 12 seconds, a UserOperation pending for more than 30 blocks (~6 minutes) might be considered stuck. The system should also check if the UserOperation's maxPriorityFeePerGas and maxFeePerGas are significantly below the current network's prevailing gas prices, which is a primary cause of transactions stalling.

Beyond simple timeouts, advanced detection involves analyzing mempool composition. A UserOperation can be outbid or replaced by other transactions with higher gas premiums. Your monitor should subscribe to new block headers and, upon each new block, check if any pending UserOperation was excluded. If a UserOperation has not been included after several blocks where the base fee was lower than its maxFeePerGas, it is likely stuck due to other validation failures or being dropped by bundlers. Implementing a secondary check against a public mempool API like Etherscan or Blocknative can provide external validation.

For actionable alerts, the system should categorize stuck reasons. Common categories include: Low Gas (fee too low), Validation Failure (simulation reverts on-chain), Bundler Exclusion (bundler's policy filters it out), and Nonce Gap (a previous UserOperation from the sender is still pending). Logging these reasons with the UserOperation hash, sender address, and timestamp is crucial for debugging. This data can feed into a dashboard or trigger automated remediation processes, such as gas bumping or cancellation.

A monitoring dashboard visualizes the key metrics of your User Operation mempool. Essential components include: - Real-time charts for operations per second (OPS), average gas prices, and bundle success rates. - Data tables listing pending operations with details like sender, target, calldata hash, and time in mempool. - System health indicators for your bundler, RPC nodes, and paymaster. Use a framework like React or Vue.js with charting libraries such as Chart.js or Recharts to build the frontend. The backend API, built with Node.js or Python, should serve aggregated data from your time-series database (e.g., TimescaleDB).

To enable proactive monitoring, implement a notification system. Define alert rules based on thresholds, such as: - pending_ops > 1000 for mempool congestion. - bundle_failure_rate > 5% over a 5-minute window. - avg_max_priority_fee > 150 Gwei indicating high network fees. These rules should be evaluated by a service that queries your database at regular intervals. Upon triggering, the service sends alerts via configured channels like Discord webhooks, Slack, Telegram bots, or PagerDuty for critical issues.

For developers, integrating directly with code is crucial. Provide a programmatic alerts API. For example, a GET /api/v1/alerts endpoint could return active alerts, while a POST /api/v1/alerts/subscribe endpoint allows users to register a webhook URL. Here's a Node.js snippet for a simple alert check:

javascriptCopy
// Pseudocode for threshold check
const highFeeAlert = async () => {
  const avgFee = await db.query('SELECT avg(gas_price) FROM ops_last_hour');
  if (avgFee > 150000000000) { // 150 Gwei
    await sendDiscordAlert(`High gas alert: ${avgFee} Gwei`);
  }
};

Effective dashboards also include historical analysis. Implement features to review past incidents, such as a spike in failed operations, by allowing users to select custom time ranges on charts. Correlate this data with external events, like mainnet Ethereum gas price surges or specific smart contract deployments, to identify root causes. Storing operation hashes and bundle transaction IDs enables deep linking to block explorers like Jiffyscan or Etherscan for immediate investigation.

Finally, ensure the system is secure and performant. Authenticate dashboard access using API keys or wallet signatures (e.g., Sign-In with Ethereum). Cache frequently queried aggregates in Redis to reduce database load. The goal is to create a tool that not only displays the state of the mempool but also empowers teams to maintain reliability and optimize the performance of their ERC-4337 infrastructure.

You now have the architectural blueprint for a monitoring system that tracks UserOperation lifecycle events from submission to on-chain inclusion. Key takeaways include: - Event-Driven Architecture using eth_subscribe to newHeads and alchemy_pendingTransactions for real-time data. - State Management with a database to track operations across received, pending, included, and failed states. - Validation Logic to check for paymaster funding, signature validity, and preVerificationGas sufficiency. - Alerting Mechanisms for critical events like stuck operations or simulation failures.

To move from concept to a working prototype, start by implementing the core listener service. Use the Ethers.js v6 or Viem library to connect to a Bundler's RPC endpoint (e.g., https://bundler.example.com) and subscribe to pending transactions. Filter for transactions sent to the EntryPoint contract address (0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 for EntryPoint v0.6). When a pending transaction is detected, decode its calldata to extract the UserOperation and store it in your database with a received status.

The next critical phase is simulation. Integrate with a Bundler's RPC method, eth_call to simulateHandleOp, to validate each operation before it's broadcast. This step is essential for security monitoring, as a failed simulation often indicates a malicious or faulty UserOperation. Log the simulation results and update the operation's status accordingly. For high-frequency monitoring, consider implementing a queue system (like Redis or RabbitMQ) to handle simulation requests asynchronously and prevent blocking your main event loop.

Finally, plan for scalability and advanced features. As transaction volume grows, you may need to shard your database or use a time-series database like TimescaleDB for metrics. Advanced monitoring could include: - MEV Analysis: Detecting if operations are being front-run or sandwiched. - Gas Analytics: Tracking maxPriorityFeePerGas trends to optimize submission. - Bundler Comparison: Monitoring multiple bundlers to compare inclusion times and success rates. Open-source tools like EigenPhi for MEV or Blocknative for mempool data can provide additional data layers.

Your monitoring system is a powerful tool for wallet developers, bundler operators, and security researchers. By providing visibility into the mempool, you can improve user experience through faster fail-safes, contribute to network security by identifying spam patterns, and gather valuable data on Account Abstraction adoption. Continue to reference the official ERC-4337 specification and Bundler implementations like Skandha or Stackup for updates as the ecosystem evolves.