Fix guide
Polygon trace and debug API: what it is, when you need it, and why pricing gets confusing
Trace and debug calls help you inspect transaction execution, failed calls, internal calls, and contract behavior - but they are heavier than normal reads and many providers gate or meter them differently.
Last updated: July 8, 2026
Guide navigation
Who this page is for
- Debug-heavy developers tracing failed transactions
- Indexers and data products using trace methods
- Bot operators debugging execution behavior
- Analytics and monitoring teams inspecting internal calls
Do not compare trace by RPS alone
RPS tells you almost nothing about monthly trace cost. Trace and debug methods are often heavier, gated, or weighted differently than basic Polygon reads.
What trace and debug methods are used for
These methods help inspect failed transactions, internal calls, contract execution behavior, bot decision flows, and transaction analysis workloads. Availability depends on provider and node/client support.
| Method | Used for | Why it can be heavy |
|---|---|---|
debug_traceTransaction | Inspect failed transaction execution | Heavy execution replay and internal call detail |
debug_traceCall | Simulate and inspect a call path | Can require deeper computation than a simple read |
debug_traceBlockByNumber | Trace a full block execution context | Large historical and execution-heavy payload |
trace_transaction | Inspect internal calls for one transaction | Trace namespace support and historical state matter |
trace_call | Trace a call without sending a transaction | Heavier than normal eth_call usage |
trace_filter | Search trace activity over ranges | Historical and broad filters can become expensive |
trace_block | Trace transactions inside one block | Still heavier than standard block reads |
trace_replayTransaction | Replay transaction behavior in detail | Replay work can be CPU and state heavy |
Why trace and debug calls are treated differently
- They can require heavier CPU and disk work.
- They may depend on historical state.
- They are often unavailable on free tiers.
- Method namespace support can vary by node client.
- Raw RPS does not tell you what the monthly trace bill looks like.
BlazingNode trace positioning
Trace bundles are available where implemented, and direct monthly request limits plus included traces make cost planning easier than many weighted models.
When a trace add-on makes more sense than a bigger plan
If your normal request volume is still fine but trace usage spikes temporarily, a trace add-on can be more rational than upgrading the whole core plan. If both normal request volume and trace usage keep growing every month, the better move is usually a higher plan. If only monthly normal request volume is the issue, an extra 10M request pack for 35 USDC may be the cleaner fit.
| Workload | Need | Suggested path |
|---|---|---|
| Occasional failed tx debugging | Understand why one transaction failed | Builder or Operator included traces |
| Active bot debugging | Repeated transaction inspection | Operator |
| Indexer or analytics trace use | Trace-heavy recurring analysis | Pro |
| Production-critical trace-heavy system | High consistency and larger trace envelope | Enterprise or custom path |
| One-time incident investigation | Short temporary spike | Trace add-on if available |
Frequently asked questions
What is the difference between trace_* and debug_*?
They often expose different views into execution depending on provider and node/client support. Availability is not universal across every Polygon RPC environment.
Does every Polygon RPC provider support trace methods?
No. Method availability depends on provider policy, plan tier, and node/client support.
Why are trace calls more expensive?
They usually require deeper execution inspection, more CPU or disk work, and sometimes historical state, so providers often meter them differently from normal reads.
How many trace calls do I need?
That depends on whether you debug occasionally, trace active bots, or run a trace-heavy analytics workload. The right plan should match real monthly trace volume, not just peak RPS.
Does BlazingNode include trace calls?
Yes on paid plans. Builder includes 25K traces, Operator 50K, Pro 100K, and Enterprise 250K per month.