Suppose you’re Goldman Sachs and you need to read or write data to a public blockchain, chances are you need to use an RPC (Remote Procedure Call) provider that runs nodes for that chain. RouteMesh makes it easier and cheaper to access data across every blockchain.
Since its stealth inception, RouteMesh has been serving billions of requests per month.
Now, we are live.
Currently, the crypto RPC market is similar to the early electricity market: vertically integrated providers, no standardized interconnects, and high variance in quality.
The next phase is the introduction of the grid layer that abstracts away producers to make the market more efficient overall.
RPC Industry History
The promise of blockchains was that everyone would run their own node to connect to the network and be their own sovereign person. That thesis has not played out as the cypherpunks hoped. The requirements to run an Ethereum full node are not for the faint of heart. Instead, we had the rise of Infura – a provider that would host nodes for you and you could connect to them. This was a sufficiently good solution given there were 2 blockchains people cared about – Bitcoin and Ethereum.
However, somewhere along the line three things happened:
The amount of data on public chains started to become serious (CryptoKitties ~2017)
The number of chains increased (Polygon, Optimism, Base, Arbitrum started coming online)
The number of people wanting to get data from nodes increased (tax, trading, analytics, compliance use cases)
All of this led to the rise of high performance providers that offered professional infrastructure. Introducing: Alchemy and Quicknode.
Alchemy was the first out of the two and managed to rapidly scale to a $10b valuation by 2021. Quicknode wasn’t too far behind raising $60m for their last round (publicly). These providers came from operators who were:
Experienced web2 engineers that could deploy infrastructure
Could adapt to the needs to the market quickly
All of this was well and good until we realised that the multi-chain future wasn’t 10 chains, but hundreds, thousands and probably millions of chains.
Node Operations
Running a node is a fairly thankless job in the industry. Client software keeps updating, compute resources are variable, physical hardware needs to be provisioned – all for you to just access the chain. As each of these new chains makes different trade-offs to achieve scalability, running a node for that particular chain becomes more challenging.
For example, here are the requirements for running different types of nodes for respective chains (full // archive):
Bitcoin:
CPU: 4 Cores // 4 Cores
RAM: 8 GB // 16 GB
Storage: 1TB // 1 TB
Ethereum:
CPU: 4 Cores // 4 Cores
RAM: 16 GB // 16 GB
Storage: 2 TB // 10 TB
Solana:
CPU: 24 Cores // 32 Cores
RAM: 256 GB // 1 TB+
Storage: 2 TB // 500 TB
As you can see, the more “modern” the chain and the more it focuses on performance, the heavier the requirements to run a node. A Solana node requires extremely specialised hardware to run correctly that can easily cost $50,000.
Now, this is the state of the industry *today*. As we have million of chains coming online, keeping up with all of these chains isn’t going to be possible for one single provider.
Provider Fragmentation
Now, let’s assume you’re a node provider company.
How do you know where to allocate your resources?
When you have a new customer they want you to have all the chains they need. But running all of these chains requires real expertise and capital.
You have two options to navigate this:
Only support what the market has a lot of demand for (unproven for new chains)
What your existing customers, who are paying, request
Charge premium and run a dedicated node for just that chain (not practical for many customers)
This makes it challenging for any single provider to support every chain.
The Customer Perspective
This means that to access any chain that exists, you need to have multiple providers to cover the chains you care about, and more for redundancy. This creates a strange labyrinth of stitching providers together that can become hard to manage for the average company reading/writing data from blockchains.
In addition each provider has the following aspects that need to be managed:
Inconsistent error codes and error handling to make implementing fallbacks challenging.
Differing pricing models with the notion of “compute units” and non-archive vs archive requests.
Rate limits that can cause bottlenecks in your application if you receive a large amount of traffic.
Subscription costs that force a certain level of usage and need to be consumed optimally to get value for money. Overage prices are much more expensive.
Varying reliability levels for different chains at different times.
Clearly this becomes a real issue that any enterprise-grade crypto company needs to solve for. Many have some form of “internal routing” that they use but the sophistication to solve all of these problems isn’t a small project by any means. Solutions such as eRPC or NodeCore try to solve this by providing a load balancing mechanism, however they fall short in the fact that a lot of work is still required to configure them and they still do not solve many of these issues – especially around pricing.
The Solution
Introducing RouteMesh: the “interconnet/grid” equivalent for RPC access. We ran into all of the issues above when supporting our analytics product (read more here) and that’s built our conviction to focus on solving this problem for the broader industry.
In essence, RouteMesh is an RPC provider that doesn’t run any nodes but has access to the largest inventory of nodes globally. Because our model is permissionless (providers don’t need to sign up explicitly), it means:
We support over 1000+ chains out of the gate
If a call fails, we can retry until we find a node where it does work
Pure usage based pricing, no subscriptions or overage prices.
Given we have the combined inventory of all nodes, our rate limits are much higher.
Because we have to know everything about our providers and nodes, it means we can do things like:
Having standardised pricing in US dollars (no intermediate units)
Give you access to the fastest nodes versus cheapest nodes (we have different API key types)
Highest rate limits in the industry (aggregate capacity of all nodes)
Standard URL schemes making it super easy to integrate (no URL maps required)
Outside of the technical innovation present, we’ve also innovated on the business model by enabling route-based pricing.
Rather than saying our pricing is $x/million, we have the concept of a route which is the chain<>method combo.
For example, if you call eth_call on Polygon that would be a specific route with its own prices. This means that chains and routes with heavy coverage can give very competitive prices while newer chains with less support are priced with their limited coverage.
“But doesn’t using an aggregator add more latency/cost” – no, the opposite actually!
On pricing: because we can use a blend of providers, our pricing typically helps customers save anywhere from 40-70% of their RPC costs while offering a more reliable service.
On latency: We have router instances in different regions of the planet and have benchmarks for nodes in that region meaning we can serve requests sometimes as quickly as 7ms! You can view our metrics here. All our metrics are public and we know the metrics of everyone else too.
Next Steps
We’ve been building the earliest version of this for the past 36 months as part of the analytics stack until we decided to make the whole company this one piece. In the coming months we’ll be expanding to offer support for:
Solana, Bitcoin and other VM ecosystems
MEV protected transaction sending
Onboarding more providers & chains
Our work has just begun but we’re thankful for our existing customers & providers to be already serving billions of requests per month.
There’s also work we want to do in bringing more transparency around this part of the industry and introducing standards to help everyone from node clients, RPC providers and end customers.
If you’re a RPC user or provider, feel free to reach out to see how we can work together!
Visit https://routeme.sh to lear more!
