Choosing a Blockchain Node Provider: What to Test Before You Commit

Give providers the same workload

Start with a short requirements document: chains and network identifiers, required interfaces, representative methods, peak traffic, concurrency, application regions and the oldest data you need. Include expensive requests even when they account for little of your total volume.

"Ethereum RPC" is not enough detail for a useful quote. A service answering current-state reads may not meet your historical-state, tracing or log-query requirements.

Verify capabilities before comparing prices

Ask which capabilities are already available and which require provisioning or synchronization. Test the exact methods your application uses, including historical requests and error cases.

For JSON-RPC, validate the response body rather than accepting HTTP success alone. The protocol distinguishes a successful result from an error response; your integration needs to handle both. The JSON-RPC specification defines that envelope.

Keep known-answer test cases for the correct network and a few identified blocks. An endpoint that responds consistently with the wrong data has not passed acceptance testing.

Find out what "dedicated" includes

Ask what resources are reserved for your deployment and what remains shared. Clarify storage, network connectivity, gateway dependencies and whether redundancy is included. A private URL or API key does not, by itself, establish dedicated capacity.

Separate commercial quotas from technical constraints. A deployment can have no provider-imposed request quota while still reaching CPU, storage or network capacity. Protective timeouts and query settings also need to suit the workload. Our dedicated versus shared RPC guide covers the capacity distinction.

Test degraded operation

Measure useful completed requests, latency and errors together. Include a mixed workload: historical queries can compete with live reads even when each performs acceptably in isolation. Our RPC latency benchmarking guide explains how to make those comparisons reproducible.

Agree a controlled recovery test. What happens when a node restarts, a subscription disconnects or the primary loses access to required history? Verify the backup's capabilities rather than assuming a second URL is equivalent. For subscription-based workloads, include the recovery checks in our WebSocket versus HTTP RPC guide.

Request written maintenance and escalation arrangements. Distinguish the time to acknowledge an incident from the time to restore service, and identify which failures remain the application team's responsibility.

Compare the full operating cost

Include storage growth, retained history, bandwidth, backup nodes, additional regions and support in the quote. Record provisioning time and migration arrangements. Keep endpoint configuration separate from application code, and identify dependencies on provider-specific methods before adopting them.

For DTEAM dedicated nodes, send us the same requirements document you would use to evaluate any provider. We do not impose artificial request-rate or usage quotas on dedicated nodes; sustainable throughput depends on the selected hardware and workload. Share your network and representative queries so we can scope the deployment.