Skip to main content
Mempool configurations vary wildly across different protocols & node client configurations. The table here is a maintained reference of mempool configurations & specifics across all the protocols that Chainstack supports.

What gives you mempool access

Two different things get called mempool access, and they have different requirements. On the EVM chains with a public mempool — Ethereum, Polygon, and BNB Smart Chain: For a live feed of pending transactions, any node type is enough, in the full mode or the archive mode. The feed is the node’s view of the public mempool — transactions that reached it over the p2p network, not only the ones you submitted through it. No node sees every pending transaction, as each node’s view depends on its peers. Global Nodes and Trader Nodes block txpool_content, txpool_contentFrom, and txpool_inspect on EVM networks, in every mode and on every plan. A call returns error code -32601:
txpool_status is not blocked. It returns the pending and queued transaction counts on nodes whose client serves the txpool namespace, which varies by network and mode. To read the pool contents, deploy a Dedicated Node and ask for the txpool_* namespace when you deploy. It is a customization that works in the full mode and the archive mode. txpool_* is also a separate namespace from debug_* and trace_*, and each one has its own gate:
  • txpool_* — the node type decides whether you can read the pool contents, not your plan.
  • debug_* and trace_* — your plan enables them. They do not bring txpool_* with them.
On Arc, the node software blocks pending-transaction visibility: eth_newPendingTransactionFilter and eth_subscribe("newPendingTransactions") return -32001, and both eth_getBlockByNumber("pending") and eth_getTransactionBySenderAndNonce return null. See Arc methods.
On protocols with no public mempool, pending-transaction methods like eth_newPendingTransactionFilter and eth_subscribe("newPendingTransactions") return empty by design — pending transactions are visible only to the sequencer. On Base and Optimism, follow transactions in real time with Flashblocks instead — see the how-to guides (Base, Optimism) or how Flashblocks works (Base, Optimism).
A subscription that is accepted is not a subscription that delivers. On World Chain and Stable, eth_subscribe("newPendingTransactions") and eth_newPendingTransactionFilter both succeed and hand back an ID, then deliver nothing.World Chain is an OP Stack chain, so its pending transactions sit with the sequencer and the txpool_* methods are not served at all. On Stable, txpool_status responds, but it reported pending: 0x0, queued: 0x0 in every one of 30 samples taken over two minutes while 52 transactions confirmed in new blocks over the same window — the pool is not exposed through the EVM JSON-RPC layer. Do not build a pending-transaction feed on either chain.
The table structure:
  • Protocol — protocol name.
  • Protocol availability — details of the mempool availability on the protocol level.
  • Chainstack availability — what you need to deploy for the protocol’s pool-inspection methods on Chainstack.
  • Client configuration — the default node client configuration for the mempool as deployed at Chainstack.
  • Example — a simple curl example. Remember to replace YOUR_CHAINSTACK_NODE with your Chainstack node endpoint for that particular protocol.
Remember that whatever the default configuration, we can always customize it for you on a Dedicated Node .

Ethereum txpool_content

Polygon txpool_content

BSC txpool_content

Gnosis txpool_content

Filecoin MpoolPending

Fantom txpool_content

Tezos pending_operations

Bitcoin getrawmempool

Ake

Ake Director of Developer Experience @ Chainstack
Talk to me all things Web3
20 years in technology | 8+ years in Web3 full time years experience
Last modified on October 2, 2026