txpool_content: Dump the Node's Entire Mempool
txpool_content•Read method•Ethereum JSON-RPCtxpool_content returns the node's entire transaction pool: every pending and queued transaction it is holding, grouped by sender address and then by nonce. It is the most direct view of the mempool an execution client offers, and also one of the heaviest responses in the whole API, which is why shared endpoints almost universally switch the txpool namespace off.
Try txpool_content
curl -s http://localhost:8545 \
-X POST \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "txpool_content",
"params": []
}'We do not fire this one from your browser: where the txpool namespace is open at all, the response is tens of megabytes, and most shared endpoints disable it outright. Copy the curl command and point it at a node whose txpool API is enabled, such as your own or the one a BLAZED.sh container sits on, and redirect the output to a file rather than to a terminal.
What txpool_content does
The pool has two halves and the response mirrors them. pending holds transactions that are executable right now: the sender's nonce lines up and the balance covers the cost, so a builder could include them in the next block. queued holds transactions that cannot execute yet, almost always because there is a nonce gap ahead of them. A transaction moves from queued to pending the moment the gap in front of it fills.
Each entry is a full transaction object, the same shape eth_getTransactionByHash returns, with blockHash, blockNumber and transactionIndex all null because nothing has been mined. The grouping by sender and nonce is what makes the dump useful for reasoning about replacement transactions and stuck nonces: you can see, for one address, exactly which nonces are outstanding and what each of them is paying.
There is no global mempool to dump. What you get is this node's view, shaped by which peers gossiped to it and by its own pool limits and eviction rules, and it excludes everything sent privately to builders. Two nodes queried at the same instant return overlapping but different pools, which is a feature when the node is yours and a problem when it is a gateway deciding what to show you.
Parameters
txpool_content takes no parameters; send an empty params array. The pool is dumped whole, which is exactly the problem. txpool_contentFrom takes one address and returns only that sender's transactions, and txpool_status returns just the pending and queued counts; both exist because this method is so expensive.
What it returns
An object with pending and queued, each a map from sender address to a map from nonce (as a decimal string) to a full transaction object. Nothing is sorted for you and the ordering of a JSON object's keys carries no meaning; builders order by effective tip, not by anything in this structure.
The response is very large. A dump taken from a mainnet node while writing this page came back at roughly 83MB, holding about 79,000 pending and 18,000 queued transactions across some 48,000 sender addresses. Your node's numbers will differ with its pool configuration and peer set, but the order of magnitude is the point.
Example response
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"pending": {
"0x000025e01db606436e2a658c765ccb78442b1c69": {
"0": {
"blockHash": null,
"blockNumber": null,
"from": "0x000025e01db606436e2a658c765ccb78442b1c69",
"gas": "0x59d8",
"gasPrice": "0x99cf00",
"hash": "0x49460eb9e2eb98b7d404f12815601246f2e9033d2bf2efa0655dd45ba3b64af9",
"input": "0xa9059cbb000000000000000000000000b0ed81f27a195bc81ce3e063c28a3adc669c26...",
"nonce": "0x0",
"to": "0xdac17f958d2ee523a2206206994597c13d831ec7",
"value": "0x0"
}
}
},
"queued": {}
}
}One sender out of tens of thousands, trimmed. The outer keys are addresses, the inner keys are nonces as decimal strings, and the values are transaction objects with null block fields because nothing has been mined yet.
txpool_content with ethers.js
import { WebSocketProvider } from "ethers";
// inside a BLAZED.sh container the node is one local socket away
const provider = new WebSocketProvider("ws://eth:8545");
// cheap first: how big is the pool right now?
const status = await provider.send("txpool_status", []);
console.log(BigInt(status.pending), "pending,", BigInt(status.queued), "queued");
// one sender only, instead of the whole pool
const mine = await provider.send("txpool_contentFrom", [
"0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
]);
console.log("outstanding nonces:", Object.keys(mine.pending ?? {}));
// the full dump: megabytes of JSON, so reach for it deliberately
// const pool = await provider.send("txpool_content", []);Gotchas and common errors
The response is measured in megabytes
This is not a normal API call. Serializing tens of thousands of full transaction objects takes real work on the node and produces a payload most HTTP clients will happily buffer entirely into memory. Polling it in a loop is a good way to make a node unresponsive for everybody using it, including you. If you want a stream of new transactions, subscribe to newPendingTransactions instead and keep your own view of the pool.
Reach for the lighter methods first
txpool_status returns only the pending and queued counts and is the right health check. txpool_contentFrom takes a single address and answers the question people usually mean, which is "what is stuck for this account". txpool_inspect returns a compact text summary rather than full objects. The full dump is for analysis, not for monitoring.
queued means blocked, not rejected
A transaction sits in queued because it cannot execute in nonce order yet, typically because an earlier nonce from the same sender is missing. Builders never see queued transactions. A bot that crashed mid-sequence and resumed at a higher nonce will find everything it sent afterwards parked here, invisible, until it fills the gap or those transactions are evicted.
The pool is bounded and evicts
Clients cap how many transactions they hold, both globally and per account; Geth's defaults are in the low thousands of executable slots and a smaller queue. When the pool is full, the cheapest transactions are dropped. A transaction that disappears from the dump has not necessarily been mined, and a pool that looks small may simply be a node with tight limits.
Private order flow is not in here
A large share of the transactions that matter for MEV never touch the public mempool; they go straight to builders. The dump therefore shows the public pool as this node received it, not everything that will be in the next block. Treat it as a rich but partial signal.
Shared endpoints keep the namespace closed
The txpool namespace is off by default on most hosted RPC, and where a provider does expose mempool data it is usually a proprietary, filtered stream rather than this method. Getting the unfiltered pool means having a node of your own, which is the arrangement co-located code on BLAZED.sh is built around.
What txpool_content costs on BLAZED.sh
txpool_content is one of three methods that cost 4 credits per call on BLAZED.sh rather than the standard 1, alongside trace_replayTransaction and trace_replayBlockTransactions. Those 4 credits are the smaller half of the bill: responses over 100KB add 50 credits per MB, and a dump this size is well past that threshold, so a single call in the tens of megabytes carries a surcharge measured in thousands of credits under that rule. Use txpool_status or txpool_contentFrom for anything you run on a schedule, and save the full dump for the analysis that actually needs every transaction.
See the full credit price listtxpool_content: frequently asked questions
Why does txpool_content return "method not found"?
The txpool namespace is disabled on that endpoint. Nearly all shared providers switch it off because the response is enormous. You need a node with the txpool API enabled, such as your own or the one your code is co-located with.
What is the difference between pending and queued?
Pending transactions are executable now: their nonce follows the account's current nonce and the balance covers them. Queued transactions cannot execute yet, almost always because an earlier nonce from the same sender is missing, and builders ignore them entirely.
Is there a lighter way to check the mempool?
Yes. txpool_status returns just the counts, txpool_contentFrom returns one sender's transactions, and txpool_inspect returns a compact text summary. For a live view, subscribe to newPendingTransactions over WebSocket instead of dumping the pool repeatedly.
Does txpool_content show every transaction on the network?
No. It shows what this node holds. Pools differ between nodes because gossip and eviction differ, and transactions routed privately to builders never enter the public pool at all.
Why does it cost 4 credits instead of 1?
It is one of the three heavy methods priced at 4 credits, with trace_replayTransaction and trace_replayBlockTransactions. The response-size surcharge of 50 credits per MB above 100KB then applies on top, which for a multi-megabyte dump dominates the cost.
Call txpool_content from the node itself
Deploy your container or script next to a synced Ethereum node. No rate limits, no compute units, sub-10ms local RPC.