Robinhood debug and trace methods

The four debug_* methods published for Robinhood Chain, what they are useful for, and their honest availability: best-effort through a single operator, without an SLA.

The catalog publishes four debug methods on https://triport.io/rpc/robinhood:

Availability: best-effort, no SLA

These methods run best-effort through a single operator and carry no availability SLA. Plan for them to be unavailable or slow: keep a fallback path, do not put a debug call on a user-facing critical path, and expect deep block traces to be the most expensive requests you can issue here.

Parity-style trace_* methods (trace_block, trace_call, trace_filter, trace_transaction) are not part of the Robinhood contract, and debug_* is not a drop-in replacement for them: the response shapes and semantics differ. See RPC behavior for the measurement evidence behind that exclusion.

Reading a revert reason

debug_traceCall takes the same call object as eth_call plus a block tag and tracer options, and returns the failure with its revert data instead of a bare error — that is what makes it the practical tool for "why did my transaction revert". Supported block tags here are latest, earliest, pending and hex numbers; safe and finalized are not part of this contract.

For a mined transaction, debug_traceTransaction gives the same picture after the fact. When you only need the outcome and gas, eth_getTransactionReceipt is cheaper, and eth_estimateGas is the right tool for sizing gas.

Internal transfers are data, not a ready index

Traces are the raw material for internal-ETH-transfer history, but Triport does not publish an indexed history: you would build your own index from traces and account for reverted calls yourself. See address history for what exists today.

Limits

Debug methods bill against the heavy-read category; per-plan request rates and the 4 MiB body ceiling are in Limits. Deep traces return large payloads — request one block at a time and keep your client timeouts generous.