txpool_content

txpool_content returns the full contents of the backing node's transaction pool as a single point-in-time, atomic snapshot: the complete transaction objects for every transaction that is either pending (executable on the next block) or queued (valid but not yet executable, typically because of a nonce gap). It is the heavyweight member of the txpool family — where txpool_status returns only counts and txpool_inspect returns short summary strings, txpool_content returns every field of every transaction.

Use it when you need the whole mempool at once rather than a live feed: building an MEV snapshot, computing a gas-price distribution across pending transactions, or running offline mempool analytics. If instead you want to react to individual transactions as they arrive, prefer a streaming subscription — txpool_content is a periodic snapshot, complementary to (not a replacement for) a push stream.

This method belongs to the polygon_txpool category and requires the Pro tier. It is intentionally heavy: on Polygon mainnet the pool commonly holds 8,000+ pending transactions, producing a response payload in the 5–50 MB range. The rate limit is correspondingly low — 1 RPS on Pro, 2 RPS on Business — and you should keep concurrency very small (see Notes). The contents reflect the specific node serving your request, so the exact set of transactions varies between calls and is not a consensus view of the global mempool.

It takes no parameters.

This method takes no parameters. Send an empty params array.

The result is an object with two top-level keys, pending and queued. Each is a map keyed by sender address; the value is a map keyed by the transaction's nonce (as a decimal string), whose value is the full transaction object.

Example error envelope (rate limited):

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32003,
    "message": "Rate limit exceeded: 1 RPS sustained on polygon_txpool (pro tier)",
    "data": {
      "current_tier": "pro",
      "category": "polygon_txpool",
      "limit_rps": 1,
      "burst_capacity": 2,
      "retry_after_sec": 1
    }
  }
}

See errors.md for the full error envelope and the shared error-code reference.

JavaScript (fetch)

const res = await fetch("https://api.triport.io/v1/polygon", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.TRIPORT_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "txpool_content",
    params: [],
  }),
});


const { result } = await res.json();
const pendingCount = Object.values(result.pending)
  .reduce((n, byNonce) => n + Object.keys(byNonce).length, 0);
console.log(`pending transactions: ${pendingCount}`);

TypeScript SDK (@triport/sdk)

import { Triport } from "@triport/sdk";


const client = new Triport({ apiKey: process.env.TRIPORT_API_KEY });


type TxPool = {
  pending: Record<string, Record<string, unknown>>;
  queued: Record<string, Record<string, unknown>>;
};


const pool = await client.polygon.request<TxPool>("txpool_content", []);
console.log("senders with pending txs:", Object.keys(pool.pending).length);

Python (triport-sdk)

import os
from triport import Triport


client = Triport(api_key=os.environ["TRIPORT_API_KEY"])


pool = client.polygon.request("txpool_content", [])
pending = sum(len(by_nonce) for by_nonce in pool["pending"].values())
queued = sum(len(by_nonce) for by_nonce in pool["queued"].values())
print(f"pending: {pending}, queued: {queued}")

• Atomic snapshot, not a stream. Each call captures the pool at one instant. For continuous mempool observation, use a subscription rather than tight polling of this method — the two are complementary (snapshot of the whole pool vs. an eventually-consistent push of individual transactions).
• Large payloads. Polygon mainnet typically returns 8,000+ pending transactions and 5–50 MB of JSON. Stream-parse the response and avoid buffering the whole body in memory where you can.
• Cap concurrency at ≤ 4. Keep at most four txpool_content requests in flight at once; combined with the per-tier limit (1 RPS on Pro, 2 RPS on Business) this avoids saturating your bandwidth. Exceeding the limit returns -32003 (rate_limited) with a retry_after_sec hint.
• No parameters, no pagination — the entire pool is returned in one response. For lighter checks use txpool_status (counts only) or txpool_inspect (summary strings).
• Requires the Pro tier; a lower tier returns -32002 (tier_insufficient).
• Rate limiting is RPS-per-tier with burst; there is no daily quota.