RPC Client Research
A deep dive into the RPC client landscape
RouteMesh is now in a spot where we have thousands of nodes in our system. Part of that means we can start to understand the software client landscape of these chains themselves. There’s not a lot of data around what client software runs on what chains... until now.
Methodology
When we add a new node in our system, we basically benchmark that node and extract as much information as we can around it. In a future post I will be writing about these tests and what they extract but in the meantime I want to focus on the node client type information.
For those of you that don’t know, to run a blockchain there are different software types known as “clients”. The most popular client for Ethereum is “geth” (short for go-ethereum). However, over the years there have been many more types of clients. If a blockchain’s consensus, operations or mechanisms are different then they will adapt from the geth codebase or develop a new client software type entirely. However, for major chains, teams may write competing software client types for the chain which makes the chain more resilient through what is known as “client diversity”.
Because of the thousands of nodes we have in our system, we can quantify client diversity in a way that hasn’t really been done in the ecosystem. This article is about sharing that. Every few days our systems will re-discover the state of our nodes to track things like client version updates, configuration changes made by providers to the nodes etc.
The Data
For context, you can follow along all the client data yourself here: https://routeme.sh/clients. We have almost 30+ RPC providers in our system at RouteMesh and are relatively confident in our coverage of the ecosystem, although it is still incomplete as we cannot have every node. It should serve as a rough proxy though.
For the clients that are run by all the RPC providers integrated, a large majority run on geth.
We thought this would be a bit more evenly split but it did surprise us. In second place is reth, by Paradigm. There is a nuance in the data in that we aren’t counting how many requests these nodes are serving by client but rather how many absolute nodes there are. However, they should be pretty closely linked together.
To make the data easier to understand, we have all the data listed as a table that shows client by market share percentage too.
To better understand this table, here’s how you want to interpret it:
Node share is what % of nodes run this client type
Version (L is for latest observed and O is for the oldest observed)
Total nodes (how many nodes we have for that given client type)
Chains (how many chains that client operates on)
Latest seen (when did we last gather information about nodes for that client type)
If we sort the table based on chains, rather than market share we start to notice different data.
There is geth which is truly the most cross-chain dominant client, then there’s about clients that follow:
reth
nitro
besu
Then you have these slightly multi-chain clients like cdk-erigon, nethermind, skaled, zkSync, erigon, go-opera, OpenEthereum, bor etc.
To better understand, let’s actually study some of these clients individually.
geth
Here we have a breakdown of how many nodes run on every chain stack ranked. Clearly geth is the backbone of the crypto rpc industry. It is the client software for almost 427 chains across the crypto-verse.
We can also see a breakdown of how the version distribution of the clients are set across the board. Geth version are a lot more spread across the board. The most recent version is version 17 that was first released in Feb 2026.
The most dominant version is 1.7.2 which was released on Oct 14th, 2017! If you had a single provider with a single node with this version of geth, the provider would be affected as that node can easily be taken down. With RouteMesh’s model this doesn’t become an issue as there are strong fallbacks in place.
1.17 had quite a few improvements that matter if you’re running extensive RPC queries. The fact that a large portion of nodes aren’t on this show the challenges of calling RPCs as it really depends on how up to date your provider is with node client versions for each chain they support!
Another fun thing we can see from our data is which providers are running which client versions and how many nodes they run for that network. We don’t have all the Alchemy/Quicknode nodes in our system so the data isn’t perfect (they charge per extra node unfortunately), but regardless this is the visibility we have.
What’s neat is we can also go the other way and see what clients/versions each provider runs as well. Below is the data around which node clients and version ranges Alchemy runs for their node fleet. This is the level of transparency we believe the industry should have.
reth
For those of you that don’t have context, reth is the child of the Paradigm folks. It’s interesting how in the data you see how the chain and the client have these close relationships.
The top supported chain for reth is... Base. Followed up Ethereum, Optimism, Base Sepolia, Ethereum Sepolia and finally Binance Smart Chain.
Unlike geth, reth has less versions spread across which indicates more alignment of versions. Providers are a lot more up to date with reth than they are with geth which is much more comforting to know.
The latest major version is reth 2.0 (released last month). However, that’s one of the least adopted versions of the client. Version 1.11.3 is the most dominant version. It was released March 2026 (so not too long ago)! Version 1.10.2 was released back in Feb.
For some reason it seems like providers wait a few months before updating to the latest client version (or at least for it to show in our dataset).
nitro
Next up on our list is Nitro which is very Arbitrum-ecosystem dominant.
Compared to geth, nitro runners seem to be a lot more being on-top of running clients that are fairly recent. While there is 3.9.9, 3.9.8 is the most dominant version number.
Taking a snoop on the Github, 3.9.8 is the latest version! Woo! 3.9.9 is still a release candidate that is being iterated on. As we can tell here, it feels like the Arbitrum ecosystem is more co-ordinated from a client <> provider perspective. nitro powers so many little/obscure chains too.
Learnings
The pipeline of developers working on clients, to providers taking the time to adopt new client versions, is a gradual roll out process. RPC providers are the backbone of the industry so understanding how they operate gives the entire ecosystem more visibility about how requests are served and handled.
Overall it’s really fun to be able to dig deeper into the lower level workings of how blockchains really work. I don’t think there’s any live data around clients and how they operate across every live chain so I hope this research creates more insight and transparency!
You can check out all the data yourself at: https://routeme.sh/clients.















Second order effect of routemesh is that it discourages client diversity without your intervention. Geth is a more mature implementation than reth and so nodes that receive requests based on performance based routing will bias towards the most stable software unless they see massive performance gains (cost savings) in running the riskier node.
If you want to encourage client diversity you could add a handicap of sorts to geth users. How you would be sure this isnt spoofed im not sure.