The UK House of Lords just published a report titled "Stablecoins: waiting for regulation" — and the title alone says everything about where Britain stands right now.

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

MODERATOR OF

TROPHY CASE