trace_block

trace_block returns the full Parity-style execution trace for all transactions in one block. The result is a flat array of trace frames: every external call and every internal call (call, delegatecall, staticcall, create, suicide) produced while the block executed, tagged with the transaction it belongs to and its position in the call tree. This is the whole-block counterpart to trace_transaction, which traces a single transaction.

Use it when you need the complete internal-execution picture of a block rather than just its receipts. Typical use cases:

• MEV indexing — reconstruct the full execution path of each transaction to detect sandwiches, atomic arbitrage, and JIT liquidity.
• DeFi internal-transfer tracking — follow transferFrom and value moves between contracts that never appear as top-level transactions.
• Compliance / forensic auditing — produce a verifiable execution trail for a transaction inside its block context.

This is a premium trace method: it requires the Pro tier or above and is rate limited per tier (3 RPS on Pro, 10 RPS on Business) with a short burst allowance. There is no daily quota. Tracing a whole block is heavy: a typical Polygon block holds ~50–150 transactions, each expanding into several to many trace frames, so a single response is commonly 100 KB–2 MB and latency runs into the seconds. Keep concurrency low and prefer recent or specific blocks over wide historical sweeps.

Trace-shape note. Polygon runs the Bor execution layer, whose trace output can differ slightly from a stock Geth/Parity node — most visibly in how a frame is typed ("call" vs "delegatecall" and the other call variants). Write your indexer to accept both type spellings rather than matching one exact string.

Positional parameters: a single block reference.

Response fields

See the shared error envelope reference for the full error object shape and handling guidance.

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: "trace_block",
    params: ["latest"],
  }),
});


const { result } = await res.json();
console.log(result.length, "trace frames in block");

TypeScript SDK (@triport/sdk)

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


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


const frames = await triport.polygon.request("trace_block", ["latest"]);


// Group frames by the transaction they belong to.
const byTx = new Map<string, unknown[]>();
for (const frame of frames) {
  const list = byTx.get(frame.transactionHash) ?? [];
  list.push(frame);
  byTx.set(frame.transactionHash, list);
}

Python (triport-sdk)

import os
from triport import Triport


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


frames = triport.polygon.request("trace_block", ["latest"])
print(len(frames), "trace frames in block")

• Pass either a block tag (latest, earliest) or a 0x-prefixed hex block number. Tracing latest is the common path for real-time MEV detection; historical blocks are available for indexing and archival analysis.
• Responses are large (100 KB–2 MB) and slow (seconds, not milliseconds). Keep concurrency low — a handful of in-flight requests is plenty — and avoid fanning the method across long block ranges in parallel.
• For a single transaction rather than a whole block, use trace_transaction. To simulate and trace a call that is not yet on chain, use trace_call. To filter trace frames across a block range by address, use trace_filter. For full per-transaction state diffs in addition to the trace, use trace_replayBlockTransactions.
• The Geth-style equivalent of this method is debug_traceBlockByNumber, which returns a nested call-tree shape rather than the flat Parity frame array. Cross-checking the two is useful for trace-shape verification.