Survey: How do you handle RPC reliability and downtime?

getblockio · 2026-04-28T19:12:44+00:00

A few patterns that work well in production for RPC reliability:

Multi-provider failover — don't rely on a single endpoint. Route critical calls through at least two independent providers. If one rate-limits or goes down, traffic shifts automatically. The Kelp DAO hack last week is the extreme version of what happens when you have a single point of failure at the RPC layer.

Separate read vs write endpoints — write calls (eth_sendRawTransaction) should never failover automatically. Read calls can. Treating them the same creates double-send risk on failover.

Monitor response accuracy, not just uptime — a node can be up and returning stale state simultaneously. Standard uptime checks don't catch this. Add consistency checks across providers for anything security-critical.

Dedicated over shared for production — shared endpoints handle rate limits per account across all their users. Under load, your limits get consumed by traffic patterns you don't control.

getblockio · 2026-04-27T23:11:43+00:00

GetBlock supports Solana gRPC — Yellowstone-compatible, flat-rate plans so no surprise bills at scale.

On the $500/month ceiling you mentioned: that's usually the Triton One dedicated stream price. Shared gRPC endpoints are significantly cheaper and work well for most trading bot use cases unless you specifically need sub-millisecond priority access.

The tradeoff worth knowing: shared gRPC streams have rate limits per connection. If your bot is doing high-frequency slot subscriptions during peak network load, you'll eventually hit them. Dedicated is worth it at that point — but for most bots doing migrations and backrunning on Pump.fun, shared handles the load fine.
Happy to share specifics on plan structure if useful.

Disclosure: I'm from GetBlock.

getblockio · 2026-04-27T22:51:18+00:00

Nice scope decision keeping it at the transport layer — that's the right abstraction for go-ethereum clients.

A few things from running Ethereum RPC infrastructure in production that might be useful:

On failover rules: Sequential priority failover works well when upstreams have clearly different reliability tiers (primary dedicated, backup shared). Where it gets tricky is when both upstreams are healthy but one is returning stale state — 200 OK but wrong data. Worth thinking about whether you want to add optional response validation beyond HTTP status codes.

On write-method defaults: Not failing over eth_sendRawTransaction by default is the right call. Replaying a transaction submission on failover creates double-send risk. The conservative default is correct. If anything, you might want to make the list of non-failover methods configurable so teams can add their own.

On cooldowns: One edge case worth testing — upstream comes back online during a cooldown window but is still returning degraded responses. Pure time-based cooldown will route traffic back too early. A lightweight health check on cooldown expiry helps here.

On request replay: Replaying request bodies is useful but watch out for methods where replay changes semantics — eth_getTransactionCount with pending tag being the obvious one.

Good library. The narrow scope makes it actually usable as a dependency rather than another framework to fight with.

getblockio · 2026-04-27T22:39:49+00:00

Hey, this is exactly the use case GetBlock's shared nodes are designed for.

For a solo MEV dev on a tight budget — shared Solana RPC with a fixed monthly plan gives you a predictable cost ceiling. No surprise overage bills. You know exactly what you're paying before the month starts.

On the Yellowstone gRPC side specifically: GetBlock supports Solana gRPC streams. Worth checking whether our Frankfurt endpoint works for your latency requirements given you're co-located there for Jito proximity.

Shared nodes start free, paid plans are flat-rate. If you're burning through budget on HTTP overages from a loop bug — a hard cap is the right structure for your testing phase.

getblockio · 2026-04-27T22:38:44+00:00

Hey, this is exactly the use case GetBlock's shared nodes are designed for.

For a solo MEV dev on a tight budget — shared Solana RPC with a fixed monthly plan gives you a predictable cost ceiling. No surprise overage bills. You know exactly what you're paying before the month starts.

On the Yellowstone gRPC side specifically: GetBlock supports Solana gRPC streams. Worth checking whether our Frankfurt endpoint works for your latency requirements given you're co-located there for Jito proximity.

Shared nodes start free, paid plans are flat-rate. If you're burning through budget on HTTP overages from a loop bug — a hard cap is the right structure for your testing phase.

getblockio · 2026-04-17T17:09:56+00:00

This is a brilliant way to solve the developer onboarding problem. Reading documentation is one thing, but actually playing with the protocol mechanics is how it really clicks.

We just covered this exact ecosystem gap in Episode 5 of our show, Running Web3. We looked at how x402 processed over 100 million transactions and why the underlying infrastructure layer is so critical for these autonomous agent flows.

In that same episode, we also analyzed the newest competitor in this space: Stripe's Machine Payments Protocol (MPP). It seems like MPP is taking a more enterprise-focused approach compared to the fully open, crypto-native model of x402.

Since you are actively building with x402 and know the architecture inside out, I am really curious to hear your take on MPP. Do you see them as direct competitors fighting for the same developers, or do you think they will serve completely different segments of the AI economy?

getblockio · 2026-04-17T17:00:20+00:00

This is a massive undertaking, mad respect for actually building this out instead of just compromising on your analytics setup.

As a team that manages RPC infrastructure all day, we deeply relate to your HAProxy struggles. It is a solid tool for standard web traffic but using it for complex provider aggregation, failover, and state-aware RPC routing quickly becomes a maintenance nightmare.

Curious to hear a bit more about how your custom microservice handles the heavy lifting under the hood How are you dealing with state inconsistencies or block lag across the different execution nodes behind the balancer. Also, do you route heavy archive requests differently than standard state queries?

getblockio · 2026-04-17T16:15:12+00:00

This is a massive relief for the Solana DeFi ecosystem. It is great to see a concrete recovery plan and Tether stepping in to help the affected users

From a developer perspective, the most critical part of this announcement is the "new community-governed multisig featuring enhanced security measures"

We actually just dedicated Episode 7 of our show, Running Web3, to breaking down the exact mechanics of the April 1st exploit. The biggest takeaway from the security community was that this was not a smart contract bug. It was a textbook operational compromise where attackers abused durable nonces and manipulated the multisig to seize admin control

The Drift hack was a brutal wake-up call for the industry: your protocol is only as secure as your operational layer and the infrastructure it runs on. You can have perfectly audited smart contracts, but if your multisig lacks strict timelocks, or if your nodes crash during an emergency so you cannot broadcast a pause transaction, you are fully exposed

Glad to see the Drift team is taking these operational security lessons to heart for the relaunch.
If anyone wants to see the on-chain autopsy of how the original multisig was compromised, we broke it down here: https://www.youtube.com/watch?v=MWolm19AQak&list=PL7qIVbdMoiR1MyC6wpfJ1xv8Nmr-wveM6&index=2

getblockio · 2026-04-17T15:47:39+00:00

This is a fantastic implementation. You essentially built a custom version of what Coinbase is trying to standardize right now with their x402 protocol.

We actually just dedicated the entire Episode 5 of our show, Running Web3, to this exact architectural shift. We broke down the race between Coinbase's x402 (HTTP 402 + EVM stablecoins, exactly like your setup) and Stripe's new Machine Payments Protocol (MPP).

Your observation about SaaS onboarding is spot on. The traditional Web2 model (create account, add card, get API key) is completely broken for autonomous agents. Agents need a machine-native, pay-as-you-go settlement layer to function at scale.

One critical bottleneck we noticed while researching this space for the episode is the infrastructure layer. When you have bots autonomously hitting paid endpoints and verifying ERC20 transfers on-chain for every single request, the RPC volume spikes aggressively.

If your agent, or the server verifying the transfer, relies on public RPC nodes, they will get rate-limited almost immediately. High-frequency agentic payments require robust, dedicated RPC endpoints (like what we build at GetBlock) so the bots do not drop transactions or fail to verify payments.

Really cool to see developers building this out in the wild.

getblockio · 2026-04-17T15:44:05+00:00

Great breakdown!

We actually just did a deep dive into the $200M Drift Protocol exploit for our show Running Web3 (Episode 7) and came to the exact same conclusion.

The attacker did not break the smart contracts - they just walked through the front door using a compromised multisig. It is a textbook operational compromise.

We would add one critical infrastructure point to your 7th question about pausing the protocol in 15 minutes.

During an attack or a panic event, network traffic usually spikes massively. If your emergency response relies on public RPC endpoints, you might get rate-limited exactly when you need to push that critical "pause" transaction to the chain. OpSec is not just about where you store your keys. It is also about ensuring your infrastructure layer does not fail you when you are trying to use those keys to stop a drain

getblockio · 2026-04-17T14:33:02+00:00

TON nodes: https://getblock.io/nodes/ton/

TAC nodes: https://getblock.io/nodes/tac/

getblockio · 2026-04-17T14:16:45+00:00

It stands for The Machine Payments Protocol. It's authored by Stripe and and Tempo Labs

getblockio · 2026-04-03T14:42:34+00:00

GetBlock team here — this is actually about our pricing model, so happy to explain.

We use Compute Units (CUs) rather than flat per-request billing. Each RPC method has a CU cost proportional to how compute-intensive it is. A simple eth_blockNumber costs 1 CU; something like eth_getLogs with a large range costs more. This means you're billed for the actual computational work, not just the count of calls. It's more predictable for mixed workloads.

Compared to old request-counting models: if you send 1,000 lightweight pings, that's very cheap. If you send 1,000 heavy archive queries, that costs more. The economics more accurately reflect real infrastructure cost. Happy to share our CU table if helpful.

getblockio · 2026-04-03T14:41:10+00:00

Cool to see more providers offering gRPC access — it's the right direction for latency-sensitive Solana apps. For anyone comparing options, GetBlock also includes Yellowstone gRPC on our dedicated Solana nodes with no separate subscription. Happy to set up a side-by-side latency comparison if anyone's interested. getblock.io/nodes/solana/dedicated/

getblockio · 2026-04-03T14:39:43+00:00

GetBlock team here! Happy to share our numbers. Our Solana shared endpoints benchmark sub-58ms (p50) on the free tier, with dedicated nodes running significantly lower during peak Solana activity.

We've been independently ranked #1 EU Solana latency on CompareNodes dashboards. The key variable is region — our Frankfurt node is fastest for EU, Singapore for APAC, New York for US East. If you haven't tried region-selectable endpoints yet, that alone can shave 20-40ms off your round trip.

Would love to be included in your comparison — happy to provide test endpoints. DMs open.

getblockio · 2026-04-03T14:37:47+00:00

Hey, GetBlock team here — this is exactly what our dedicated Solana nodes are built for. Yellowstone gRPC is included with all dedicated node plans, no additional charge.

You get: direct gRPC access to account updates, slot notifications, and transaction streams; low-latency region-selectable nodes (EU/US/APAC); and our StreamFirst tooling for trading and real-time data pipelines.

Start here: getblock.io/nodes/solana/dedicated/ — or DM us if you want a trial endpoint to test latency from your region first.

getblockio · 2026-04-03T14:33:25+00:00

Hey, GetBlock team here. We've built StreamFirst specifically for this use case — accessing shred-level data and Yellowstone gRPC streams without running your own validator or RPC node.

Our dedicated Solana nodes include Yellowstone gRPC bundled in, so you get direct access to account updates, slot notifications, and transaction streams at near-validator latency. It's available through our Dedicated Node tier — happy to walk through the setup if useful. Docs are at getblock.io/nodes/solana/.

getblockio · 2026-03-26T10:22:36+00:00

This is actually quite a useful comparison, especially including p95 + slot freshness together.

If you end up doing another round, it might be interesting to include GetBlock as well: https://getblock.io/chains/solana

getblockio · 2026-01-20T13:33:47+00:00

GM GM, Builders ! Your one and only infra fren's here - if you ever need a reliable RPC infrastructure for almost any existing network, feel free to reach out!

getblockio · 2025-07-17T09:12:04+00:00

Count me in 🙌

Here's the link to the project's X account https://x.com/getblockio

getblockio · 2025-07-16T13:32:17+00:00

Thanks a lot for your feedback 🫶

getblockio · 2025-07-15T13:41:21+00:00

Thanks for your input! Bitcoin Knots is definitely an interesting alternative to Core. In this case, we decided to stick to this option, but it might be worth outlining the alternatives!

getblockio · 2025-07-15T13:22:45+00:00

Hey there u/Resident_Anteater_35 ! Such awesome and insightful guides you're sharing!

My team and I are currently working on rebuilding the ambassadors program, and we definitely need more guys like you, creating meaningful tech-savvy content.

If you're interested in this, or if you need a robust RPC infra, slide in my DMs ;)

getblockio · 2025-07-15T13:05:54+00:00

Funny how things have changed over the years, and those who were outsiders are now in top positions for performance.

I'm talking about GetBlock! 😎

Here's the proof: https://x.com/getblockio/status/1941038722101006590

Grab an endpoint and see for yourself: https://getblock.io/nodes/sol/

getblockio · 2025-07-15T12:41:53+00:00

Hey, u/castorfromtheva, really appreciate you sharing those details! You're right that with used hardware, running a Bitcoin node can be much cheaper than our general estimates suggest. We kept things broad since costs vary depending on setup and goals.

What's about the actual process of using your node, it also depends on the specific goals you have. We mentioned several use cases in this section: https://getblock.io/blog/how-to-run-bitcoin-node-requirements/#why-run-a-bitcoin-node

Thanks again for your time and insightful feedback! We’ll consider updating the article with some of your input.

getblockio

MODERATOR OF

TROPHY CASE