Multi-chain RPC
Just send RPC requests to one endpoint. We pick upstreams by health, block height, and latency, and switch away automatically when one fails. When sources disagree, we cross-check them.
ChainBridge never asks for your private key or seed phrase. We only relay transactions you signed yourself and never sign on your behalf.
Networks covered today
- Ethereum
- Solana
- BNB Chain
- Arbitrum
- Base
- Polygon
- Optimism
- Avalanche
These are the chain names we serve, not customer logos. The full directory, with live capabilities per chain, is on the supported networks page.
Routing, retries, and circuit breaking
Callers only need one endpoint; node selection, retries, circuit breaking, and rate limiting all happen in the gateway.
Multi-provider smart routing
Scores providers in real time by block height, latency, and error rate, then picks the best node per request.
Node health and quality scoring
Continuous probes detect lagging height, timeouts, and inconsistent responses; unhealthy nodes are removed automatically.
Failover and circuit breaking
A failed node is skipped automatically; retries are never billed twice.
Multi-source cross-validation
Critical reads (balance, nonce, receipt) are cross-checked across sources. Mismatches are flagged so bad data never passes as truth.
HTTP and WebSocket
Standard JSON-RPC (including batch arrays) and WebSocket subscriptions share the same endpoints and keys. WebSocket needs a ws upstream on that chain. Chains without one return "WebSocket not enabled yet" instead of pretending to connect. Reconnecting the same session within 5 minutes is not charged a second connection fee.
Archive queries
Historical state and log queries are billed at archive CU weights (typically 5–20x). Enable them per chain, with limits, in the console. Archive access requires an archive node for that chain. Chains without an archive upstream are rejected outright, never answered by a regular node.
Node health and routing quality
Metering rules
Metering events are persisted before posting, then deduplicated into usage. Once a billing period is invoiced it cannot be changed, only corrected with adjustment notes.
| Item | Billing rules | Description |
|---|---|---|
| HTTP JSON-RPC | Per compute unit (CU) | Method weights are listed on the public billing rules page, with version and effective date |
| Batch requests | Metered per item | Each element of a JSON array is metered as its own CU |
| Failed requests | No customer charge | Failed requests are not billed |
| Cache hits | 0 CU | No customer charge |
| Archive queries | Archive CU weights (5–20x) | Enable per chain in the console |
| WebSocket | Connection time (1 CU per minute) + subscription messages billed per message | Reconnecting the same session within 5 minutes incurs no second connection fee |
| Solana gRPC | 10 CU per connection + 0.05 CU per message | Metered separately from JSON-RPC; each connection is billed once, and so is each downstream message |
| Data API | Per request (weights differ by endpoint) | Metering and SLA separate from raw RPC |
Onchain data teams can configure provider failover and check eth_getLogs for its actual latency and error records.
Wallet teams can turn on multi-source validation for critical reads. Disagreeing node data shows up as flagged records with a resolution status.
Engineering and finance teams can reconcile usage and invoices against the original price version. Any discrepancy traces back to the exact requests behind it.
About ChainBridge Nodes
No. The gateway returns standard JSON-RPC results. For critical reads we compare multiple sources: we return the majority result, flag the anomaly, and log the mismatch for troubleshooting.
No. Each customer request has exactly one requestId, and each attempt has exactly one attemptId; retries are never billed twice.
Yes. Solana JSON-RPC, gRPC, and Data API are metered separately from EVM, with their own SLA; Solana addresses are case-sensitive and never lowercased.
Yes. The self-hosted gateway can run on your own nodes only, or put yours first with public fallback to add capacity during peaks and incidents.
Dual limits per key and plan: requests per second and CU per minute. When you hit the limit the response includes a suggested wait time; back off and retry after that many seconds.
One endpoint for every configured network
Access follows your plan and the networks you have configured. For private deployment and custom SLAs, the contract governs.