Blockchain Infrastructure

Ethereum RPC looks like ordinary HTTP until it isn't. Methods have wildly different costs, not every node can answer every request, and a node that is a few blocks behind will happily return an answer that is quietly wrong. Generic load balancers cannot see any of this.

• Archive, full and minimal nodes have different capabilities, and routing a request to the wrong tier fails or returns incomplete data.

• Client implementations differ: some methods exist only on Erigon, others behave differently on Geth or Reth.

• A node that lags the chain head serves stale data that looks valid to the caller.

• Chain re-orgs can produce answers from a fork that no longer exists.

• Filters and subscriptions are stateful, so they break the moment a load balancer moves a session.

• Archive nodes are expensive, and routing cheap queries to them wastes the most costly capacity you own.

1. 01

   Route by method, not by round-robin

   Each RPC method is classified by cost and capability, then sent to the cheapest node tier that can answer it correctly. Light queries stop consuming archive capacity.

2. 02

   Detect client type automatically

   Nodes are probed for their client and version, so Erigon-only methods are never sent to a Geth node and capability differences are handled by the router rather than by the caller.

3. 03

   Guarantee canonical data

   Live queries are served from the node at the highest block height, with re-org detection to prevent serving blocks from a fork that has been abandoned.

4. 04

   Keep stateful sessions sticky

   Filter and subscription sessions retain affinity to the node that created them, and WebSocket traffic is proxied natively rather than translated through HTTP.

5. 05

   Measure every routing decision

   Per-method metrics, tier-fallback counters and routing decision labels, so a change in traffic mix is visible before it becomes an incident.

Which Ethereum clients do you support?

Erigon, Geth and Reth. The routing layer detects the client automatically and accounts for capability differences, including methods that exist on only one implementation.

Can this run in front of third-party RPC providers?

Yes. Hosted providers can be treated as another backend tier, which is a common pattern for overflow capacity or as a fallback while self-hosted nodes are syncing.

How is a re-org actually handled?

Block hashes are tracked across nodes so a response from an abandoned fork can be identified and withheld rather than returned as though it were canonical. The event is exported as a metric so you can see how often it happens.

Do you also operate the nodes?

We design and automate node deployment, syncing and monitoring. Ongoing operation can stay with your team or be a separate arrangement — that is a commercial question rather than a technical one.