Forem: Petar

Why scalable RPC infrastructure matters for Web3

Petar — Wed, 18 Jun 2025 12:00:33 +0000

A single-region RPC endpoint works—until it doesn’t.

Every decentralized application depends on reliable access to blockchain data. Whether you're building a DeFi dashboard, NFT marketplace, or onchain analytics engine, your DApp communicates with the chain through an RPC interface—usually via a node provider API.

But how that connection is structured under the hood plays a critical role in user experience, system performance, and scaling efficiency. What looks like “just an endpoint” can quietly become your DApp’s biggest bottleneck.

The hidden risk of monoregional RPC endpoints

Most teams start with a single RPC endpoint provider, often hosted in one region. It's simple, predictable, and easy to integrate—until usage scales or your audience grows globally.

Figure 1: The hidden risk of monoregional RPC endpoints; Source: ETHBelgrade hackathon slides

Problems arise when:

Users in different geographies experience high latency
Traffic spikes cause delays or dropped requests
Indexers miss data due to stale sync
Frontends feel slow—even when the DApp is “working”

This happens because the underlying RPC node infrastructure wasn’t designed for performance.

RPC infrastructure is backend infrastructure

RPC isn’t just a data pipe—it’s a critical service layer.

Treating it like production infrastructure means asking:

Where are the nodes located?
Are the nodes always warm, or spun up on demand?
Is there load balancing across regions and cloud zones?
How are failures and congestion handled?
Is polling the only model, or is streaming supported?

These questions affect every interaction between your users and the blockchain.

The evolution: Global RPC architecture

To solve these challenges, the industry has begun moving toward geo-distributed RPC endpoints—an evolution of the traditional RPC provider API model.

Instead of a static endpoint tied to one node, modern RPC providers now offer region-aware routing and backend abstraction. Think of it like a CDN, but for blockchain API traffic.

Figure 2: Global RPC architecture idea definition; Source: ETHBelgrade hackathon slides

Key features of these global architectures include:

Geo-routing: End users are served from the nearest available node
Persistent warm nodes: No cold start latency
Automatic failover across regions
Streaming support via WebSocket or gRPC
Live monitoring of performance by region

This approach is especially important for DApps with international users, latency-sensitive use cases (e.g. trading bots), or high-volume data needs.

Case study: The Global Node concept

One example of this shift is the Global Node model, first introduced as an open-source prototype during the ETHBelgrade hackathon. The project, initially called Unstoppable RPC Endpoint, proposed intelligent aggregation of multiple RPC endpoints across cloud providers and regions.

Figure 3: Unstoppable RPC Endpoint architecture; Source: ETHBelgrade hackathon repo

The system evaluated each endpoint in real time based on block height, availability, latency, and load. It then dynamically routed requests to the optimal node—functioning as a smart global load balancer for blockchain traffic.

Now implemented in production by RPC providers like Chainstack, the Global Node approach offers a scalable answer to the blockchain scalability bottleneck—and sets a new bar for RPC provider APIs that need to serve real-time, global decentralized applications.

RPC performance benchmarks that matter

Whether you're self-hosting or using a managed RPC endpoint provider, here are the latency goals your DApp should aim to hit:

RPC operation	Target latency
`eth_call`	< 250ms
`getBalance`	< 300ms
tx confirmation	< 1s
event stream tick	< 500ms
contract logs (10k blk)	< 1.5s

If your RPC node setup isn’t hitting these across regions, users will feel the delay—even if your DApp is technically functional.

Figure 4: Global RPC provider benchmark extract; Source: Chainstack Compare Dashboard—Ethereum

Should you self-host your RPC node?

Self-hosting offers control, but not scale. Most internal setups:

Operate from a single region
Lack elastic scaling and intelligent routing
Suffer from cold node startup time
Require constant maintenance and monitoring

For teams building global decentralized applications, the tradeoff usually isn't worth it. The benefits of using a modern, distributed RPC provider API—with built-in redundancy and performance optimization—often outweigh the costs of managing your own infrastructure.

Figure 5: Costs of managing your own infrastructure; Source: Chainstack

What to look for in a modern RPC endpoint provider

If you're evaluating RPC providers for production use, here are the key questions to ask:

Are backend nodes geo-distributed?
Is there region-aware request routing?
Are nodes persistent and warm at all times?
Is WebSocket or gRPC streaming available natively?
Are latency and error metrics transparent?
Is pricing predictable regardless of traffic?

These indicators help separate basic RPC endpoint providers from infrastructure built to scale with you.

Figure 6: Unstoppable RPC Endpoint differentiation; Source: ETHBelgrade hackathon slides

Bringing it all together

As Web3 matures, the demands on infrastructure are increasing. Fast RPC calls, stable indexers, and low-latency alerts are no longer luxuries—they’re requirements.

If you're building globally, you need RPC architecture to match.

Not just a single endpoint—but a distributed, intelligent RPC node layer that keeps your DApp responsive, resilient, and ready for scale.

The future of RPC is global.

Make sure your stack is too.

The Evolution of RPC Infrastructure Billing Models

Petar — Wed, 07 May 2025 16:34:00 +0000

From hourly node pricing to usage complexity—and the rise of capacity-based RPC infrastructure

If you’ve built anything in Web3 over the past few years, you’ve likely felt the same friction I have: infrastructure billing that feels like a moving target.

You’re not just asking how to scale—you’re asking how much your RPC node usage is going to cost when you do. And too often, the answer is: it depends.

But it wasn’t always like this.

🧱 Era 1: Buying Hours, Not Output

In the early days of blockchain development, we ran our own full nodes. Ethereum, BNB, Solana—whatever chain we needed, we spun up geth, parity, or solana-validator on a cloud VM, paid by the hour, and hoped for the best.

The model was straightforward: provision compute, pay for uptime.

Scaling, though, was manual and brittle. You added more nodes to handle traffic spikes. If you hit performance ceilings, you threw more CPU at the problem. You paid the same whether your app made ten requests a second or ten thousand—what mattered was how long the machine ran.

Costs weren’t tied to actual demand—they were tied to time.

It was simple, but far from efficient. Most teams overprovisioned just to be safe.

Then came managed blockchain node API providers, and the model started to change.

⚖️ Era 2: Usage-Based Pricing—With Asterisks

The second generation of RPC infrastructure came with shared nodes, elastic scaling, and pay-as-you-go APIs. Providers like Alchemy, QuickNode, Infura, and Helius promised: only pay for what you use.

It sounded like a massive leap forward for anyone building apps on top of blockchain RPC nodes.

But the details revealed new complexity. “Usage” wasn’t flat-rate. It was weighted by method and intensity.

A request to get the latest block number might cost 1 unit. A call to eth_getLogs over 10,000 blocks? That could cost 60x more. The more compute or data you pulled, the faster you burned through your plan.

To handle this, providers introduced:

Compute units (CUs)
API credits
Method-based multipliers

The logic made sense from an infrastructure perspective. The developer experience? Not so much.

You weren’t just building dApps—you were budgeting for method calls.

Instead of focusing on product features or user needs, you started thinking in quotas:

Are we calling too many “heavy” RPC methods?
Will this dashboard blow up our blockchain API quota?
Should we remove logs indexing to stay under budget?

It worked—but it punished experimentation and scale. Especially for projects running bots, cross-chain analytics, or real-time data.

⚡ Era 3: Capacity-Based Billing for RPC Nodes

Recently, a new model has started gaining traction—capacity-based pricing for blockchain infrastructure.

Instead of charging per request (or per credit), you pay for sustained throughput—how many RPC requests per second your app is allowed to send.

This is best represented by services like Chainstack’s Unlimited Node. You select an RPS tier—25, 100, 250, 1000—and get unlimited blockchain API access within that capacity.

No multipliers
No quotas
No overage fees

It’s like paying for an internet connection by bandwidth instead of per byte.

This approach flips the priorities:

✅ You stop optimizing around billing edge cases
✅ You start designing for real-world performance
✅ You plan capacity the same way you would with any backend system

🧭 The Evolution in One Line

We went from:

💻 Paying for machines → 🔢 Paying for complexity → ⚡ Paying for capacity

And in that final stage, blockchain infrastructure finally feels like modern backend engineering.

📊 Comparing Blockchain Node API Billing Models

Billing Model	Example Providers	What You Pay For
Dedicated Instances	Self-hosted, Ankr, early Infura	Uptime (hours of node operation)
Usage-Based (CU/Credit)	Alchemy, QuickNode, Helius	Method-weighted usage (per request)
RPS-Tiered (Capacity)	Chainstack (Unlimited Node)	Sustained RPC request throughput (RPS)

Each model had its time and use case.

Need a personal dev node for light querying? Self-hosted or usage-based still works.
Running an indexing pipeline, trading bot, or AI agent? Throughput-based pricing gives you predictability.

✅ Why Capacity-Based RPC Pricing Makes Sense Today

It’s not always the cheapest model—but it’s the clearest.

You know what your system can handle, and what it will cost. No surprises if someone uses a heavy method. No overage charges when you hit your dashboard too hard.

From a builder’s point of view:

No request rationing
Predictable billing
Scale without financial guesswork

It also shifts how we think about blockchain node APIs: not as metered utilities, but as high-availability infrastructure you can rely on.

🔁 Real-World Friction, Resolved

I’ve worked on projects that had to throttle features—not because of performance, but because of billing complexity. We paused bots during market spikes to avoid massive bills. We held off on backfills to conserve credits.

Those constraints weren’t technical. They were billing constraints.

With RPS-tiered RPC nodes, that anxiety disappears. You plan for traffic. You build what you need.

🧩 Final Thoughts on RPC Node Billing Models

The evolution of RPC infrastructure billing mirrors the broader maturity of the space.

We’ve gone from raw compute, to complexity-based credits, to something that finally aligns with how we build everywhere else: capacity-driven, product-friendly pricing.

It's not about counting requests anymore. It's about asking:

What kind of performance does my app need to thrive?

The best billing model is the one that lets you stop thinking about billing.

If you’re experimenting with capacity-based models or have war stories from the credit-era, I’d love to hear them in the comments.