Overview
This guide provides step-by-step instructions for integrating the EVM mempool into your Cosmos EVM chain. For conceptual information about mempool design and architecture, see the Mempool Concepts page.Step 1: Add EVM Mempool to App Struct
Step 2: Configure Mempool in NewApp Constructor
The mempool must be initialized after the antehandler has been set in the app.
NewApp constructor:
Breaking Change from v0.4.x: The global mempool registry (
SetGlobalEVMMempool) has been removed. Mempool is now passed directly to the JSON-RPC server during initialization.Configuration Options
TheEVMMempoolConfig struct provides several configuration options for customizing the mempool behavior:
- Minimal Configuration
- Full Configuration Options
For most use cases, the minimal configuration is sufficient:
Defaults and Fallbacks
- If
BlockGasLimitis0, the mempool uses a fallback of100_000_000gas. - If
LegacyPoolConfigis not provided, defaults fromlegacypool.DefaultConfigare used. - If
CosmosPoolConfigis not provided, a defaultPriorityNonceMempoolis created with:- Priority =
(fee_amount / gas_limit)in the chain bond denom - Comparator = big-int comparison (higher is selected first)
MinValue = 0
- Priority =
- If
BroadcastTxFnis not provided, a default is created that uses the appclientCtx/txConfigto broadcast EVM transactions when they are promoted from queued → pending. MinTipis optional. If unset, selection uses the effective tip from each tx (min(gas_tip_cap, gas_fee_cap - base_fee)).
v0.4.x to v0.5.0 Migration
Breaking Change: Pre-built pools replaced with configuration objects PR #496 replaced pre-built pools with configs inEVMMempoolConfig:
- Removed:
TxPool *txpool.TxPool,CosmosPool sdkmempool.ExtMempool - Added:
LegacyPoolConfig *legacypool.Config,CosmosPoolConfig *sdkmempool.PriorityNonceMempoolConfig[math.Int]
Minimal Setups: Nothing to Change
If you use the default mempool wiring (no custom pools), your existing code continues to work:Advanced Setups: Migrate Your Customizations
If you built custom pools yourself, replace them with configuration objects: Before (v0.4.x):Custom Legacy Pool Configuration
Customize EVM transaction pool parameters:Custom Cosmos Mempool Configuration
The mempool uses aPriorityNonceMempool for Cosmos transactions by default. You can customize the priority calculation:
Custom Broadcast Function
Override the default broadcast behavior for promoted EVM transactions:Custom Block Gas Limit
Different chains may require different gas limits based on their capacity:Event Bus Integration
For best results, connect the mempool to CometBFT’s EventBus so it can react to finalized blocks:Architecture Components
The EVM mempool consists of several key components:ExperimentalEVMMempool
The main coordinator implementing Cosmos SDK’sExtMempool interface (mempool/mempool.go).
Key Methods:
Insert(ctx, tx): Routes transactions to appropriate poolsSelect(ctx, filter): Returns unified iterator over all transactionsRemove(tx): Handles transaction removal with EVM-specific logicInsertInvalidNonce(txBytes): Queues nonce-gapped EVM transactions locally
CheckTx Handler
Custom transaction validation that handles nonce gaps specially (mempool/check_tx.go).
Special Handling: On ErrNonceGap for EVM transactions:
TxPool
Direct port of Ethereum’s transaction pool managing both pending and queued transactions (mempool/txpool/).
Key Features:
- Uses
vm.StateDBinterface for Cosmos state compatibility - Implements
BroadcastTxFncallback for transaction promotion - Cosmos-specific reset logic for instant finality
PriorityNonceMempool
Standard Cosmos SDK mempool for non-EVM transactions with fee-based prioritization. Default Priority Calculation:Transaction Type Routing
The mempool handles different transaction types appropriately:Ethereum Transactions (MsgEthereumTx)
- Tier 1 (Local): EVM TxPool handles nonce gaps and promotion
- Tier 2 (Network): CometBFT broadcasts executable transactions
Cosmos Transactions (Bank, Staking, Gov, etc.)
- Direct to Tier 2: Always go directly to CometBFT mempool
- Standard Flow: Follow normal Cosmos SDK validation and broadcasting
- Priority-Based: Use PriorityNonceMempool for fee-based ordering
Unified Transaction Selection
During block building, both transaction types compete fairly based on their effective tips:- EVM:
gas_tip_capormin(gas_tip_cap, gas_fee_cap - base_fee) - Cosmos:
(fee_amount / gas_limit) - base_fee - Selection: Higher effective tip gets selected first
Testing Your Integration
Verify Nonce Gap Handling
Test that transactions with nonce gaps are properly queued:Test Transaction Replacement
Verify that higher-fee transactions replace lower-fee ones:Verify Batch Deployments
Test typical deployment scripts (like Uniswap) that send many transactions at once:Monitoring and Debugging
Use the txpool RPC methods to monitor mempool state:txpool_status: Get pending and queued transaction countstxpool_content: View all transactions in the pooltxpool_inspect: Get human-readable transaction summariestxpool_contentFrom: View transactions from specific addresses
Related Documentation
- Mempool Concepts - Understanding mempool behavior and design
- EVM Module Integration - Prerequisites for mempool integration
- JSON-RPC Methods - Mempool query methods