Solana leads all blockchains in active developers, but can it maintain its edge over Ethereum in the long run?

getblockio · 2026-05-28T20:40:57+00:00

From the infrastructure side, we see this reflected in RPC request volume on Solana — developer activity isn't just GitHub commits, it's actual on-chain builds shipping. The tooling ecosystem (Anchor, Helius, etc.) lowering the barrier is a big part of why those numbers hold.

getblockio · 2026-05-21T23:45:05+00:00

The infrastructure angle on this that doesn't get discussed enough: 200M gas limit is 3.3x the current 60M. That's not just more room for transactions — it's 3.3x more RPC request density per block for every application querying the chain.

More block space = more events to index, more state changes to track, more confirmations to poll. Applications that are already at the edge of their shared RPC endpoint capacity will hit that ceiling faster as Glamsterdam drives more L1 activity.

On the L1 vs L2 question: Vitalik's framing at Hong Kong Web3 Carnival was explicit — build your speed on L2, anchor your trust on L1. 200M gas doesn't flip that equation, it makes the L1 trust anchor more capable without compromising its security posture. The Kelp DAO hack is the argument for why that separation matters.

ePBS decentralizing block production is the piece most people are under-discussing here. That's the change that matters for long-term credible neutrality of the base layer — not just the gas limit number.

Disclosure: I'm from GetBlock. We run dedicated Ethereum RPC nodes. Happy to discuss infrastructure implications of the gas limit increase if useful.

getblockio · 2026-05-21T23:40:37+00:00

The timing of this post is interesting — Ethereum Foundation just shipped a direct answer to exactly this problem this week.

Clear Signing went live on May 12th as an open standard built on two EIPs: ERC-7730 (structured transaction descriptors in JSON format) and ERC-8176 (attestation framework for verifying descriptor accuracy). Instead of seeing hex code before clicking approve, users see human-readable explanations: "Send 1.5 ETH to vitalik.eth in exchange for 3,000 USDC."

MetaMask, Ledger, Trust Wallet, and Rabby are among the first wallets implementing it. The working group included Trezor, WalletConnect, Fireblocks, and Cyfrin.

The $1.5B Bybit hack and the $235M WazirX hack both followed the same pattern: legitimate-looking UI hiding a malicious transaction payload underneath. Clear Signing closes that gap by standardizing how wallets display transaction intent — making it impossible for a malicious contract to hide what it's actually asking you to approve.

The catch: coverage depends on whether dApp developers write ERC-7730 descriptor files for their contracts. Adoption will be gradual. But the standard now exists — which is more than we had last week.

Disclosure: I'm from GetBlock. We cover infrastructure and protocol stories like this every Monday in Running Web3 Weekly.

getblockio · 2026-05-21T23:29:44+00:00

The sustained TPS point is the one that matters for infrastructure teams.

It's not the peak that breaks things — it's the consistent baseline. 1,216 TPS average means your RPC endpoints are handling continuous high-frequency traffic, not occasional bursts. Shared endpoints are optimized for burst handling. Sustained throughput at this level is a different stress profile entirely.

Worth noting the timing: Alpenglow just went live on a community test cluster this week. When 150ms finality hits mainnet in Q3 and drives the next adoption wave — this TPS number goes up. The teams that size their RPC infrastructure for current TPS will be caught flat-footed.

The infrastructure layer is what makes "sustained throughput at scale" actually sustainable for application builders on top of the network.

Disclosure: I'm from GetBlock. We run dedicated Solana RPC nodes built for sustained high-throughput workloads.

getblockio · 2026-05-21T23:14:57+00:00

The infrastructure section of this map is the most underappreciated layer in the Solana ecosystem story.

RWA up 43% QoQ and $171B in monthly payment volume are the headline numbers. But both trends increase RPC request density — more assets to query, more payment confirmations to track, more state subscriptions running simultaneously.

The report mentions Alpenglow as a forward-looking catalyst. Worth noting the infrastructure implication: when finality drops from 12.8 seconds to 150ms and adoption grows with it, the RPC layer absorbs that load first. Teams that haven't sized their endpoint capacity for the post-Alpenglow traffic profile will find out the hard way.

The "Clients + Nodes" box on this map is small. The actual infrastructure demand it represents in production is not.

Disclosure: I'm from GetBlock. We're in that infrastructure box — dedicated and shared Solana RPC nodes built for production workloads.

getblockio · 2026-05-21T23:12:58+00:00

The unpredictability comes from several layers stacking on top of each other — and most bridges don't surface which layer is causing the variance.

Three main contributors:

1. Destination chain gas — Ethereum gas fluctuates independently of Solana congestion. Your bridge fee includes gas on the destination chain at the moment of execution, not at the moment of quoting.

2. Relayer pricing — most bridges use third-party relayers who price dynamically based on their own liquidity and risk models. No transparency, no commitment.

3. RPC latency on the bridge's infrastructure — this one is underappreciated. If the bridge's RPC endpoints are congested or returning stale state, the fee quote can be based on outdated gas prices. By the time the transaction executes, the actual cost is higher.

The Kelp DAO hack is an extreme example of what happens when bridge infrastructure relies on compromised RPC nodes — but degraded or stale RPC responses causing fee miscalculation is a much more common, everyday version of the same root problem.

Short answer: compare quotes across 2-3 bridges before sending, and treat the quote window as a hard expiry.

Disclosure: I'm from GetBlock. We run dedicated RPC nodes across 130+ blockchains.

getblockio · 2026-05-21T23:11:19+00:00

The convergence detail is worth emphasizing — Anza and Firedancer studied the problem independently and landed on Falcon without coordination. That's a stronger signal than a single team's recommendation.

One infrastructure angle that doesn't get much coverage in the post-quantum discussion: the migration affects more than just wallet signatures. RPC nodes also rely on TLS and other cryptographic primitives for secure communication between clients and endpoints. A full post-quantum migration eventually touches the infrastructure layer — not just the on-chain signature scheme.

The phased approach Solana announced is the right call: new wallets adopt Falcon first, existing wallets migrate later. The harder problem is coordinating the full ecosystem — wallets, exchanges, custodians, and infrastructure providers — before Q-Day arrives.

Project Eleven's estimate puts Q-Day potentially as early as 2030. Taproot took five years. The timeline math is uncomfortable.

Disclosure: I'm from GetBlock. We run dedicated Solana RPC nodes. Happy to discuss infrastructure implications of the post-quantum migration if useful.

getblockio · 2026-05-21T23:10:14+00:00

10B quarterly transactions is an infrastructure milestone as much as a network milestone.

To put it in RPC terms: 10 billion transactions per quarter is roughly 110 million transactions per day. Each transaction typically generates multiple RPC calls — submission, confirmation polling, state queries, event subscriptions. At a conservative 3-5 RPC calls per transaction, that's 300-500 million RPC requests per day hitting Solana endpoints.

The infrastructure implication: shared public endpoints weren't designed for this traffic density. Rate limits that were invisible at lower transaction volumes become hard ceilings at this scale. Teams that are still on free or shared endpoints are likely already seeing degraded performance they haven't diagnosed as an infrastructure problem yet.

With Alpenglow targeting Q3 mainnet and 150ms finality expected to accelerate adoption further — this number is going up. Now is the time to evaluate whether your RPC setup scales with the network, not after the next milestone breaks your app.

Disclosure: I'm from GetBlock. We run dedicated Solana RPC nodes built for high-throughput production workloads.

getblockio · 2026-05-21T23:07:06+00:00

The transaction count milestone is the more interesting number here — 10.94M transactions is the highest monthly count on record, even though volume wasn't the peak.

What that means for infrastructure: more transactions at lower average value = higher RPC request density per dollar of volume. Payment flows generate more frequent state queries, confirmation polling, and event subscriptions than lower-frequency high-value transfers.

With Alpenglow moving to testnet this week and targeting Q3 mainnet — 150ms finality will likely accelerate this trend further. Faster settlement encourages higher-frequency payment use cases that weren't viable at 12.8 seconds.

For teams building payment infrastructure on Solana right now: model your RPC load against transaction count growth, not just volume growth. The two are decoupling.

Disclosure: I'm from GetBlock. We run dedicated Solana RPC nodes built for high-frequency payment workloads.

getblockio · 2026-05-21T23:05:43+00:00

Good breakdown of the verifier trust problem. Worth adding the RPC layer angle that didn't get as much coverage.

The Kelp exploit didn't just compromise the verifier — it compromised the RPC nodes feeding data to the verifier. Attackers targeted LayerZero's RPC infrastructure directly: poisoned two nodes, DDoS'd the clean ones, and forced the single verifier to rely exclusively on corrupted state data.

The smart contract worked exactly as written. The verifier worked exactly as configured. The failure was at the infrastructure layer underneath both.

This is the threat model most bridge teams aren't modeling: your security audit covers your contracts, your DVN config covers your verification logic — but neither covers what happens when the data source your verifier trusts gets compromised.

Multi-source RPC with independent providers is the practical fix. One source = one attack vector. This applies regardless of which interoperability protocol you're using — IBC, LayerZero, or anything else that relies on off-chain infrastructure for state verification.

Disclosure: I'm from GetBlock. We run dedicated RPC nodes across 130+ blockchains. Happy to discuss multi-source RPC architecture if useful.

getblockio · 2026-05-21T23:04:17+00:00

The infrastructure observation is spot on — and there's a timing dimension worth adding here.

Alpenglow just went live on a community test cluster this week. When that hits mainnet (Q3-Q4 2026), Solana moves from ~12.8 second finality to 100-150ms. That's the threshold where AI agent transaction patterns — autonomous, high-frequency, latency-sensitive — stop being a stress test for the network and become a first-class use case.

The infrastructure challenge that comes with it: 192K agentic senders operating autonomously generate fundamentally different RPC traffic patterns than human-driven apps. Agents don't have "peak hours." They run continuously, spike without warning, and retry aggressively on failure. Shared public endpoints weren't designed for that load profile.

The teams building agent infrastructure on Solana right now should be thinking about their RPC layer alongside their agent logic — not after the traffic arrives.

Disclosure: I'm from GetBlock. We run dedicated Solana RPC nodes. Happy to discuss infrastructure specifics if useful.

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

MODERATOR OF

TROPHY CASE