txpool_content — Polygon JSON-RPC

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 rate-limit response — HTTP 429 with a plain body, not a JSON-RPC envelope:

{
  "error": "rate_limited",
  "message": "Rate limit exceeded: 1 RPS sustained on polygon_txpool (pro tier)",
  "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://triport.io/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}`);

• 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 HTTP 429 (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 HTTP 403 tier_insufficient (tier_insufficient).
• Rate limiting is RPS-per-tier with burst; there is no daily quota.