In Review

Planned

In Progress

Completed

Main Roadmap

<ul><li>For new blocks and logs properly subscribe across upstreams and make sure if one is down others are used transparently</li><li>Separate transport layer so that there can be multiple destinations including Websocket, Kafka, AWS SNS, Webhooks, etc</li></ul>

Subscriptions to new blocks and logs (Websocket, Kafka, SNS, etc)

Kasra Khosravi

Adding support for generic JSON-RPC protocols in eRPC, with essential features such as load balancing, fault tolerance, rate limiting, singleflight (to solve thundering herds), and monitoring. This enable eRPC to be used for various purposes, domains, and use cases, such as: • Other blockchain protocols like Bitcoin, Solana, and TON (making it possible to use eRPC for any blockchain by default)• Non-blockchain JSON-RPC applications• Custom JSON-RPC implementations This improvement would make eRPC more universal and flexible solution for handling JSON-RPC traffic across a wide range of projects.

Support for Generic JSON-RPC Protocols

Thanee Charattrakool

A control panel frontend. A first iteration may just be a text editor for <code>erpc.yaml</code> and stop/start buttons for the containers.

Web console for config and observability

jaybuidl

Most rpcs provider have a paid-per-call model. Batching eth_call with multicall3 contract would significantly reduce rpc cost on most providers

Auto-batch multiple eth_calls for evm upstreams using multicall3 contracts

Clément

<ul><li>Support third-party providers (alchemy, quicknode, etc.) for rate limiting</li><li>This will correctly record used quota when different methods consume different quota on providers (e.g. eth_getLogs is more expensive vs eth_blockNumber)</li></ul>

Credit unit mapping for rate limiters

Allow defining failsafe policy templates and introduce a ‘method’ field to have customized setup for different methods.For example get_blockNumber timeout and retry policy will be different than trace_debug* methods that are usually slower and more expensive.<pre><code>projects:
 - id: main
 networks:
 - architecture: evm
 evm:
 chainId: 42161
 failsafe: my-network-policy
 
 upstreams:
 - id: blastapi-chain-42161
 #...
 failsafe: my-upstream-policy

failsafe:
 templates:
 - id: my-upstream-policy
 policies:
 - method: 'trace*'
 timeout:
 duration: 15s
 retry:
 maxCount: 2
 delay: 2s
 - method: '*'
 timeout:
 duration: 1s
 retry:
 maxCount: 3
 delay: 500ms
#...</code></pre>

Allow per-method failsafe policy definitions and reusable policy templates

Aram Alipoor

<ul><li>Backfill historical data in parquet format (or alternative) for fasting fetching</li><li>Allow users to define which specific data they need prefilled (e.g. only contracts / events they care about)</li></ul>

Pre-warming historical data into cache

<ul><li>Increase RPS simply with more instances of eRPC</li><li>To enable this rate limits and some other state must be shared across all instances</li></ul>

Horizontal scaling via shared state

This is useful for security/ data validation and data reconciliation.I e. You make a request, it goes to multiple (at least 2) RPC vendors, the responses are compared, if they are the same then it's successful, if not then there is an error.Maybe this is a field you can select for a given endpoint

Reconciliation between RPC vendors

Brendan Coughlan

<ul><li>Have two modes controlled by an env var or config:<ul><li>Simple: Only low-cardinality tags, Mainly external system interactions (cache calls, upstream RPC calls, etc)</li><li>Detailed: More tags such as full request data, Internal eRPC logic mainly for debugging purposes</li></ul></li><li>Add a pre-configured Jaeger UI container in the docker-compose.yml</li></ul>

Integrating OpenTelemetry tracing

<ul><li>rpc-level batching for incoming requests</li><li>auto-batch requests towards upstreams</li><li>allow multi-chain requests within 1 request</li></ul>

Smart Batching

It's received by the server (erpc) as a gzipped request and erpc decompresses it and passes it to the upstream servers.&nbsp; We're currently offering this for some of our customers via a lua script in openresty.&nbsp; The benefit to our customer is it helps them save egress costs when running in clouds that charge egress fees.&nbsp; Would love it if this was something erpc could support.For example:<pre><code>echo '{
&nbsp; "jsonrpc":"2.0",
&nbsp; "method":"eth_chainId",
&nbsp; "params":[],
&nbsp; "id":1
}' | gzip | curl -i --request POST \
&nbsp; --url http://localhost:4000 \
&nbsp; --header 'Content-Type: application/json' \
&nbsp; --header 'Content-Encoding: gzip' \
&nbsp; --compressed \
&nbsp; --data-binary @-</code></pre>

Request decompression

Caleb Call

<ul><li>automatic finding nodes for chains + normalizing their request/responses so you don't try to find which one supports trace/geth_trace/etc</li></ul>

v0.1

Discovery and Routing

<ul class="tight" data-tight="true"><li>rate limiters,</li><li>circuit breakers,</li><li>timeouts,</li><li>retries,</li><li>hedges,</li><li>empty response handling</li></ul>

Proxy and Load-Balancer

Some setting in our erpc.yaml (like <code>projects.networks.[i].public = true</code>) which would automatically add all the public upstreams for our network, plus we could add our own custom ones on-top of that just with the normal way of specifying <code>upstreams</code>) By public upstreams, this refers to <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://chainlist.org/">https://chainlist.org/</a> RPC endpoints. Chainlist is <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://github.com/DefiLlama/chainlist">open source</a> and has an extremely wide avalibility of RPCs for each chain, so it is a great choice for this. <img src="https://fb-usercontent.fra1.cdn.digitaloceanspaces.com/0191bdd6-10fa-74f1-a34d-3e284b94b6a4.png" data-width="100%" data-align="left"> It would be great if the implementation of this could also come with some reasonable failsafe defaults to aggressively ignore ones that are constantly failing (many of these RPCs are bad, so we need to filter them out fast). Relevant conversation and context: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://t.me/erpc_cloud/449">https://t.me/erpc_cloud/449</a> (@WesleyCharlesBlake already started down this path) This would be absolutely HUGE for supporting multichain applications, as now developer no longer need to worry about specific RPC endpoints at all, and can add new chains to their app extremely easily.

Public RPC Aggregator

User should be able to define number of in-consensus nodes for a particular method/request, for example:<pre><code class="language-yaml">projects:
 - id: main
 networks:
 - architecture: evm
 evm:
 chainId: 1
 failsafe:
 # ...
 consensus:
 # Total number of nodes that must be tried to fetch the data.
 # for example eth_getBlockByNumber to be fetch from 3 nodes.
 maxCount: 3
 # Minimum required nodes to consider the response accurate.
 # For example at least 2 nodes must return same block info.
 # For methods like eth_blockNumber it can mean at least 2 responses are needed and then pick the highest value.
 minCount: 2
</code></pre>

Add consensus and data integrity failsafe policy

Would be awesome to have per project custom caching policies, with a config like this for example: ``` type CachingPolicy = { /// Type of caching policy (maybe it could be possible to have something like “block” and “reorg” type?) type: "duration", /// The json rpc method to cache method: string, /// Some regex params for which to ignore caching if present in the params, or maybe something like in the upstream with an ignore + allow properties ignoreForParams: string[], /// Custom properties for duration based caching duration?: { period: string } } ``` My use case would be around the pimlico endpoint <code>pimlico_getUserOperationGasPrice</code> , like a 10sec caching, to have faster response and reduce pimlico credits consumption if we got a user activity spike on our end. I think ti could also be useful for frontend applications to use a duration based caching for the <code>eth_getBlockByNumber</code> and params <code>latest</code>, with an ignore pattern like <code>^(?!latest$|earliest$).*$</code>

Extend caching config (TTL, Per-method policies, Multiple storage)

Quentin Nivelais

Same as the custom Alchemy and Envio custom evm types, would be awesome to have this for pimlico <a target="" rel="noopener noreferrer nofollow" class="link" href="https://docs.pimlico.io/infra/platform/supported-chains">(since it support a lot of chains) </a>, and has a “multichain” api url: <code>https://api.pimlico.io/v2/{chainId}/rpc?apikey=[YOUR_API_KEY_HERE]</code>

Add Pimlico transport

<ul class="tight" data-tight="true"><li>usage of error metrics per network, upstream, method</li></ul>

Observability

<ul class="tight" data-tight="true"><li>header-based, token-based, ip-based, CORS, etc)</li></ul>

Authentication

Help Center

Improved

Fixed

erpc

Rejected

High Priority

Low Priority

v0.5

v0.4

v0.3

v0.2

v0.x rc

Quarterly Roadmap

Monthly Roadmap

Share your idea, explain the impact in your use-case and project, provide details on important capabilities and nice-to-have points.