Setting Up Real-Time MEV Detection Alerts for Your Network

Maximal Extractable Value (MEV) represents profits that validators, searchers, or bots can extract by reordering, inserting, or censoring transactions within a block. Common forms include sandwich attacks on DEX trades, arbitrage between liquidity pools, and liquidations in lending protocols. For network operators and application developers, real-time detection of these events is critical for monitoring network health, protecting users, and understanding economic activity. Setting up an alerting system allows you to react to MEV events as they happen, rather than analyzing them after the fact.

The foundation of any MEV alert system is a reliable data source. You need access to real-time mempool data and newly mined blocks. Services like Chainscore's MEV API, Flashbots Protect RPC, or running your own Erigon/Nethermind archive node with transaction pool access can provide this stream. The key is to ingest pending transactions and completed blocks, then apply detection heuristics to identify patterns indicative of MEV. For example, a classic sandwich attack involves a victim's DEX trade transaction flanked by two attacker transactions in the same block.

Here is a basic Python example using the Chainscore API to detect a potential sandwich attack by analyzing a new block. It looks for a pattern where a transaction (tx2) interacts with the same pool as two surrounding transactions (tx1, tx3) from the same sender.

pythonCopy
import requests
CHAINSCORE_API_KEY = 'your_api_key'
CHAINSCORE_URL = 'https://api.chainscore.dev/v1/block/'

def check_block_for_sandwich(block_number):
    headers = {'x-api-key': CHAINSCORE_API_KEY}
    response = requests.get(f'{CHAINSCORE_URL}{block_number}', headers=headers)
    block_data = response.json()
    txs = block_data['transactions']
    for i in range(1, len(txs)-1):
        # Simplified heuristic: check if middle tx and flanking txs share a pool
        if (txs[i-1]['from'] == txs[i+1]['from'] and
            txs[i].get('dex_pool') and
            txs[i].get('dex_pool') == txs[i-1].get('dex_pool')):
            send_alert(f"Potential sandwich attack in block {block_number}")

Once you have detection logic, you need to connect it to an alerting pipeline. This typically involves publishing events to a message queue (like Apache Kafka or RabbitMQ) or directly calling a notification service. For immediate alerts, integrate with Slack, Discord webhooks, Telegram bots, or PagerDuty. For a more robust system, log events to a database like PostgreSQL or TimescaleDB for historical analysis and dashboarding. This allows you to track metrics such as MEV volume per day, most targeted protocols, and the success rate of different attack types over time.

Configuring your alerts requires careful tuning of thresholds and filters to avoid alert fatigue. You might start by alerting on all detected MEV but quickly refine to only high-value events (e.g., >1 ETH extracted) or attacks targeting specific, whitelisted smart contracts in your ecosystem. It's also crucial to monitor for false positives; a benign user making two trades in a block could trigger a naive sandwich detector. Regularly review and adjust your heuristics based on real chain data. Combining multiple data sources, like also checking if the flanking transactions originated from a known searcher address, can improve accuracy.

Beyond basic detection, advanced MEV alert systems can incorporate machine learning models to classify novel attack vectors or predict MEV opportunities before they are executed. By joining mempool data with on-chain state (e.g., DEX pool reserves), you can estimate potential profit for pending arbitrage transactions. For network operators, correlating MEV alerts with validator performance metrics can reveal if certain validators are consistently capturing disproportionate value. The goal is to move from simple notification to actionable intelligence, providing insights that can inform protocol design, user protection features, and network governance decisions.

Real-time MEV detection requires monitoring the mempool—the staging area for pending transactions—and analyzing blocks as they are proposed. You should be familiar with core blockchain concepts: transaction lifecycle, gas fees, block builders, and validators. Understanding common MEV strategies like arbitrage, liquidations, and sandwich attacks is essential to recognize them in the data stream. For Ethereum, this means working with the execution layer (transactions) and the consensus layer (block proposals).

The primary technical prerequisite is access to a reliable node connection. You cannot rely on public RPC endpoints for mempool data due to rate limits and data sanitization. You need a dedicated, archival Ethereum node (e.g., Geth, Erigon, Nethermind) with transaction pool access enabled. Alternatively, use a specialized mempool data provider like Blocknative or Bloxroute. For processing, you'll need a backend service (Node.js, Python, Go) and a database (PostgreSQL, TimescaleDB) to store and query alerts.

A typical system architecture consists of three core services. First, a Data Ingestion Service subscribes to the node's JSON-RPC newPendingTransactions and newHeads streams. Second, a Detection Engine processes this stream, applying heuristics and algorithms to identify potential MEV opportunities or threats. Third, an Alerting Service formats and dispatches notifications via webhook, Telegram bot, or email. These services should be decoupled using a message queue (e.g., RabbitMQ, Kafka) for scalability and resilience.

Your detection logic will depend on your goal. For searchers, you might look for profitable arbitrage paths between DEXs using a solver. For protectors, you might monitor for front-running attempts on user transactions. Implementations often use TypeScript with ethers.js or Python with web3.py. A basic check for a simple DEX arbitrage might involve simulating a swap on two different pools using a forked environment via Foundry's cast or Tenderly to validate profitability before an alert is sent.

Finally, consider the operational requirements. Running this system 24/7 demands monitoring for node health, data stream continuity, and detection latency. Alerts must be low-latency to be actionable; aim for sub-second processing from transaction broadcast to notification. You'll also need to manage private keys securely if your alerts trigger automated actions. Start with a single chain (Ethereum Mainnet) and a specific MEV type before scaling to more complex, cross-chain detection.

Real-time MEV detection is critical for network operators, validators, and protocol developers to monitor ecosystem health and security. Unlike post-mortem analysis, real-time alerts allow for immediate investigation of suspicious activity, such as sandwich attacks, arbitrage, or liquidation cascades. Setting up these alerts requires defining specific heuristics—rule-based patterns that signal potential MEV behavior—and connecting them to a data pipeline that processes blocks as they are finalized. The core components are a reliable blockchain data source (like an RPC node or data indexer), a detection engine to run heuristics, and an alerting system.

The first step is selecting and configuring your data source. For real-time detection, you need access to a mempool stream and a new block feed. Services like Chainscore's Mempool API or running a dedicated Geth/Erigon node with transaction pool access provide the raw data. Your detection service must subscribe to these streams to receive pending transactions and newly mined blocks. It's essential to ensure low latency; delays in data ingestion can mean missing critical events that define an MEV opportunity, as bots often act within the same block.

Next, you implement the detection heuristics. These are algorithms that scan transaction data for known MEV patterns. Common heuristics include: sandwich_detection for identifying front-running and back-running trades around a victim swap, arbitrage_detection for profitable DEX-to-DEX trades within a single block, and liquidations for identifying collateral liquidation transactions. Each heuristic should be coded to analyze transaction ordering, gas prices, contract interactions, and profit calculations. For example, a simple sandwich detector in pseudocode might check if two swaps from the same address envelop a user's swap to the same pool.

Once heuristics are defined, you need to process the data. This involves parsing each new block, extracting transactions, and running them through your detection functions. This can be resource-intensive, so efficient code and potentially a queuing system are necessary. The output of a successful detection is an MEV event object, which should contain details like the block number, transaction hashes involved, the heuristic triggered, estimated extractable value, and the involved addresses (searcher, victim, contracts). This event is then passed to your alerting module.

Finally, configure your alerting system. This can range from simple log files and webhook calls to more sophisticated platforms like Discord, Slack, or Telegram bots, or security incident management tools. The alert should be actionable, providing all necessary context for an investigator. For ongoing monitoring, consider dashboards that aggregate events over time. Remember to tune your heuristics to reduce false positives, which can be done by adjusting profit thresholds or requiring multiple confirming signals. Regular updates are needed as MEV strategies evolve.

For a production setup, consider using specialized MEV detection infrastructure. Chainscore's Detection API offers pre-built heuristics and real-time alerts, reducing the development overhead. Whether building in-house or using a service, the goal is the same: gain situational awareness of MEV activity on your network to protect users, inform protocol design, and ensure fair market operation. Start with a few key heuristics, validate them against historical data, and then deploy your monitoring to mainnet.

A blockchain's mempool (memory pool) is a network-wide, decentralized queue of transactions that have been broadcast by users but not yet confirmed in a block. For MEV detection, the mempool is your primary data source. By monitoring it in real-time, you can observe the flow of pending transactions, including arbitrage opportunities, liquidations, and sandwich attacks, as they are submitted to the network. This live feed is the raw input for any alerting or analysis system.

To connect, you need a reliable mempool provider. Running your own full node (like Geth or Erigon for Ethereum) gives you the most direct and private access, but requires significant infrastructure. For most developers, using a specialized service like Chainscore, Alchemy Mempool, Bloxroute, or a public RPC endpoint is more practical. These services aggregate transactions from multiple nodes and provide a clean WebSocket or HTTP stream, often with enhanced data like transaction simulation results.

The core technical task is subscribing to a transaction stream. Using a WebSocket connection is standard for real-time alerts. Here's a basic example using the Chainscore API with Node.js:

javascriptCopy
const WebSocket = require('ws');
const ws = new WebSocket('wss://api.chainscore.io/v1/mempool/stream?network=ethereum-mainnet&apiKey=YOUR_KEY');

ws.on('message', function incoming(data) {
  const tx = JSON.parse(data);
  console.log('New TX:', tx.hash);
  // Add your MEV detection logic here
});

This connection will push new transaction objects to your application as they enter the mempool.

Each transaction object contains critical fields for analysis: hash, from, to, value, gasPrice or maxPriorityFeePerGas, and most importantly, the input data (calldata). For MEV, you must decode this calldata to understand the intended contract interaction, such as a swap on Uniswap or a debt repayment on Aave. Services often provide pre-decoded logs, but you may need ABIs for custom analysis.

Latency is a decisive factor in MEV. The time between a transaction being broadcast and your system processing it must be minimized. Choose a provider with low-latency infrastructure in regions close to major block builders and validators. Test the propagation delay—the time from submitting a test transaction to seeing it in your stream—to benchmark your setup. Delays of even a few hundred milliseconds can render an arbitrage opportunity unprofitable.

Finally, implement robust connection management. Mempool streams can disconnect. Your code should automatically reconnect, handle backpressure, and gracefully process bursts of activity during times of high network congestion. This reliable foundation ensures your detection logic acts on a complete, real-time view of network activity, which is non-negotiable for effective MEV alerting.

The core of your MEV monitoring system is the detection logic that processes raw blockchain data. Chainscore's API provides structured alerts for common MEV patterns, which you can consume programmatically. You will typically set up a server-side listener or a cloud function that subscribes to the relevant alert streams. Key alert types include sandwich attacks, liquidations, arbitrage, and n-frontrunning. Each alert payload contains critical data such as the transaction hash, involved addresses, profit extracted, and the specific strategy detected.

To begin, you need to authenticate with the Chainscore API and subscribe to an alert feed. Below is a basic Node.js example using the eventsource library to stream real-time alerts for a specific network like Ethereum mainnet. Replace YOUR_API_KEY with your actual key and configure the network parameter.

javascriptCopy
import EventSource from 'eventsource';

const url = `https://api.chainscore.dev/v1/mev/stream?network=ethereum&apiKey=YOUR_API_KEY`;
const eventSource = new EventSource(url);

eventSource.onmessage = (event) => {
  const alert = JSON.parse(event.data);
  console.log('New MEV Alert:', alert);
  // Add your custom logic here (e.g., send to Discord, trigger analysis)
};

eventSource.onerror = (err) => {
  console.error('EventSource failed:', err);
};

Once you are receiving alerts, you must implement your custom filtering and routing logic. Not every alert may be relevant to your application. You might filter by minimum profit threshold, exclude certain known safe addresses (like your own contracts), or only monitor specific token pairs. For high-severity alerts like large-scale sandwich attacks on your protocol's liquidity pools, you may want immediate notifications via services like Discord, Telegram, or PagerDuty. For other alerts, logging them to a database for later analysis might be sufficient.

For a robust production system, consider implementing alert deduplication and cooldown periods to avoid notification spam from the same attack vector. You should also set up health checks for your alert stream connection. Chainscore's documentation provides best practices for handling reconnections and backoff strategies. The goal is to create a system that is both responsive to genuine threats and resilient against data stream interruptions.

Finally, integrate your detection logic with your existing security and monitoring stack. This could mean feeding alerts into a SIEM (Security Information and Event Management) tool, creating dashboards in Grafana, or triggering automated response scripts. By programmatically implementing this detection layer, you move from passive observation to active network defense, enabling faster reaction times to protect your users' funds and your protocol's integrity.

Once your MEV detection system is operational, the next critical step is to ensure its findings reach you instantly. This is achieved by integrating with alert channels. These are the conduits that push notifications—such as a new sandwich attack or a profitable arbitrage opportunity—to your preferred communication platform. Common channels include Discord webhooks, Telegram bots, and Slack integrations. The goal is to minimize the time between detection and your awareness, enabling swift investigation or action.

The integration process typically involves configuring a webhook URL provided by your alerting service within your MEV detection setup. For a system using the Flashbots Protect RPC or a similar MEV-aware node, you would set the webhook in its configuration file. If you're running a custom detection script using a library like web3.py or ethers.js, you would add a function to send an HTTP POST request to your webhook endpoint containing the alert payload, which includes details like the transaction hash, block number, attack type, and estimated profit.

A robust alert payload is essential for effective monitoring. It should contain structured data that your team can act upon. Key fields include: event_type (e.g., sandwich, arbitrage), transaction_hash, victim_address, attacker_address, block_number, estimated_profit_eth, and a severity score. Sending this data to a service like Discord allows you to format it into an embedded message with color-coded severity levels, making it easy to triage alerts at a glance during high-activity periods.

For production systems, consider implementing alert deduplication and routing. High-frequency MEV bots may attempt the same attack pattern multiple times; your system should group related alerts to prevent notification fatigue. Furthermore, you can route alerts based on severity: critical alerts (e.g., a large-value sandwich attack on a user) could go to a dedicated on-call channel, while informational alerts (e.g., a small, failed arbitrage) could be logged to a separate dashboard for later analysis.

Finally, test your integration thoroughly before relying on it. Simulate an alert by triggering a detection on a testnet transaction or by manually sending a test payload to your webhook. Verify that the notification appears correctly in your chosen channel with all relevant data. Regularly review and update your alerting logic as new MEV strategies emerge and your monitoring requirements evolve. Effective alerting transforms raw blockchain data into actionable intelligence for your team.

Your MEV detection pipeline is now operational. The next critical step is integrating these alerts into your existing monitoring and incident response workflows. For development teams, this means piping alerts into Slack, Discord, or PagerDuty channels using the webhook endpoints provided by tools like Forta or Tenderly. For protocol teams, consider creating automated on-chain responses, such as pausing vulnerable contracts or adjusting fee parameters when a specific sandwich attack pattern is detected. The key is to move from passive observation to active defense.

To deepen your analysis, explore correlating your MEV alerts with broader market and on-chain data. Cross-reference detected arbitrage transactions with DEX price feeds from Chainlink or Pyth to understand profit margins. Analyze failed front-running attempts to identify bot strategies. Use block explorers like Etherscan to trace the full transaction lifecycle of flagged addresses. This contextual data transforms simple alerts into actionable intelligence, helping you assess the severity and sophistication of the threats targeting your network.

Finally, consider expanding your monitoring scope. The principles you've applied—monitoring mempools, analyzing transaction ordering, and tracking profitable addresses—can be adapted for other threats. Set up alerts for nft arbitrage, liquidation cascades in lending protocols, or governance attacks exploiting proposal timing. Regularly review and tune your detection rules as bot strategies evolve. The EigenPhi and Flashbots MEV-Explore dashboards are excellent resources for staying updated on the latest MEV trends and attack vectors.