Tracing & historical data
Two numbering systems
Section titled “Two numbering systems”When genesis commits a V1 archive ending at height H, ordinary legacy-facing Tolar methods expose the archived blocks followed by V2 activity. Native V2 block 0 appears as H + 1 in that legacy-facing sequence.
Ethereum methods use native V2 block numbers starting at 0. They do not project V1 blocks as Ethereum blocks. Do not join data from the two interfaces on block number alone.
V1 history is an archive
Section titled “V1 history is an archive”The explicit tol_getLegacy* methods query the immutable V1 archive. tol_getLegacyHistoryInfo reports the commitment and whether that node has the archive available.
A validator can know the committed archive root without storing the archive itself. An indexer must choose a history-capable endpoint instead of treating unavailable history as empty history.
Trace an execution
Section titled “Trace an execution”debug_traceTransaction supports explorer-oriented transaction tracing in V2. Available tracer options, configuration and retained data must be checked against the RPC compatibility guide and the queried node.
Use bounded concurrency and retries for expensive queries. Do not expose unrestricted tracing traffic to a production node without reviewing its resource controls.
Choose the right node
Section titled “Choose the right node”- Validator: consensus participation and configured retention; not a promise of complete old receipts.
- Full: retained chain data according to configuration.
- Archive: historical state support, with storage and retention requirements.
Missing historical state should be reported as unavailable, not replaced with current state. Store the interface, network and block identifier alongside indexed records.
See node operation and obtain the release-specific bootstrap instructions from your node operator before designing an indexer backfill.