Hi, my name is Andrey, and I work with blockchain data analytics, mostly in EVM-like networks.
In practice, that means working with things like token prices across exchanges, NFT flows, liquidity depth in DEX pools, lending-related activity, flashloan opportunities, and other on-chain signals that can be turned into useful analytics.
What pulled me into this area was the nature of blockchain data itself.
Unlike traditional fintech systems, blockchain data is open and immutable. Once something is written to the chain, it is usually there forever. That creates a very unusual environment for analytics: you can track how funds move, how wallets behave, how contracts are used, how liquidity appears and disappears, and how entire systems evolve over time.
But there is an important practical detail here.
On-chain analytics does not start with charts or SQL. It starts with access to the network.
To collect data, you need a stable way to talk to blockchains. Very quickly, this turns into an infrastructure problem: nodes, RPC, APIs, sync status, availability, rate limits, and cost.
At a high level, analytics comes down to two things:
- knowing which contracts, events, and transactions to inspect;
- being able to extract that data reliably and at scale.
The first part is hard, but manageable.
The second part is where things get expensive and painful.
The old model stopped working
The most direct solution is to run your own nodes and use their APIs.
But that is no longer trivial.
For example, running Ethereum execution + consensus infrastructure now requires a serious machine: fast NVMe storage, a lot of RAM, and a decent CPU. In practice, this can easily mean something like 4TB NVMe, 64GB RAM, and a modern processor. And even with the hardware ready, there is still sync time. Sometimes more than 72 hours.
So the market naturally evolved a different offer:
Don’t run your own nodes. Use our RPC. Start on a free tier, then upgrade to paid plans when needed.
A few years ago, this model worked surprisingly well.
Free plans were often enough to build an MVP, test ideas, and even run small products. And if things grew, paid plans or PAYG usually made sense.
But over time, that changed.
If I look back at roughly 2018–2020, that period felt like a very good time for on-chain analytics. Hardware was much cheaper, networks were smaller, and workloads were lighter. Then L2 adoption accelerated, transaction costs dropped, usage exploded, and the amount of chain data grew massively.
As a result, the economics changed too.
What used to be true:
- hardware was affordable;
- free RPC plans were often enough for early analytics workloads;
- self-hosting was still realistic for many developers.
What changed:
- NVMe prices increased sharply;
- large SSDs became much more expensive;
- free RPC plans became heavily restricted;
- those free plans became almost useless for serious analytics workloads;
- paid plans started at a level that is hard to justify for solo builders and small teams;
- and once the workload grows, costs can climb very quickly.
At that point, collecting data from Web3 networks — or building a small analytics startup on top of them — became much less accessible than it used to be.
Why I started self-hosting anyway
I hit this problem myself.
I needed to make a large number of heavy requests across multiple networks. Free providers were no longer enough, and paying commercial rates for the amount of traffic I needed did not feel rational.
That left very few options.
The main one was obvious: run my own nodes.
I did not want to do it. Not because of the hardware alone, but because of everything that comes with it: updating node software, monitoring sync state, dealing with lag, handling failures, and generally maintaining a small fleet of infrastructure.
Still, I did it.
I started with one node. Then another. Then more.
And very quickly I ran into another problem: a node by itself is not a solution.
Nodes need updates. During updates, they can fall behind the network. After updates, they need time to catch up. If production traffic is hitting a lagging node during that period, things stop behaving the way you want them to.
That naturally led to the next step: if I wanted stable access, I needed at least two nodes in HA mode and something in front of them.
HAProxy worked — until it didn’t
I chose HAProxy.
It can route traffic, run health checks, and generally do what a load balancer is supposed to do. On paper, the setup looked fine: two nodes behind HAProxy, traffic balanced between them, one node can go down for updates while the other keeps serving requests.
And yes, that setup worked.
But over time, I realized that HAProxy was not really the right abstraction for the problem I was solving.
What I actually needed was not just balancing. I needed routing logic that understood Web3-specific realities:
- whether a node was truly synced;
- whether it was still catching up;
- whether it should be used for archive-only requests;
- whether a consensus endpoint should be handled differently from execution traffic;
- whether one provider or node was more appropriate for a specific route or workload.
HAProxy is powerful, but maintaining this kind of logic there became too uncomfortable and too brittle for my use case.
That is when I decided to build a dedicated service for it.
Building my own RPC aggregator
The idea was simple:
build a layer that can aggregate different sources, route and balance requests between them, understand which nodes are healthy, which are behind, which are suitable only for certain request types, and which should not be used at all.
In other words, not just a generic load balancer in front of nodes, but a service built specifically around the realities of Web3 infrastructure.
That is how my RPC aggregator appeared.
At this point it is still in alpha, but it already covers some of the pain points that pushed me to build it in the first place:
- aggregation of multiple providers and self-hosted nodes;
- separate routing for execution, archive, and consensus traffic;
- balancing and request routing;
- infrastructure checks that are more practical than using a generic reverse proxy alone.
Why I’m opening it up
At some point I realized something else: this setup is already larger than what I personally need for my own workloads.
So instead of keeping all of that capacity to myself, I decided to open it up in alpha.
Right now I am not trying to sell it.
What I care about more is understanding whether this is actually useful to other people dealing with similar problems:
- on-chain analytics;
- bots;
- infra tooling;
- archive-heavy workloads;
- consensus or beacon access;
- high-volume RPC use cases that do not fit well into free-tier providers.
If that sounds relevant, I’m happy to share access in exchange for honest feedback.
What I want to learn is simple:
- is this actually useful in practice?
- which networks or routes are missing?
- where are the weak points?
- what should be improved first?
If there is interest, I can also write a more technical follow-up about the architecture itself: how the routing layer works, why I moved away from a pure HAProxy-based setup, and what kinds of infrastructure problems start appearing once you build this for real analytics workloads.
If this is relevant to your work, feel free to reach out.
Telegram: @ddkand
Top comments (0)