GeezerVison

eRPC is a fault-tolerant RPC proxy with re-org-aware permanent caching, serving both EVM chains and SVM (Solana) clusters. It sits in front of all your upstreams — managed providers and your own nodes — behind a single endpoint, and handles failover, retries, caching, and multi-chain routing automatically. Built for read-heavy workloads such as data indexing and high-load frontends.

With the below setup, you get immediate access to 2,000+ EVM chains and 4,000+ public free EVM RPC endpoints. SVM (Solana) networks are configured explicitly — see below.

Using npx:

npx start-erpc

Or, using Docker:

docker run -p 4000:4000 ghcr.io/erpc/erpc

Or, using Railway:

curl 'http://localhost:4000/main/evm/42161' \
--header 'Content-Type: application/json' \
--data '{
    "method": "eth_getBlockByNumber",
    "params": ["latest", false],
    "id": 9199,
    "jsonrpc": "2.0"
}'

curl 'http://localhost:4000/main/svm/mainnet-beta' \
--header 'Content-Type: application/json' \
--data '{
    "method": "getSlot",
    "params": [{"commitment":"confirmed"}],
    "id": 1,
    "jsonrpc": "2.0"
}'

SVM networks identify themselves as svm:<cluster> (e.g. svm:mainnet-beta, svm:devnet, svm:testnet), or svm:<chain>:<cluster> for Solana forks and variants such as Fogo and Eclipse (e.g. svm:fogo:mainnet) — so several SVM chains can be hosted side by side without network-id or cache-key collisions.

The same failsafe, routing, and consensus machinery EVM uses applies to SVM, with Solana-specific behavior wired in automatically:

• Commitment-aware finality. A network-level svm.commitment is injected per method at the param position Solana expects, so every upstream answers at the same level. Cache finality follows Solana's rules rather than EVM's: commitment: finalized is the latest rooted slot — a head that advances every ~400ms — so only slot-pinned reads (getBlock, getTransaction) at a finalized commitment are cached as immutable; moving-head state reads (getBalance, getAccountInfo, …) are realtime.
• A dedicated cache block. SVM caching is configured under database.svmJsonRpcCache (same schema as evmJsonRpcCache, and both may share one backend). SVM cache keys are case-preserving, because base58 pubkeys and signatures are case-sensitive.
• Write guards. sendTransaction, sendRawTransaction, and requestAirdrop are never auto-dispatched to a second upstream by retry, hedge, or probe mirroring. Note the asymmetry with EVM, where eth_sendRawTransaction is hedgeable.
• A per-upstream slot poller. Tracks processed and finalized slots plus the blockstore-ingestion watermark; an upstream that fails getHealth or ingests shreds without replaying them is cordoned out of routing until it recovers.
• Native error passthrough. Solana JSON-RPC codes and error.data reach the client unchanged — notably -32002 SendTransactionPreflightFailure with its RpcSimulateTransactionResult — so @solana/web3.js and @solana/kit keep working.

See erpc.svm.example.yaml for a full configuration, and the SVM docs for details.

This setup is ideal for development and testing purposes. For production environments, we recommend extending your configuration with dedicated premium providers and advanced failover settings. See our Configuration Guide for more details.

• Retries, failover, circuit breakers & hedged requests: every call is routed to the fastest healthy upstream, automatically.
• Re-org-aware permanent cache: serve reads from cache, stay consistent across chain reorgs, and eliminate redundant upstream calls.
• Hosted gRPC cache by Goldsky: plug in Goldsky's read-only cache of indexed chain data to serve historical reads without hitting your upstreams.
• Automatic method routing: no need to track which provider supports which eth_* (EVM) or Solana method.
• Configurable rate limits: set hourly or daily rate limits and compute-unit budgets per upstream to control usage and cost.
• Selection policies: influence which upstreams serve traffic — e.g. cheap-first until error-rate or block-lag thresholds are crossed.
• Consensus & data integrity: compare results across upstreams, enforce consensus, and penalize nodes that disagree or return stale data.
• Unified error handling: consistent, normalized error codes and messages across every provider.
• Flexible authentication: basic auth, secrets, JWT, SIWE and more.
• Smart batching: aggregate multiple RPC or contract calls into one.
• Observability: track throughput (RPS), errors, and latency per upstream from a single Grafana dashboard.

• 🔵 Moonwell: How eRPC slashed RPC calls by 67%
• 🟢 Chronicle: How eRPC reduced RPC cost by 45%

eRPC provides several CLI commands beyond the default server start:

Validate a configuration file (TS, JS, or YAML) and report any errors, warnings, or notices. Useful in CI pipelines to catch misconfigurations before deployment.

erpc validate erpc.yaml
erpc validate erpc.ts

Parse a configuration file and output the fully resolved configuration with all eRPC defaults applied. Supports YAML and JSON output. This is useful for inspecting what your final config looks like after eRPC fills in all default values (retry policies, timeouts, selection policies, etc.).

# Output as YAML (default)
erpc dump erpc.yaml

# Output as JSON
erpc dump --format json erpc.ts

# Compare two configs (e.g. before/after a migration)
diff <(erpc dump old-config.yaml) <(erpc dump new-config.yaml)

1. Clone this repository:

git clone https://github.com/erpc/erpc.git

2. Install Go dependencies:

make setup

3. Create a configuration file:

cp erpc.dist.yaml erpc.yaml
vi erpc.yaml

4. Run the eRPC server:

make run

By contributing to this project, you agree that your contributions may be used in both the open-source and enterprise versions of the software. Please review our Contributing Guidelines and Contributor License Agreement before submitting your contributions.

Apache 2.0