How SolidRPC matches RPC requests to qualified capacity

A suitable path must match the requested chain and method. It must also be able to serve the requested block context, meet the applicable freshness policy, and remain eligible under observed health and capacity conditions. A path that answers one request is not automatically suitable for another.

Consider a current-state read and a trace of an old transaction. They can share a chain ID but require different retained data and RPC support. The same applies to an indexer requesting a large historical log range. The network catalog is the starting point for checking these differences.

Historical state, blocks, receipts, logs, execution traces, and historical proofs are different data products. The word archive alone does not establish that every one of them is available at every block.

Likewise, debug methods and Parity-style trace methods are separate interfaces. Support for one family does not establish support for the other. Use the exact method and relevant historical fixture when qualifying an integration. Our archive guide explains the distinctions, and the trace-method guide compares their outputs.

The chain pages make method families visible so a team can identify a mismatch before rollout. They should be read alongside any method-specific restrictions in the documentation.

An HTTPS endpoint does not imply a WebSocket endpoint, and a WebSocket connection does not imply support for every subscription type. Check availability and subscription types for the network you intend to use.

The current WebSocket guide documents ordinary stateless JSON-RPC and native newHeads subscriptions on activated networks for eligible accounts. Applications need to save a processing cursor, reconnect and resubscribe after a disconnect, and reconcile missed or replacement blocks. Live delivery is different from durable replay.

Use the current guide and network response for coverage rather than copying a static network list into application assumptions. A capability can become available without changing the endpoint shape used by your integration.

Choose fixtures from the application rather than testing only eth_blockNumber. Include a recent state read, a historical state read at the oldest depth you require, a known non-empty log range, and a known transaction trace if tracing is part of the workload. Verify the expected result or structural invariants, not just the transport status.

For a log query, retain the filter and exact block range. For state, record the block selector. For a trace, record the transaction hash and tracer options. Use stable or finalized fixtures when comparing results so changing chain state does not invalidate the comparison.

Then test representative concurrency and bursts within the plan. Record failures and completion times alongside successful throughput. A single successful call establishes that fixture at that moment, not sustained capacity for every workload.

When an eligible request needs another serving path, SolidRPC manages that selection behind the integration. Your application should not need a separate provider contract for each data type or a table of upstream fallback rules.

There is still an explicit application boundary. The team chooses the required chain and method, checks documented support, and handles application outcomes correctly. An unsupported feature should be identified before migration rather than treated as a transient fault that endless retries will fix.

For a production review, send the required chains, methods, historical depth, peak rate, and latency expectations. Those details make it possible to assess the actual workload and choose a concrete evaluation plan. Start with the migration guide and the production benchmark checklist.