DEV Community: GetBlock

The Real Battle Isn't About Stablecoins — It's About Who Controls Money Movement

GetBlock — Thu, 25 Jun 2026 17:49:04 +0000

Jamie Dimon, CEO of JPMorgan, just escalated his criticism of stablecoin rewards in the CLARITY Act debate. His message: "The banks will not accept it."

On the surface, this is a regulatory squabble about yield incentives. But if you're building on blockchain, this is the fight that determines whether your infrastructure matters for real-world payments—or stays a niche playground.

The Setup: What's Actually Being Fought Over

The CLARITY Act (Crypto Law Intelligent Regulatory Framework) is Congress's attempt to create clear rules for stablecoins. One contentious part: how much yield/rewards can stablecoin projects offer to encourage adoption?

The positions:

Crypto side: Rewards (yield, incentive programs) drive adoption. Users need reasons to switch from bank accounts. Without them, stablecoins compete on convenience alone—which banks already control.
Banking side (Dimon): These rewards are unfair competition. Banks can't offer similar yields on checking accounts (regulatory restrictions). So stablecoins get an artificial advantage.

Dimon's actual quote: "The banks will not accept it. And I don't think this is right either. It gives them an advantage that's not sustainable."

Translation: This will destroy our deposit-gathering model if we allow it.

Here's What's Really Happening

This isn't about stablecoin technology. This is about settlement rails and who controls them.

Right now:

You want to send money to someone. You use your bank.
Your bank moves money through SWIFT, ACH, or Fed Wires.
Banks earn on this flow. They're the settlement layer.

Stablecoins on blockchain offer an alternative:

You hold stablecoins. You send them on-chain. They settle instantly, cheaper, 24/7.
No bank gatekeeping.
No settlement delays.
No SWIFT fees.

Banks understand this existential threat. So they're pushing regulation that makes on-chain settlement less attractive.

The reward debate is the proxy war. If you can't offer yields to encourage adoption, fewer people use stablecoins, fewer people move money on-chain, and the banking system retains its monopoly on settlement.

Why This Actually Matters to Developers

You might be thinking: "I build dApps, not payment infrastructure. This doesn't affect me."

Wrong. This affects you in several ways:

1. Infrastructure Adoption

More stablecoin users = more on-chain transaction volume = more demand for RPC nodes, indexing services, block explorers, etc.

If regulation kills adoption incentives, you get less volume, which means:

Fewer use cases justify infrastructure investment
Infrastructure becomes more commoditized (which hurts everyone's margins)
Regional infrastructure diversity suffers

2. The "Financial Rails" Competition

Whoever controls settlement rails controls the most valuable real estate in finance.

Scenario A: Banks keep control → Crypto becomes a trading/speculation layer, not payment infrastructure
Scenario B: On-chain settlement grows → Blockchain becomes critical infrastructure, and everything built on it has real utility

The regulation being debated determines which scenario wins. Dimon knows this. That's why he's escalating.

3. Developer Economic Models

If on-chain payments become a real use case (vs pure DeFi trading), it changes what projects get funded:

More focus on payment rails, compliance, and real-world integration
Less focus on yield farming and casino-like mechanics
Different skill sets matter (payments engineering > DeFi math)

The developers who understand this shift first will be the most valuable.

The Regulatory Strategy (What's Actually Happening)

Banks can't outright ban crypto. So they're using three tactics:

1. Make Adoption Harder

Restrict how stablecoin projects can incentivize users
Require excessive compliance (different for stablecoins vs bank deposits)
Slow down approval timelines

2. Co-opt the Technology

JPMorgan created JPM Coin (a bank stablecoin)
If regulations favor "traditional finance-backed stablecoins," they win
You get blockchain rails, but controlled by banks

3. Regulatory Capture

Fund research arguing stablecoins are risky
Lobby regulators directly
Fund politicians on both sides

Dimon's recent statements are part of Tactic 1: making the case that stablecoin rewards are unfair and should be restricted.

What's At Stake

Let's be concrete:

If banks win:

Stablecoins exist, but they're bank-run
DeFi and blockchain remain niche
Your infrastructure serves traders, not payment networks
Real economic activity stays in traditional finance
Blockchain is a technology, not an alternative system

If crypto (reasonably) wins:

Open stablecoins compete with bank stablecoins
On-chain settlement becomes a viable alternative for real transactions
Infrastructure matters because it's actually used
Blockchain becomes settlement infrastructure, not just a trading game

What Developers Should Actually Do

This isn't something you solve by tweeting. But it matters for your career and your project's future:

1. Understand the landscape

Know what stablecoins are trying to do. Know who's fighting this fight. This context is more valuable than learning the latest DeFi protocol.

2. Build for real use cases

If you're building on blockchain, ask: "Would a merchant or payment processor care about this?"

If the answer is no, you're building for traders. Which is fine, but know the difference.

3. Think long-term on infrastructure

If on-chain settlement becomes real, infrastructure becomes critical. If it stays niche, infrastructure is commoditized.

Position yourself accordingly.

4. Follow the regulation, seriously

CLARITY Act, MiCA (Europe), and Singapore's approach matter. They're determining the future of the industry. Reading the regulatory debate is as important as reading the technical specs.

The Uncomfortable Truth

Dimon isn't wrong that stablecoin rewards are a form of subsidy. But that's not the actual argument.

The actual argument is:

"Banks want to keep being the settlement layer. Stablecoins with adoption incentives threaten that. So we'll regulate them into oblivion."

"Stablecoins should be able to compete fairly on technology and incentives. If they're better, people should choose them."

This is the fight. The CLARITY Act is where it's being decided. And the outcome determines whether on-chain infrastructure becomes genuinely important or stays a niche tool for traders.

Dimon's escalation is a signal that banks are losing the technical battle (stablecoins work, people want them) so they're moving to the regulatory battlefield.

What Comes Next

Expect:

More regulatory proposals restricting stablecoin rewards
More pressure on Congress from both sides
Banks creating their own stablecoins (JPM Coin precedent)
Potential bifurcation: bank stablecoins (regulated, boring) vs open stablecoins (fighting for legitimacy)

The CLARITY Act probably won't end this. This is a multi-year fight.

But for you as a developer: pay attention. The outcome determines whether you're building financial infrastructure or a trading game.

What's your take? Are you building for real payment use cases, or is your project optimized for traders? How do you think regulation will shape what matters?

Drop your thoughts in the comments.

If you're building infrastructure and need reliable RPC access across multiple chains, check out GetBlock. We're thinking about long-term infrastructure, not short-term trading volume.

Ethereum's Public Goods Funding Crisis: Why Validator Redirected Revenue Matters for Developers

GetBlock — Thu, 25 Jun 2026 17:33:00 +0000

When Ethereum Foundation contributor Trent Van Epps raised the alarm about a potential "gradual funding challenge" across the ecosystem, he wasn't talking about market crashes or protocol security issues. He was talking about something quieter, but arguably more existential: how do we sustainably fund the infrastructure that keeps Ethereum decentralized?

A new proposal now circulating suggests validators could redirect between 0-10% of their staking rewards toward ecosystem funding. It sounds technical. But if you're building on Ethereum, this matters—a lot.

The Problem Nobody Wants to Talk About

Here's the uncomfortable truth: Ethereum's infrastructure runs on goodwill and grants.

Client teams, security researchers, specification writers, and core developers depend on funding from the Ethereum Foundation, grants programs, and increasingly—whatever private funding they can cobble together. As the Foundation reduces spending, and existing programs wind down, we're entering uncharted territory.

Unlike Bitcoin's mining-driven incentive structure, Ethereum doesn't have a clear path for validators to fund the public goods their entire network depends on. They earn rewards for securing the network. But securing the network isn't the same as building it.

Node operators run clients maintained by teams with shrinking budgets. dApp developers depend on stable RPC infrastructure. Security researchers discover bugs that could drain billions. And yet, none of this work is directly compensated by the consensus layer.

The result? A tragedy of the commons dressed up as decentralization.

The Validator Redirected Revenue Proposal: How It Works

The proposal is elegant in its simplicity:

Validators signal how much of their staking rewards (0-10%) they'd be willing to contribute to ecosystem funding
The system aggregates these signals
A governance mechanism distributes these funds to public goods projects
Validators maintain full control—it's opt-in, not mandatory

This isn't taxation. It's consensus-level fundraising.

What makes this different from existing grants:

It's sustainable. Grants programs depend on Foundation budgets. Staking rewards exist as long as Ethereum does.
It's decentralized. Validators vote with their rewards. No single organization controls where funds go.
It aligns incentives. Validators benefit from a healthy ecosystem. They have skin in the game.
It respects choice. No validator is forced to participate.

Why This Matters for Infrastructure Developers

If you're running an RPC service, maintaining a client, or building developer tooling, this proposal is your lifeline.

Consider the economics: an infrastructure provider serving dApps might run 50+ nodes across multiple regions. They earn nothing from validator rewards. Their costs are real: compute, bandwidth, monitoring, security audits. Their revenue depends on finding users willing to pay for better service—which is harder when free services exist.

A sustainable funding mechanism changes the game. It means:

Better client implementations. Teams can hire full-time researchers instead of piecing together funding from five different sources.
More security audits. Fewer critical vulnerabilities shipping to production.
Better developer experience. Tools get maintained instead of abandoned.
Regional diversity. Small operators in underserved regions can stay competitive.

At GetBlock, we've seen firsthand how infrastructure fragility cascades. When a major client team loses funding and slows down development, it affects every node operator downstream. When security research dries up, the entire ecosystem becomes more fragile.

This proposal doesn't solve everything, but it creates a foundation (pun intended) for long-term thinking instead of quarter-to-quarter scrambling.

The Tension (There's Always a Tension)

Critics will raise legitimate concerns:

"This centralizes funding decisions." If a single governance mechanism controls redistribution, yes. The proposal needs careful design here. Decentralized grant protocols, milestone-based funding, and transparent evaluation processes are critical.

"Validators should maximize returns." True. But validators who care about long-term network health might see ecosystem funding as enlightened self-interest. A network with broken infrastructure and security holes isn't worth staking on.

"This is soft consensus enforcement." If participation becomes normalized, there's social pressure to participate. But that's not intrinsically bad—it's how open-source communities have always worked.

"Why should we trust whoever distributes the funds?" We shouldn't. Transparency, governance, and accountability frameworks need to exist. This is a design problem, not a fatal flaw.

What Good Governance Looks Like

For this to work, we need:

Transparent evaluation. Public criteria for which projects get funded. No backroom deals.
Milestone-based disbursement. Funds released as work is completed, not upfront.
Community oversight. Not just the Foundation, but node operators, developers, and researchers voting on direction.
Diversity of recipients. Funding shouldn't consolidate around a few large teams. Smaller projects, regional efforts, and experimental approaches need support.
Clear success metrics. How do we measure whether funded work actually improved the network?

The Bigger Picture

This proposal is about more than staking rewards. It's about accepting that public goods require public funding mechanisms.

Bitcoin solved this through mining and path dependence. Ethereum is more complex. Consensus-level incentives, governance mechanisms, and explicit funding flows are necessary.

The question isn't whether to fund Ethereum's infrastructure. It's how to do it in a way that remains decentralized, transparent, and sustainable.

Redirected validator rewards are one mechanism. It won't be the only one. But it's a step toward treating infrastructure as what it is: essential public goods, not the charity case of the Ethereum Foundation.

For Developers: What You Should Care About

If you're building on Ethereum:

Monitor this proposal's progress. It will affect which infrastructure teams survive the next 5 years.
Advocate for funding infrastructure you depend on. If you run full nodes or use specific client implementations, make your needs known.
Support sustainable models. When tools you depend on ask for funding, take it seriously. Maintenance is work.
Think long-term. A blockchain with mature, well-funded infrastructure is more valuable than one with cheap bandwidth but fragile foundations.

The infrastructure that powers Ethereum isn't free. The question is just how we'll pay for it.

What's your take? Should validators redirect rewards toward ecosystem funding? What infrastructure needs are you seeing in the wild? Drop a comment below.

This post originally appeared on the GetBlock Engineering blog.

Every GetBlock Shared Node Plan Just Got Up to 75% More Compute Units

GetBlock — Tue, 23 Jun 2026 19:33:28 +0000

GetBlock pushed Compute Unit caps up by as much as 75% on all Shared Node plans, with no price change. Paid accounts were raised automatically. Here are the new numbers.

If you have ever watched a Compute Unit counter climb toward its ceiling in the last week of a billing cycle, this one is for you. In a quiet market, every request you fire is a request you pay for, and you would rather your RPC layer not eat into budget that belongs to your roadmap.

So we changed the equation. GetBlock has pushed the Compute Unit (CU) ceilings up on every Shared Node plan by as much as 75%, and left every price untouched. There is nothing to migrate onto and no upgrade to clear first. Whatever plan you run already does more for the same spend.

The new caps: up to 75% more, same price

This went live today and reaches the entire Shared Node range, both the three mid-tier plans we shipped recently and the tiers you have run for a while. Prices stayed put. The one thing that moved is the ceiling. Here is the full breakdown:

Plan	Price	Old CU cap	New CU cap
Starter	$49	50M	90M
Growth	$99	105M	185M
Advanced	$199	220M	385M
Scale	$349	400M	700M
Pro	$499	600M	1,000M
Premium	$699	900M	1,600M

In practical terms, that is far more requests on the plan you already pay for, the cushion you want when a launch takes off or traffic outpaces the roadmap. The end-of-month scramble to stay under your cap goes away.

Here is how GetBlock CEO Vasily Rudomanov framed it:

"Builders should spend their time shipping, not rationing requests. That conviction sits behind our latest upgrade: every Shared Node plan, from Starter to Premium, now includes 75% more compute units. It rests on deep infrastructure optimization and, just as much, on what our customers told us they needed. Our largest plans now clear 1.6 billion CUs, giving the most demanding teams room to build without over-provisioning. Together with the mid-tier plans we introduced recently, this makes GetBlock's Shared Node lineup one of the most flexible and cost-effective options across Tier 1 Web3 infrastructure. The fewer limits builders carry in their heads, the more they can put on-chain."

What you need to do (probably nothing)

Your next step depends on where you stand today, and for most readers there is none.

Already paying for a plan? You are set. We recalculated every account on our side, the higher caps are attached, and you can verify it in your dashboard right now. Nothing needs redeploying, and your keys keep working as before.

Running on Free? Switch to any paid tier and the raised caps apply from day one, at the same price every paying customer sees, boost included.

Let your plan lapse, or sitting in the grace window before it does? This is a good moment to come back. Same tiers, same pricing, more capacity than the day you walked away. No codes to punch in, nothing tucked into the footnotes, just a bigger allowance than before.

A few other things worth a look

Since the dashboard will be open anyway, a few recent additions deserve a look. We rolled out new mid-tier Shared plans to bridge the entry tiers and full enterprise workloads. They exist for the same reason these caps do: developers kept saying the leap from a small plan straight to enterprise was too steep, so we built the steps between.

Limitless Node gives high-volume teams dedicated capacity with no per-request ceiling. Our risk and compliance suite, Wallet Risk, Wallet Audit, and the Rug Pull Checker, lets you vet an address before funds pass through it. And TRON Energy rental cuts TRON network fees on USDT transfers by as much as 70%, no TRX staking involved, all from the same account and balance you already use.

Pick your tier

The caps are in place now, but the deal around them will not stay open forever. If sizing up has been on your list, this is as cheap as that headroom will ever get. Open the pricing page, run your numbers through the new calculator, and get back to the work that pulled you in to begin with: shipping.

https://getblock.io/pricing/

Top Crypto API Providers for Blockchain Developers

GetBlock — Wed, 17 Jun 2026 01:39:14 +0000

Every Web3 project hits the same infrastructure question early on. How do you get data out of the chain without running your own nodes? And how do you turn that data into something your app can actually use? For most teams, the answer is a blockchain API.

But "blockchain API" covers a lot of ground these days. Some providers give you raw JSON-RPC access to nodes. Others index everything into REST endpoints. A few focus on market data. The newer ones blend market, on-chain, and portfolio data into a single layer.

We've been evaluating what's out there lately. Part of that is because we build infrastructure ourselves. Part of it is because developers keep asking us what pairs well with GetBlock for workloads outside pure RPC. This post is the short version of that research: five providers, each doing something different, grouped so you can pick based on what you're actually building. Check this crypto wallet API breakdown for a deep dive into wallet APIs.

What Blockchain APIs Usually Cover

Before the list, a quick note on what these APIs actually do. Developers typically reach for a blockchain API for one of these reasons:

Wallet and portfolio data: balances, token holdings, transaction history across multiple chains
Market data: prices, volumes, tickers, historical OHLCV
On-chain analytics: address activity, exchange flows, derived indicators
Node-level access: JSON-RPC for reads and writes, smart contract calls, event subscriptions
Research and signals: curated news, token unlocks, fundraising data
AI integration: MCP servers and structured tools so LLM-powered apps can query crypto data directly

No single provider covers all of these equally well. The trick is matching the tool to the workload.

How We Picked These Five

We focused on providers with production traction, clear pricing, active development, and documentation a developer can actually read without getting lost. Each provider below occupies a distinct slot in a real stack.

1. CoinStats Crypto API

CoinStats Crypto API is relatively new to the API space, but the consumer app behind it has over 1M monthly users. The same data infrastructure is exposed through a REST API, and there's a dedicated MCP Server for AI agents and LLM-powered applications.

The easiest way to frame what CoinStats covers is this: CoinGecko or CoinMarketCap for market data, plus wallet data, plus portfolio analytics, all through one integration. Coverage is 100,000+ coins, 200+ exchanges (Binance, Coinbase, Hyperliquid, and others), 120+ blockchains, and 10,000+ DeFi protocols auto-detected per wallet address. For most crypto use cases (portfolio trackers, trading bots, tax tools, multi-chain wallet explorers, AI agents), that single integration replaces what teams typically stitch together from three or four separate providers.

A few things stood out during our evaluation. CoinStats MCP Server ships with 20+ tools that LLM-based apps can query directly, so Claude, Cursor, and other AI assistants can pull prices, wallet balances, DeFi positions, and portfolio data without custom API glue. Pricing is credit-based with a free tier, so cost scales with endpoint complexity rather than flat seat limits. Response format stays consistent across chains, which matters when you're aggregating a Solana address, an xpub on Bitcoin, and an EVM wallet into a single portfolio view. Check this crypto api guide for more.

Best for: portfolio trackers, tax and accounting tools, multi-chain wallet explorers, AI crypto assistants, and embedded fintech dashboards where market data, wallet data, and DeFi positions all need to come from one source. Probably the best fit for most crypto use cases simply because so much of the stack is consolidated into a single provider.

2. GetBlock

Since we're publishing this on our own blog, we'll keep this section matter-of-fact. GetBlock is a Web3 RPC provider. You get access to full and archive nodes on 130+ mainnet and testnet blockchains through JSON-RPC, REST, WebSockets, and gRPC. That includes programmable chains (Ethereum, BNB Chain, Polygon, Solana, and the major L2s), non-programmable ones (Bitcoin, Litecoin, Dogecoin), and AltVM chains like Aptos and Sui.

What GetBlock is built for is anything that needs direct node access without the overhead of running your own infrastructure. Smart contract interactions, transaction broadcasting, event subscriptions, historical state reads, and low-latency reads for trading workloads. We recently launched a dedicated Solana stack aimed at HFT and MEV teams, with roughly 150ms faster node state than standard shared endpoints.

GetBlock doesn't replace a data indexer or a market data provider. It's the layer underneath a lot of those: when you need the raw chain, fast, reliable, and geo-distributed, that's the slot it fills. Shared and dedicated node options cover everything from side projects on the free tier to production trading infrastructure under custom SLAs.

Best for: dApps, wallets, trading infrastructure, validators, analytics indexers, and any project that needs direct RPC access across many chains without the ops burden of managing nodes.

3. Covalent (GoldRush)

Covalent, now operating under the GoldRush brand, focuses on structured multichain data through a unified REST API. Coverage is 100+ EVM-compatible chains. The pitch is consistency: the same endpoint schema works on Ethereum mainnet as it does on a smaller L2. You swap one chain path parameter and the query works.

The product surface is broad. Wallet balances (ERC20, 721, 1155, native tokens), transaction history with decoded log events, NFT metadata and sales data, block-level details, gas prices, and cross-chain activity lookups in a single call. Covalent has also added an MCP server and a streaming API for sub-second updates. That puts it in the same conversation as CoinStats for AI-agent use cases on EVM data.

One thing to note: Covalent's strength is EVM. If your project lives entirely in Solana or Bitcoin territory, it's not the right tool. But if you're building an analytics dashboard, DeFi position tracker, or indexer across multiple EVM chains and you want structured, query-ready data rather than raw RPC responses, it fits well.

Best for: DeFi dashboards, multi-chain EVM analytics, NFT apps, compliance tools, and AI agents that need structured indexed data with a consistent query interface.

4. Messari

Messari is a different animal from the rest of the list. Where CoinStats and Covalent lean toward building blocks for apps, Messari sits closer to a research and intelligence layer. Coverage spans 40,000+ assets, on-chain metrics for 200+ DeFi protocols, news aggregation from 500+ sources, token unlock schedules, fundraising data, and analyst-verified diligence reports.

The API surface includes 15+ families across market data, signals, news, fundraising, research, token unlocks, stablecoins, protocols, and AI outputs. A Messari MCP server is available as well, letting AI assistants pull research content and live data during analysis workflows.

Messari fits best when the product you're building needs context rather than just raw data. Diligence platforms, institutional dashboards, research tools, portfolio apps with narrative overlays, compliance monitoring. Free tier rate limits are modest (20 requests per minute), and the deeper features live on enterprise plans with custom infrastructure options.

Best for: research platforms, institutional dashboards, diligence and compliance tools, and any application where analyst commentary, fundraising data, or token unlock tracking matters more than raw chain access.

5. Glassnode

Glassnode sits at the on-chain analytics end of the spectrum. The catalog runs 7,500+ metrics across 1,200+ assets, with 900+ API endpoints. Coverage includes addresses, derivatives, distribution, supply dynamics, exchange flows, and the long-running indicators Glassnode is known for (MVRV, SOPR, NUPL, and others). For Bitcoin specifically, it runs one of the longest continuous on-chain datasets in the industry.

Glassnode is built for quant desks, researchers, and anyone whose strategy depends on derived on-chain signals rather than live wallet data. Point-in-time (PIT) metrics are a distinguishing feature. They're immutable, so backtests don't suffer from look-ahead bias, which is a practical problem with most on-chain datasets. A Glassnode MCP server is also available for AI workflows, plus Snowflake and BigQuery integrations for teams pulling data into analytics pipelines.

One practical note: API access is only on the Professional plan with an API add-on, not the free tier. That positions Glassnode as a paid tool from day one, which matches who it's built for.

Best for: quant trading, institutional research, on-chain market analysis, and teams that need immutable historical metrics for modeling and backtesting.

Picking a Provider

The honest answer is that most real projects end up using more than one. A portfolio app might run CoinStats API for wallet and market data, GetBlock for RPC calls that need to hit chains directly, and Messari for research content. A quant desk might pair Glassnode signals with GetBlock's Solana stack for execution and Covalent for EVM-side indexing.

A few questions to guide the pick:

What data do you actually need? Market prices and wallet balances: CoinStats API. Raw RPC and node access: GetBlock. Structured EVM indexed data: Covalent. Research, signals, and narrative data: Messari. Derived on-chain metrics: Glassnode.
How many chains, and which ones? CoinStats and GetBlock both span 100+ networks including non-EVM chains. Covalent is EVM-focused. Glassnode and Messari emphasize depth over breadth.
Are AI agents in your stack? All five now expose data through MCP or similar structured access, but the surface area varies. CoinStats, Covalent, Messari, and Glassnode each ship MCP servers.
What pricing model fits? Credit-based (CoinStats, Covalent), subscription (Glassnode, Messari enterprise), or usage-scaled RPC plans (GetBlock). The right one changes with your scale curve.

If we had to pick one as the "start here" option for a new project covering most common crypto use cases, it would be CoinStats API. Market data, wallet data, portfolio analytics, and MCP access through one integration covers more ground out of the box than any other option on this list. For projects that then need low-latency RPC or chain-specific infrastructure underneath, pair it with something like GetBlock.

Best DeFi APIs and Tools: 2026 Overview and Rating

GetBlock — Fri, 12 Jun 2026 15:14:38 +0000

DeFi runs on data and execution. Wallets, dashboards, bots, and AI agents all lean on APIs. They read protocol state or route trades. Pick the wrong layer and integration drags for weeks.

But "DeFi API" is a loose label. Some tools return protocol-level metrics like total value locked. Others read a single wallet's positions across chains. Some route swaps directly through DEX liquidity. Others handle oracles, cross-chain messaging, or institutional analytics. They sit at different layers of the same stack.

This guide rates five of the best DeFi APIs and tools for 2026. It covers data, swaps, oracles, analytics, and cross-chain infrastructure. It also explains the node layer most of them depend on.

For a wider view across general-purpose providers, see our top crypto API providers guide.

What Is a DeFi API or Tool?

A DeFi API or tool is an interface for decentralized finance data and actions. It lets your code query on-chain state or submit transactions. No need to run your own node infrastructure. Some tools also handle off-chain logic like price oracles and cross-chain messaging.

The label spans four distinct categories. Knowing the difference upfront is half the decision when picking the right tool.

Protocol and market data. TVL, yields, fees, stablecoin supply, and similar aggregates across DeFi protocols.
Wallet and position data. What an address holds and where its funds are actively deployed across protocols.
Swap and execution. Routing trades across decentralized exchanges. Quote, price, and execution endpoints.
Cross-chain and oracle infrastructure. Tools that bridge chains, move messages between networks, or feed off-chain data into smart contracts.

One distinction matters more than the rest. Token balances tell you what an address holds. Token positions tell you where those funds are working. Many APIs return balances. Far fewer return positions. That gap shapes the ranking below.

How to Choose a DeFi API or Tool

Match the tool to the job. Six factors decide most choices:

Data category. Decide first. Wallet data, swap routing, oracles, and analytics are different jobs.
Chain coverage. Count the chains you need today. Then count the ones you will add next year.
Data freshness. Some endpoints update every minute. Trading workloads need sub-second latency.
Pricing model. Per-request and flat-fee billing scale very differently at production volume.
AI agent support. MCP servers let agents query an API directly. This matters more each year.
Reliability. Read the SLA. Check uptime history and rate-limit policy before committing.

The Infrastructure Layer: GetBlock

Most DeFi APIs deliver processed data. Prices. Balances. Positions. Swap routes. But something has to connect to the blockchain first and read it. That is the infrastructure layer.

GetBlock provides managed RPC nodes and blockchain data infrastructure across 50+ chains. Coverage includes Ethereum, Solana, BNB Smart Chain, Base, Arbitrum, Polygon, Avalanche, and more. Trading bots, DeFi apps, and AI agents all rely on this layer. They read on-chain state, monitor mempool activity, and submit transactions directly.

For latency-sensitive workloads, GetBlock offers dedicated nodes and a low-latency Solana stack. Both target HFT, MEV, and trading desks. Its Limitless Node product caps RPS instead of compute units. That suits sustained high-throughput workloads better than credit-based pricing.

GetBlock also runs a separate data product line above the RPC layer. Solana Swap Data Stream pushes real-time DEX swap events. Token Insight API returns token metadata, balances, and metrics across chains. Wallet Risk Check and Smart Contract Checks add risk and compliance signals.

If your product consumes pre-aggregated DeFi data, the five APIs below cover most needs. If it also interacts with the blockchain directly, add GetBlock's RPC infrastructure underneath.

The 5 Best DeFi APIs and Tools in 2026

Each option below leads a different category. The order reflects how often a DeFi builder will reach for each one. Pick by the job, not by the rank.

#1. CoinStats Wallet API

Best for: per-wallet DeFi positions and all-around DeFi data across chains.

CoinStats DeFi API is the strongest option for most DeFi use cases. Most APIs return balances. This one detects what funds are deployed.

That covers staking, lending, and liquidity pool stakes. It spans more than 10,000 DeFi protocols. The same call works across 120+ blockchains. Response format stays identical across chains.

CoinStats API also aggregates market data and portfolio analytics into the same stack. It tracks 100,000+ coins and 200+ exchanges. Realized and unrealized PnL layer on top. Average buy and sell prices come included. Performance metrics round out the data. CoinStats app powers 1M users each month on this same stack.

Token Security is part of the same product. Token Risks endpoint runs on Hexens Glider engine. It returns severity-ranked risk scores. It flags honeypots, hidden fees, and centralized mint or burn rights. It also covers blacklists, pausable transfers, upgradeable proxies, and unrenounced ownership.

AI agents reach all of this through CoinStats MCP Server. It exposes wallet, DeFi, portfolio, and security data through natural language. Most node and market-data APIs do not surface that layer.

For DeFi API selection in more detail, best DeFi APIs guide goes deeper.

Key features

Per-wallet DeFi position detection across 10,000+ protocols
120+ blockchains under one unified response format
100,000+ coins and 200+ exchanges tracked
Portfolio analytics with PnL and performance metrics
Token Security with severity-ranked risk scoring
MCP Server for AI agent and LLM access
Free tier with no card required

Pros

Reads DeFi positions, not just balances
One response format across every chain
Built-in portfolio analytics and Token Security
MCP-native for AI agent workflows
Generous free tier for early development

Cons

Not a raw RPC node provider
Not focused on protocol-level TVL charts
Pricing tiers scale with usage, not flat rate

Best suited for: wallets, portfolio trackers, DeFi dashboards, AI assistants, and analytics tools. They need balances and DeFi positions across many chains.

#2. 1inch API

Best for: DEX aggregation and swap routing on EVM chains.

1inch API is the leading DEX aggregator across EVM chains. It routes swaps through hundreds of decentralized exchanges to find the best execution price.

Aggregation Protocol covers Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Smart Chain, Avalanche, and others. It scans 400+ liquidity sources. The routing engine splits orders across pools to minimize slippage.

Limit Order Protocol adds gasless conditional orders. Users sign orders off-chain. Anyone can fill them on-chain when conditions match. Fusion mode adds intent-based execution with Dutch auctions for better pricing.

1inch also exposes Portfolio API, Token API, and Spot Price API. The API is REST-based. WebSocket support handles live pricing. A free tier covers early development.

Key features

DEX aggregation across 400+ liquidity sources
10+ EVM chains supported
Limit Order Protocol and Fusion intent-based execution
Token, portfolio, and spot price endpoints
REST API with WebSocket streams

Pros

Best-in-class swap routing on EVM chains
Strong gas-cost optimization across complex routes
Battle-tested across years of production volume

Cons

EVM-only. No Solana or non-EVM chain support
Wallet and market data are thinner than dedicated providers
Free tier rate limits tighten quickly at production scale

Best suited for: wallets, DeFi apps, trading bots, and any product that routes EVM swaps.

#3. Chainlink Data Streams and Price Feeds

Best for: verifiable price oracles on-chain.

Chainlink is the dominant oracle network in DeFi. Its products push verified market prices on-chain. Lending protocols, perpetuals, and stablecoins all depend on this layer.

Two products matter here. Price Feeds are push-based on-chain oracles. They update on price deviation thresholds. They power Aave, Compound, MakerDAO, and most major lending protocols.

Data Streams is the newer pull-based product. It delivers low-latency, off-chain price data through a REST API. Applications fetch a signed report. They post it on-chain with the same transaction. This suits perpetuals exchanges and high-frequency DeFi where push oracles update too slowly.

Coverage spans hundreds of trading pairs across crypto, FX, commodities, and equities. Reports are signed by a decentralized oracle network. Verification happens on-chain at low cost.

Key features

Push-based Price Feeds across 1,000+ trading pairs
Pull-based Data Streams with sub-second latency
Crypto, FX, commodities, and equities coverage
On-chain verifiability for every report
Wide adoption across DeFi protocols

Pros

Industry-standard oracle layer
Signed, verifiable data on-chain
Production-proven across tens of billions in secured TVL

Cons

Not a typical REST query API for off-chain analytics
Integration requires smart contract work
Data Streams pricing skews enterprise

Best suited for: lending protocols, perpetuals, stablecoins, and any DeFi product needing verifiable on-chain prices.

#4. Glassnode API

Best for: institutional on-chain analytics and macro research.

Glassnode API is the institutional benchmark for on-chain analytics. It surfaces derived metrics that raw RPC and basic data APIs do not.

Coverage spans 7,500+ on-chain metrics across Bitcoin, Ethereum, and 1,200+ assets. Two features set it apart for DeFi research. Entity-adjusted metrics cluster addresses controlled by the same actor. Exchanges, miners, and large holders become meaningful economic signals instead of raw address counts.

Point-in-Time data delivers immutable historical snapshots. Backtests and model validation run without look-ahead bias. Delivery options include REST, Snowflake, BigQuery, and CSV exports.

Glassnode also ships an MCP server for AI-assisted research workflows. The product line skews toward quant desks, asset managers, and macro research teams. It is not built for retail-facing DeFi dashboards.

Key features

7,500+ on-chain metrics across major assets
Entity-adjusted clustering for cleaner economic signals
Point-in-Time data for bias-free backtesting
REST, Snowflake, BigQuery, and CSV delivery
MCP server for AI research workflows

Pros

Best-in-class derived on-chain metrics
Strong historical depth for backtesting
Institutional delivery options for data teams

Cons

Pricing reflects an institutional buyer profile
Limited per-wallet or position-level features
Asset coverage narrower than multi-chain data providers

Best suited for: quant desks, asset managers, macro teams, and DeFi protocols needing audit-grade history.

#5. LayerZero API

Best for: cross-chain messaging and omnichain DeFi.

LayerZero is the dominant cross-chain messaging protocol in DeFi. It powers omnichain tokens, cross-chain governance, and bridge infrastructure.

Developers integrate through two contract standards. OApp lets a smart contract send arbitrary messages between chains. OFT defines a token that exists natively across multiple chains without wrapped representations.

Coverage spans 90+ chains including all major EVM networks, Solana, Aptos, and Sui. Stargate, a canonical LayerZero-based bridge, processes billions in monthly volume. Major DeFi protocols like PancakeSwap, Radiant, and Sushi rely on LayerZero for cross-chain logic.

This is not a REST API in the traditional sense. Integration happens through smart contracts and LayerZero SDK. But for cross-chain DeFi flows, it is the most-used messaging layer in production.

Key features

90+ chains supported, including EVM, Solana, Aptos, and Sui
OApp standard for arbitrary cross-chain messages
OFT standard for omnichain tokens
Production use by major DeFi protocols
Tested across billions in bridge volume

Pros

Widest chain coverage among messaging protocols
Native omnichain token support
Strong adoption across DeFi protocols

Cons

Smart contract integration, not REST endpoints
Learning curve for OApp and OFT patterns
Trust assumptions around oracle and relayer security

Best suited for: cross-chain DeFi, omnichain tokens, bridges, and products moving value across networks.

Comparing the Top 5 DeFi APIs and Tools

A quick side-by-side view of category, chain coverage, and where each tool fits best.

Provider	Category	Chain Coverage	Best For	MCP Support
CoinStats Wallet API	Wallet, DeFi positions, portfolio, security	120+	All-around DeFi data and per-wallet positions	Yes
1inch API	DEX aggregation	10+ EVM	Swap routing on EVM chains	No
Chainlink	Price oracles	Multi-chain	Verifiable prices on-chain	No
Glassnode	On-chain analytics	BTC, ETH, 1,200+ assets	Institutional research and backtesting	Yes
LayerZero	Cross-chain messaging	90+	Omnichain DeFi and bridges	No

Which DeFi API or Tool Should You Pick?

Pick CoinStats Wallet API if you need balances, DeFi positions, portfolio analytics, and Token Security across many chains in one integration. It is the most general-purpose option here.
Pick 1inch API if you route swaps on Ethereum or major EVM L2 networks.
Pick Chainlink if your DeFi product needs verifiable price oracles on-chain.
Pick Glassnode if institutional-grade on-chain analytics and bias-free historical data drive your workflow.
Pick LayerZero if your DeFi product moves value or messages across chains.

Final Thoughts

DeFi APIs and tools have specialized fast. The right choice depends on the data or execution layer your product needs. Not on which provider is biggest. Define that layer first. The selection follows from there.

One thing worth keeping in mind. The five tools above operate at the data, execution, oracle, analytics, and messaging layers. Some products go further. They read raw on-chain state, run their own indexers, or submit transactions directly. Those need an RPC infrastructure layer underneath. GetBlock fits there. Managed RPC nodes across 50+ chains. Data products like Token Insight API and Solana Swap Data Stream sit on top. Useful for teams consolidating the stack.

Start building with GetBlock →

FAQ

What is a DeFi API?

A DeFi API is an interface for decentralized finance data and actions. It lets developers query on-chain data without running their own infrastructure. The label covers four categories: protocol data, wallet positions, swap routing, and oracle infrastructure.

What is the best DeFi API in 2026?

For most DeFi use cases, CoinStats Wallet API is the strongest all-around option. It returns balances, DeFi positions, portfolio analytics, and Token Security in one integration. Coverage spans 10,000+ protocols and 120+ chains. Specialized providers fit narrower jobs. 1inch handles swaps. Chainlink delivers oracles. Glassnode focuses on institutional analytics. LayerZero powers cross-chain messaging.

Do I need an RPC node provider and a DeFi API?

If your product only consumes pre-aggregated DeFi data, a DeFi API may be enough. If it also reads contract state or submits transactions directly, add RPC infrastructure. GetBlock fits that layer.

What is the difference between token balances and token positions?

Token balances tell you what an address holds. Token positions tell you where those funds are deployed. Staking, lending, and liquidity pool stakes count as positions. Most APIs return balances. Far fewer return positions. CoinStats Wallet API is built around the position layer specifically.

Solana Q1 2026: Record Transactions, $2B in RWA, and the First AI Agent Economy. Here's What the Data Says for Builders.

GetBlock — Thu, 28 May 2026 20:25:21 +0000

Messari published its State of Solana Q1 2026 report on May 19th. The headline — record on-chain activity and continued capital efficiency, even as the broader crypto market entered a bear phase and SOL declined 33% quarter-over-quarter — tells you something important before you read a single statistic. When network usage grows while the token price falls, it means people are building and transacting for reasons that have nothing to do with speculation.

Here's a clear-eyed breakdown of the six metrics that matter most for builders.

1. Transaction Volume Hit an All-Time High

Average daily non-vote transactions reached a new all-time high of 112.6 million — up 50% quarter-over-quarter.

The "non-vote" distinction is important. Validator vote transactions currently consume roughly 75% of Solana's block space under normal conditions — the 112.6 million figure strips those out and counts only user-generated activity. That's the number that tells you about actual demand on the network.

50% quarter-over-quarter growth while the price is down 33% is the cleanest possible signal of product-market fit. Users aren't leaving when the token dumps. If anything, they're using the network more.

Infrastructure implication: 112.6 million daily transactions, each generating multiple RPC calls for submission, confirmation, and state queries, means the RPC layer is under sustained high load. Teams that sized their endpoint capacity for Q4 2025 traffic levels may already be experiencing degradation they haven't diagnosed as an infrastructure problem.

2. RWA on Solana Overtook Ethereum

RWA market cap on Solana grew 43% quarter-over-quarter to $2.01 billion, led by BUIDL's doubling to $525.4 million.

At one point, Solana reportedly surpassed Ethereum in total RWA holders.

Early users of the Solana Developer Platform include Mastercard, Worldpay, and Western Union, highlighting growing institutional adoption of Solana-based payment infrastructure.

This is the metric that changes the narrative most definitively. The "Solana is a memecoin chain" characterization doesn't survive contact with the data when Mastercard and Western Union are building on it.

The practical implication for builders: tokenized assets are not a future roadmap item on Solana. Tokenized Treasuries, private credit, and commodity-backed instruments are already live across Orca, Raydium, and Jupiter as primary liquidity venues. If your application needs to interact with any of these, the infrastructure and liquidity are there now.

3. Chain GDP Held Flat Despite the Bear Market

Chain GDP — total application revenue — held essentially flat at $342.2 million, while App RCR ticked up to 382%.

Chain GDP falling would mean the applications running on Solana generate less revenue when the token price drops. It didn't fall. That's resilience. The speculative premium in the token price can vanish and the underlying economic activity continues.

REV decreased only 1% quarter-over-quarter to $89.5 million, the second-highest of any network behind Hyperliquid.

Second in real economic value (REV) behind Hyperliquid — not behind Ethereum, which previously held this position. That's a structural shift in where fee-generating activity happens in the ecosystem.

4. Stablecoins: Third Largest Network, Shifting Composition

Stablecoin market cap held at $14.85 billion as composition shifted toward USDT, USD1, and PYUSD.

$14.85 billion in stablecoin float on Solana puts it third among all blockchains by this metric. The composition shift toward USDT, USD1, and PYUSD is significant: these are not DeFi-native stablecoins designed for yield farming. They're payment and settlement instruments. PYUSD is PayPal's product. USD1 is the Trump-backed stablecoin. USDT is the global dollar proxy for cross-border payments.

Ethereum's stablecoin base grew only 0.3% that same quarter. Solana outpacing Ethereum's growth rate here is a meaningful signal for a chain still establishing itself as a serious financial settlement layer.

For builders: if you're building anything involving stablecoin payments, the liquidity and the institutional partners are on Solana. The network that has Visa, Stripe, and PayPal running payment infrastructure is not the same network that existed two years ago.

5. RWA Lending Deposits Crossed $1.2B — Overtook Ethereum

RWA lending deposits jumped 115% quarter-over-quarter to $1.23 billion — overtaking Ethereum's roughly $1.13 billion for the first time.

This is the data point most coverage missed. Solana's RWA lending deposits — real assets used as collateral for on-chain loans — are now larger than Ethereum's. This is a use case that requires deep trust in the underlying network's security and reliability. The institutions putting $1.2 billion in collateralized lending on Solana are not experimenting. They're in production.

6. AI Agents: From Experimentation to Measurable Output

Q1 marked the first measurable economic output from AI agent activity on Solana, with the x402 payment standard expanding across QuickNode, Messari, Alchemy, and others, and the Solana Foundation-backed Agent Registry going live onchain.

PlayBabylon logged 490,000 trades from 1,171 autonomous AI agents within five days of its mainnet launch.

Solana is currently the only major blockchain compatible with both Stripe's Machine Payments Protocol (MPP) and the x402 payment standard.

That last fact is worth sitting with. The two competing open standards for AI agent payments — one from Stripe, one from Coinbase — are both supported on Solana. This is not an accident: Solana's sub-cent transaction fees and confirmed sub-second finality make it the natural home for machine-to-machine payments that need to happen at high frequency and low cost.

The Agent Registry going live onchain is the infrastructure piece most people underestimated. It means AI agents can have verifiable on-chain identities — they can prove who they are, what they're authorized to do, and build reputation over time. That's the missing layer between "AI agents can make payments" and "AI agents can participate in a structured economy."

What's Coming in Q2 and Beyond

Solana's structural setup heading into the rest of 2026 is anchored by Alpenglow, the network's most consequential consensus upgrade since mainnet, targeted for Agave 4.1 and projected to compress transaction finality from roughly 12.8 seconds to 150 milliseconds.

Alpenglow entered community validator testing on May 11th. If testing holds, mainnet activation targets Q3 2026.

When 150ms finality arrives, every metric in this report gets a multiplier:

Payment flows that needed batch settlement can move to real-time
AI agent transaction frequencies can increase 10-100x
RWA settlement windows compress from hours to seconds
DeFi liquidation mechanics become more precise

The Infrastructure Implication

All six of these metrics point in the same direction: Solana's transaction density is growing faster than most teams' infrastructure planning accounts for.

112.6 million daily non-vote transactions is not the ceiling — it's the Q1 floor heading into Alpenglow. When the upgrade ships and adoption responds, the RPC load increases proportionally.

The teams building on Solana in 2026 — particularly in payments, RWA, and agentic applications — need infrastructure that scales ahead of adoption, not after it. Shared public endpoints are rate-limited by the aggregate traffic of all users on that endpoint. At 112.6 million daily transactions and growing, shared endpoints hit their limits first.

Dedicated RPC infrastructure — where your rate limits are isolated to your own traffic — is the architecture that matches where Solana's network utilization is heading.

Running Web3 Weekly covers the infrastructure stories that matter for builders every Monday on YouTube and X.

GetBlock provides dedicated and shared RPC nodes for Solana and 130+ other blockchains — purpose-built for high-throughput production workloads. Explore Solana infrastructure →

Solana's Biggest Consensus Overhaul Is Live for Testing. Here's What Builders Need to do right now.

GetBlock — Thu, 21 May 2026 20:58:28 +0000

Alpenglow is not on mainnet yet. The community test cluster is where validator operators evaluate the new consensus design under real-world conditions before any broader rollout. The test milestone matters because it demonstrated that Alpenswitch — the actual transition from old to new consensus — works in a live multi-validator environment.

What Builders Should Do Right Now

1. Build against 150ms finality assumptions

If you're designing application architecture today that will ship in Q4 2026, model your UX and confirmation flows against 150ms rather than 12.8 seconds. Don't design for the current network if your launch is after mainnet activation.

2. Audit your RPC infrastructure for throughput

If Alpenglow drives meaningful adoption growth on Solana, your application's RPC request volume will scale with it. Shared public endpoints have rate limits that don't scale with your traffic. This is the time to evaluate whether your current RPC setup can handle 2-3x your current load.

Dedicated endpoints give you isolated capacity — your rate limits are determined by your usage alone, not shared with every other application on the same node. For Solana applications expecting growth alongside Alpenglow's mainnet launch, this is worth evaluating before the traffic arrives.

3. Check the Anza and Firedancer GitHub repos

Both teams have Alpenglow implementations available. If you're building validator tooling or infrastructure that touches Solana's consensus layer, the code is there to review now — not after mainnet.

Anza (Agave): https://github.com/anza-xyz/agave
Firedancer: https://github.com/firedancer-io/firedancer

4. Watch for Agave 4.1

This is the client release that ships Alpenglow to mainnet. When the release candidate drops, that's the signal that the mainnet activation timeline is concrete rather than projected.

The Bigger Picture

Solana's metrics have been soft for the past several months — TVL down 56% from its 2025 peak, monthly active users at a two-year low, fees declining. Alpenglow is the technical answer to a network that needs a structural argument for why builders and institutional capital should choose it over alternatives.

The argument is: a network where three-quarters of block space goes to internal coordination has a ceiling. Remove that ceiling and the throughput, reliability, and user experience ceiling rises with it. That's the bet Alpenglow is making — and with 98.27% validator approval and a successful test cluster activation, the bet is looking increasingly credible.

This breakdown is based on Running Web3 Weekly by GetBlock, covering the infrastructure stories that matter for builders every Monday on YouTube and X.

GetBlock provides dedicated and shared RPC nodes for Solana and 130+ other blockchains — including low-latency dedicated Solana stacks built for HFT, MEV, and high-throughput applications. Explore Solana infrastructure.

The Kelp DAO Hack Wasn't a Smart Contract Exploit. It Was an RPC Infrastructure Attack.

GetBlock — Tue, 28 Apr 2026 18:21:59 +0000

The Kelp DAO Hack Wasn't a Smart Contract Exploit. It Was an RPC Infrastructure Attack.

On April 18th, $292 million was drained from Kelp DAO's bridge in 46 minutes. Every post-mortem you've read focused on the 1-of-1 DVN configuration on LayerZero. That's the right conversation — but it's not where the attack actually executed.

The smart contract worked exactly as written. No reentrancy. No key compromise. The code wasn't the vulnerability. The infrastructure feeding data to the code was.

What Actually Happened at the Infrastructure Layer

Here's the attack sequence:

Lazarus Group (TraderTraitor unit) identified that Kelp DAO's bridge used a single LayerZero DVN verifier
They compromised two RPC nodes that the DVN used for transaction verification
They launched a DDoS against the remaining clean nodes — forcing the system to rely exclusively on the compromised ones
The single verifier received corrupted state data and confirmed a fraudulent cross-chain transaction as legitimate
116,500 rsETH (~$292M) was released from escrow to the attacker's address
The malicious binary self-destructed, wiping logs and traces
Kelp paused contracts 46 minutes later — blocking two additional attempts worth ~$100M

The result: Aave froze rsETH markets with $230M in potential bad debt at risk. rsETH, deployed across 20+ chains, was suddenly undercollateralized everywhere simultaneously.

Why This Is a Different Threat Model

Most security audits cover:

Reentrancy attacks
Flash loan manipulation
Oracle price manipulation
Access control vulnerabilities

Very few cover what happens when the RPC layer is compromised or degraded under load.

This is the gap the Kelp exploit exposed. Your smart contract can be perfectly written and still execute malicious transactions — if the data it's acting on comes from a compromised source.

The LayerZero vs Kelp Blame War

Both parties made public statements. Both are partially correct.

LayerZero's position: Kelp used a 1-of-1 DVN configuration against explicit warnings going back to July 2024. Their protocol wasn't broken — Kelp's configuration was.

Kelp's position: 1-of-1 DVN is the default configuration in LayerZero's quickstart guide. Approximately 40% of protocols on LayerZero use the same setup. The RPC nodes that were compromised were LayerZero's own infrastructure, not Kelp's.

Both statements can be true simultaneously. And that's exactly what makes this dangerous: a default configuration, trusted by most, with a single point of failure at the infrastructure layer.

The Arbitrum Governance Precedent

Four days after the exploit, Arbitrum Security Council executed an emergency vote: 9 of 12 multisig signers froze 30,766 ETH (~$71M) at the attacker's address.

This is important for two reasons.

First, it's a win for victims — roughly 25% of stolen funds are now locked and potentially recoverable.

Second, it's a proof point that "permissionless" is not an absolute state. A group of 12 people, through a governance mechanism, can freeze funds on a "decentralized" network. When you're designing systems, this is a centralized choke point that exists whether you acknowledge it or not.

Four Infrastructure-Level Lessons

1. Never use 1-of-1 verification on a bridge

// Dangerous - single point of failure
DVN config: {
  requiredDVNs: ["single-dvn-address"],
  optionalDVNs: [],
  optionalDVNThreshold: 0
}

// Correct - multiple independent verifiers required
DVN config: {
  requiredDVNs: ["dvn-address-1", "dvn-address-2"],
  optionalDVNs: ["dvn-address-3"],
  optionalDVNThreshold: 1
}

One verifier = one attack vector. Multi-DVN with independent providers is the minimum viable security posture for any bridge holding meaningful value.

2. Your RPC nodes are part of your threat model

The question isn't just "is my endpoint up?" — it's "is my endpoint returning accurate state?"

These are different questions with different answers. A compromised node can be fully available while returning fabricated data. Standard uptime monitoring won't catch this.

For cross-chain verification specifically:

Use multiple independent RPC sources from different providers
Implement response consistency checks across sources
Treat RPC endpoint selection as a security decision, not just an infrastructure decision

3. Default configurations can be dangerous

If you're copying a protocol's quickstart guide, check whether it's optimized for simplicity rather than security. These are different optimization targets.

Before deploying any bridge configuration to production:

Read the security documentation, not just the getting-started guide
Check what the recommended production configuration looks like vs the default
Understand what each parameter controls and what failure mode it protects against

4. Shared public nodes amplify attack surface

The Kelp exploit targeted specific RPC nodes. But the broader risk applies to any application using shared public endpoints for security-critical operations.

Shared nodes aggregate traffic from thousands of applications. A DDoS targeting one application on a shared endpoint degrades service for all of them. For most dApps, this means slower response times. For a bridge DVN, it can mean routing verification traffic to compromised fallback nodes.

What to Audit in Your Stack Today

If you're running a bridge or cross-chain application:

Checklist:
□ How many independent DVN verifiers are required for message validation?
□ Are those verifiers using independent RPC sources?
□ What happens to your verification logic if one RPC source goes down?
□ What happens if one RPC source returns stale or incorrect data?
□ Are any verification-critical RPC calls going through shared public endpoints?
□ Does your governance design have emergency intervention mechanisms?
   If yes — are you treating those as features or risks?

The Kelp post-mortem will focus on DVN configuration. That's correct. But the RPC layer is where this attack was actually executed — and most teams still aren't modeling that threat.

GetBlock provides dedicated and shared RPC nodes across 130+ blockchains including Ethereum, Arbitrum, and TON. If the Kelp story made you think about your own RPC setup — explore our infrastructure.

TON Just Got 10x Faster. Here's What That Means for Your RPC Stack

GetBlock — Wed, 22 Apr 2026 13:01:56 +0000

On April 10th, TON activated Catchain 2.0 on mainnet. Block time dropped from 2.5 seconds to 400 milliseconds. Finality dropped from 10 seconds to approximately one second. Pavel Durov called it step one of seven in a structured upgrade roadmap.

Most coverage focused on the speed numbers. This post focuses on something most developers haven't thought about yet: what a 10x performance upgrade does to your infrastructure stack.

What Actually Changed Under the Hood

Catchain 2.0 is a complete replacement of TON's consensus mechanism. It doesn't patch the old approach - it discards it entirely.

The practical result:

Metric	Before	After
Block time	~2.5s	400ms
Finality	~10s	~1s
Block rate	baseline	6x higher

The upgrade also introduced Streaming API v2 - a new layer that pushes state updates to applications the moment a block lands. Instead of polling the chain for new data, apps can subscribe to a stream and receive updates in real time.

Durov's recommendation for developers is direct: update your apps to use Streaming API v2. The chain is already real-time. The app layer needs to catch up.

The Infrastructure Problem Nobody Is Talking About

Here is the thing about blockchain performance upgrades that rarely makes the announcement post.

When a chain gets 6x more blocks per second, every application querying that chain gets 6x more traffic to handle. Every app, every bot, every indexer that hits a TON endpoint is now making roughly six times as many requests as it did last week.

That number gets bigger when you account for the user growth that faster, cheaper transactions are supposed to attract.

Public nodes were not designed for this pattern. The rate limits that were invisible before become hard ceilings. Free shared endpoints start dropping requests under load. Applications that worked reliably yesterday begin failing in ways that are difficult to debug - not because your code changed, but because the underlying traffic volume did.

This is the gap between a protocol upgrade and production reliability. And it is a gap that most developers discover at the worst possible time: after they have already shipped.

What This Means If You Are Building on TON Right Now

If you are using public or free shared RPC endpoints:

Test your request volume against the new block rate. If your application queries per block or subscribes to events, your baseline traffic just increased 6x. Check whether your current endpoint handles that load before your users do.

If you are polling for state updates:

Switch to Streaming API v2. Polling was already inefficient at 2.5 second blocks. At 400ms it creates unnecessary load on both your infrastructure and the node you are querying. Streaming is the correct pattern for real-time applications on the post-Catchain network.

If you are running a payment application or Mini App:

Subsecond finality changes what you can promise users. A payment that previously took 5-10 seconds to confirm now confirms in under a second. That is a meaningfully different UX. But it only holds if your infrastructure can keep up with confirmation requests at the new throughput.

If you are building high-frequency DeFi:

Arbitrage bots, liquidation bots, and on-chain order book logic that was not viable at 2.5 second block times now becomes worth reconsidering. The infrastructure requirement for these use cases is even more demanding - you need low-latency dedicated access, not shared endpoints.

The TAC Angle

One upgrade-adjacent development worth noting: TAC, the EVM-compatible execution layer on top of TON, benefits from the same underlying performance improvements. If you are building Solidity-based applications that need to interact with the TON ecosystem - including Telegram Mini Apps - TAC gives you EVM tooling with TON-native distribution. That combination becomes more compelling as the base layer gets faster.

Evaluating Your Stack

Before Catchain 2.0, many TON applications could get away with shared public endpoints. The traffic volume was manageable and the performance requirements were forgiving.

That calculus has changed. The practical checklist for any team with a TON application in production:

Measure your current RPC request rate per minute
Multiply by 6 to estimate the new baseline under Catchain 2.0
Check whether your current endpoint's rate limits accommodate that number
If not - or if you have no visibility into those limits - switch to a dedicated endpoint before the traffic increase catches you

At GetBlock, we provide dedicated and shared TON RPC nodes built for this kind of load. Dedicated nodes give you guaranteed throughput and latency isolation - no competing with other applications for capacity on a shared endpoint. We also support TAC nodes for teams building on the EVM layer.

If you want to test your current setup, the simplest approach is to run a load simulation at 6x your current request volume and watch for rate limit errors or degraded response times. Better to discover the ceiling in a test than in production.

The Bigger Picture

Catchain 2.0 is step one of seven in the MTONGA roadmap. Step two - a 6x reduction in transaction fees - has been announced but not yet scheduled. If that lands as described, TON will have subsecond finality and fees around $0.0005 per transaction.

That combination - fast, cheap, with a billion-user distribution channel through Telegram - makes TON infrastructure worth taking seriously. The builders who will benefit most are the ones who have their stack ready when the user growth arrives, not the ones scrambling to upgrade after it does.

The chain is already real-time. The question is whether your infrastructure stack is.

Running Web3 is a show by GetBlock covering the technology that actually powers the Web3 industry. Episode 8 covers the full MTONGA roadmap and what Catchain 2.0 means for builders.

GetBlock provides RPC node access across 130+ blockchains including TON and TAC. Explore TON nodes or TAC nodes.

Custom Base op-Erigon Node for AMM Analytics. When Standard Infrastructure Solutions are Not Enough

GetBlock — Thu, 11 Dec 2025 11:54:51 +0000

Most blockchain infrastructure providers offer standard configurations. When a DeFi analytics platform, Revert Finance, needed overlay RPC methods on Base, the capability didn't exist in any production node. They needed a partner who could build custom solutions, not just provision servers.

GetBlock deployed a working solution in under a week.

Why standard RPC infrastructure couldn't work

Revert Finance provides advanced analytics and automation tools for liquidity providers in DeFi, helping them track and optimize their positions across major AMMs, including Uniswap, Pancakeswap, and Sushiswap. By offering real-time insights into yield, fees, rewards, and risks, Revert enables LPs to maximize returns and efficiently manage their DeFi portfolios.

When Revert began integrating Aerodrome, a leading AMM on Base, they hit an unexpected obstacle. They needed additional data points during reward claims and liquidity operations – events that Aerodrome's developers never designed into the original contracts. Standard RPC methods couldn't solve this.

Most Web3 infrastructure needs can be met with reliable RPC services. GetBlock provides full and archive node API access across 100+ blockchains including Base. Browse our supported nodes.

The overlay RPC workaround

Revert's engineering team devised a workaround: use Erigon's overlay RPC namespace to replay historical Aerodrome transactions with modified bytecode that adds the missing event emissions.

The workflow:

Take Aerodrome's contract source code (e.g., CLGauge at 0xF33a96b5932D9E9B9A0eDA447AbD8C9d48d2e0c8)
Add custom event emissions at critical points in the code
Compile the modified contract to get instrumented bytecode
Use overlay_callConstructor to deploy this modified version into a local state overlay
Use overlay_getLogs to replay historical Aerodrome transactions against the instrumented contract and capture the custom events

This approach required an archive Base node with a full historical state running Erigon's op-stack fork with overlays enabled. That's what GetBlock's engineering team stepped in to build.

Production reality check

This combination, the Erigon client with the overlay_* functional on Base, didn't exist in any production infrastructure offering at the time.

While overlay RPC was proven for Ethereum, extending this functionality to op-stack chains was still experimental. The op-erigon community fork maintained by Sunnyside Labs had the code theoretically in place.

When testing op-erigon's overlay methods for production use, we discovered edge cases that needed resolution:

nil pointer crashes
null return values
op-stack execution context gaps

GetBlock collaborated with op-erigon maintainers who addressed the L1 and operator cost function initialization in pull request #259.

Building on that foundation, GetBlock implemented targeted modifications to achieve production stability of the node.

Running into infrastructure limitations with your analytics service or dApp? GetBlock's team can evaluate your requirements and design a solution. Get in touch to explore what's possible for your use case.

Stabilizing overlay RPC execution on GetBlock’s Base op-erigon node

When production testing revealed more complex overlay execution issues that upstream fixes couldn't fully resolve, GetBlock's engineers implemented custom patches in under a week.
The fixes included:

1. Execution context injection

We ensured overlay replays carry full op-stack semantics:

blockCtx := evmtypes.BlockContext{
    BlobBaseFee: blobBaseFee,
    L1CostFunc: opstack.NewL1CostFunc(chainConfig, stateDB),
    OperatorCostFunc: opstack.NewOperatorCostFunc(chainConfig, stateDB),
}

2. CREATE transaction detection

Added isCreateTx flag to properly handle contract deployment overlays:
go

isCreateTx := creationTx.GetTo() == nil && contractAddr == address

3. Deployed bytecode extraction

After CREATE execution, we explicitly read deployed code from intra-block state:

if isCreateTx {
    deployed := evm.IntraBlockState().GetCode(contractAddr)
    if len(deployed) > 0 {
        result.Code = hexutil.Encode(deployed)
        return result, nil
    }
}

4. Tracer integration

Enhanced the tracer to write injected code to state and propagate errors to the RPC layer:

tracer.evm.IntraBlockState().SetCode(tracer.contractAddr, tracer.injectedCode)
tracer.resultCode = tracer.injectedCode

The result

GetBlock's work with Revert demonstrates what's possible when you combine:

Deep client-level expertise
Close collaboration with the customer and developer community
Engineering capability to patch and deploy specialized builds

The result: GetBlock deployed a hardened archive Base node with patched op-erigon that properly implements overlay RPC. Revert launched their Aerodrome analytics on schedule.

What we learned building this

If you're working with overlay RPC or custom Erigon deployments, note:

Overlay requires explicit state override parameter Even for empty overrides, pass {} as the second param to avoid nil dereference:

curl -X POST https://go.getblock.io/<token> \
-H "Content-Type: application/json" \
-d '{
  "jsonrpc":"2.0",
  "method":"overlay_getLogs",
  "params":[
    {"fromBlock":"latest","toBlock":"latest"},
    {}
  ]
}'

Op-stack execution context is non-negotiable: L1 cost functions and operator fees must be initialized or Cancún-era blocks will fail.
CREATE transactions need special handling: Standard execution paths don't automatically expose deployed bytecode in overlay contexts, you must read from intra-block state.

Wrapping up: Infrastructure is an engineering lever

Innovation in blockchain isn’t just about creating smarter contracts; it’s about the infrastructure that makes those possibilities real. Advanced products like Revert’s DeFi analytics don’t fit neatly into standard setups.

At GetBlock, we treat infrastructure as a technical enabler, not a constraint. When the standard toolset runs out, our engineering focus takes over.

For Revert Finance, that meant bringing overlay RPC from theory to production on Base. For your product, it might mean architecting the missing piece between your vision and your data layer.

Need custom blockchain infrastructure?

GetBlock provides high-performance blockchain infrastructure across 100+ blockchains — from RPC node access and dedicated setups to fully customized engineering support for teams building at the frontier.

If your project requires specialized node configurations that standard providers can’t deliver, let’s talk.

Most infrastructure providers say 'that's impossible.' We say, 'give us a week.’

BlastAPI Shuts Down: Migrating to GetBlock in Three Lines of Code for Web3 devs

GetBlock — Fri, 24 Oct 2025 11:07:04 +0000

With BlastAPI set to discontinue operations by the end of the month, RPC node provider GetBlock is extending a helping hand to affected Web3 developers.

Through a dedicated migration campaign, teams moving from BlastAPI to GetBlock can claim up to 50% off shared RPC node subscriptions on the Pro and Enterprise plans (find tech manual and migration guide below!)

The offer, valid until November 20, 2025, aims to ensure continuity for developers while unlocking measurable performance gains and greater multi-chain flexibility.

TL;DR

BlastAPI is shutting down on October 31, 2025. GetBlock steps in with a limited‑time migration program offering up to  50% off shared RPC node subscriptions.
New users can use promo code MIGRATE50 to receive 50% off the Enterprise plan or MIGRATE40 for 40% off the Pro plan, both applied with six-month commitments.
Claim the offer by November 20, 2025 by submitting the promo codes through the contact form on GetBlock's website.
To migrating users, GetBlock delivers a true upgrade with broader blockchain coverage, stronger architectural performance, and top-tier customer  support unmatched in its segment.

Activate your discount through our Contact form and save at least $2,400 on an optimal setup.

BlastAPI shuts down, GetBlock launches migration campaign with 50% off

BlastAPI’s sudden closure has left many Web3 teams in search of reliable alternatives. GetBlock, with over 100 Layer-1 and Layer-2 blockchains supported including Ethereum, Solana, Tron, and Bitcoin, presents one of the most comprehensive infrastructures on the market.

Migrating projects gain access to key performance enhancements such as broader multi-chain support, archive data availability, secure routing through MEV‑protected endpoints, and globally distributed endpoints across the US, Europe, and Asia.

Transitioning is straightforward: developers submit a contact request on the GetBlock website with the appropriate promo code – MIGRATE50 or MIGRATE40. GetBlock’s team oversees setup from integration to final deployment — minimizing downtime and configuration overhead.

GetBlock vs BlastAPI: Bigger blockchains lineup, faster endpoints, best-in-class support

While BlastAPI maintained a respectable range of networks and developer features, GetBlock’s ecosystem now represents one of the most extensive and high‑performance infrastructures in the RPC market.

Its core advantages include a 60‑plus blockchain edge, faster global response times verified by independent testing, and customer support excellence for all users. The platform’s SOC 2 certification, due by Q4 2025, underscores its commitment to security and enterprise-grade reliability.

Bonus 1: Seamless migration in three lines of code

While for some use-cases, pasting a new API endpoint URL is actually a drop-in replacement, you can’t be too safe.

Migration is as simple as changing your RPC URL. Here's how:

// Blast API (OLD)
const OLD_RPC = "https://eth-mainnet.blastapi.io/YOUR_PROJECT_ID";

// GetBlock API (NEW) - Direct replacement
const NEW_RPC = "https://go.getblock.us/<ACCESS_TOKEN>";

// You're good to go! Your dApp is now using the new endpoint
const provider = new ethers.JsonRpcProvider(NEW_RPC);

Before switching to a new endpoint, test the connection:

# Sending a request to an Ethereum endpoint
curl -X POST "https://go.getblock.us/<YOUR_ACCESS_TOKEN>"\
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber",
  "params":[],"id":"getblock"}'

# Expected response
{"jsonrpc":"2.0","id":"getblock","result":"0x123456789"}

Bonus 2: Should I choose a Pro or Enterprise plan?

Here’s what you need to know about the plans included in the promo campaign.

GetBlock CEO Vasily Rudomanov invites all Web3 teams to explore the platform’s infrastructure stack:

Following the BlastAPI shutdown, GetBlock is prepared to support affected teams with a seamless migration to new RPC node infrastructure.
GetBlock is offering special promotional pricing on its Pro and Enterprise package suites to make the migration immediate and painless.
The whole process is straightforward: contact the team, apply a promo code - MIGRATE50 for Enterprise and MIGRATE40 for Pro package - and GetBlock handles integration. Customers can expect full infrastructure support without extended setup timelines or unexpected costs. For Web3 builders seeking reliable, scalable RPC nodes, this represents a practical opportunity to upgrade their infrastructure layer in 2025.

For affected BlastAPI teams, it’s an opportunity to secure a stable infrastructure foundation and continue building without interruption.

Wrapping up

Migrating isn’t just about replacing your RPC provider; it’s about futureproofing your infrastructure. GetBlock’s consistent uptime, transparent pricing, and ongoing chain integrations make it a dependable option for teams building long‑term in Web3.

This migration offer is the simplest way to make the switch and ensure transition happens quickly, painlessly, and results in an infrastructure upgrade — not just a replacement

To join the migration program or get assistance, visit getblock.io

Avalanche Node Peculiarities and Benefits

GetBlock — Mon, 28 Jul 2025 12:58:16 +0000

Avalanche is a layer-1 blockchain compatible with EVM. It has robust development capabilities, with its unique three-chain architecture and the ability to launch customized L1s using the network. Here, let’s focus on Avalanche nodes and explore how they work to help Web3 developers deploy their projects, and how services like GetBlock can simplify the process.

What is Avalanche node

Avalanche nodes play a crucial role in maintaining the network’s integrity, processing transactions, and enabling Web3 development. Before exploring how to run a node, it’s essential to understand Avalanche’s structure, consensus, and node types.

Avalanche chain structure

Avalanche operates three separate but interconnected chains, each optimized for a specific set of tasks:

X-chain: Built on the Avalanche Virtual Machine, it is used for creating and transferring digital assets, including the native AVAX token.
P-chain: Responsible for staking operations, validator coordination, and governance processes.
C-chain: Fully compatible with Ethereum via the Coreth Virtual Machine, it focuses on deploying and executing smart contracts.

This architecture separates core functionalities for greater scalability, performance, and customization potential.

Avalanche consensus

Avalanche utilizes a Delegated Proof-of-Stake (DPoS) consensus model that relies on validator and delegate participation to reach network consensus. One can see how the consensus works on the scheme below

Let’s explore both roles.

Validators:

Must stake a minimum of 2,000 AVAX (approximately $50,000).
Directly validate transactions and contribute to consensus.
Participate in governance decisions.
Earn staking rewards.

Delegates:

Can stake as little as 25 AVAX (about $625).
Vote for validators instead of validating directly.
Do not need to run their own node (but recommended).
Earn rewards alongside chosen validators (typically 8–10% APY).

This system allows flexible participation in securing the network, even with limited resources.

Avalanche node types

Avalanche nodes come in several types based on their functionalities, each serving different roles in the ecosystem. Let’s explore them.

Full node:

Stores the full blockchain state and can be pruned to reduce disk size.
Synchronizes with other nodes to maintain network data.

Validator node:

A full node with added consensus participation.
Validates transactions by staking AVAX and participates in governance.

RPC node:

A full node that provides access to the Avalanche API.
Supports Web3 apps by executing blockchain queries and smart contract calls.

Generally, AVAX full node is the basic node type, which can then be customized into an RPC or validator node. Their use cases differ based on the task.

Web3 development:

Requires an RPC node with an active API endpoint.
Essential for dApps, NFTs, blockchain games, and DeFi protocols.

Transaction validation:

Performed by validator nodes with at least 2,000 staked AVAX.
Ensures secure execution and recording of transactions.

How to run Avalanche node

Running an Avalanche node requires both adequate hardware and a Unix-based software environment. Let’s go through the setup process.

Hardware requirements

To deploy a fully functioning AVAX node, your machine should meet these minimum specifications:

Disk: 1 TB SSD
RAM: 16 GB
CPU: 8-core processor or higher
Internet: Minimum 5 Mbps connection

Now, let’s focus on software.

Software requirements

AVAX nodes require specific software components and operating systems:

Operating system: Unix-based (Ubuntu recommended); Windows is not supported
Avalanche client: AvalancheGo
Dependencies: go (Golang) and gcc (GNU compilers)
Additional tools: Prometheus for monitoring, Grafana for data visualization, other tools are optional

After everything is set up, we’re ready to install.

Installation and maintenance

Setting up an Avalanche node involves several steps.

The process includes:
Install go and gcc on your Unix-based system.
Download AvalancheGo from source, Docker, or use the pre-built binary.
Run AvalancheGo and wait for full node synchronization (bootstrapping).
Configure the node via flags, including C-, X-, and P-chain settings.
Optionally, enable pruning to save disk space.

Ongoing node maintenance includes software updates and performance monitoring using tools like Prometheus and Grafana. One can see the example of a performance monitoring dashboard below.

RPC and validator nodes

To configure an RPC node, you must expose the correct API endpoint and ensure stable uptime. This allows smart contract interactions and dApp development directly through your node, making it suitable for developers and Web3 projects.

Validator nodes, on the other hand, require staking 2,000 AVAX and adjusting the AvalancheGo configuration for consensus participation. These nodes secure the network and participate in block validation, making them vital for Avalanche’s DPoS model.

Benefits of running Avalanche node

Operating an Avalanche node brings various advantages to individual participants, developers, and enterprises.

Securing the network

Each full AVAX node helps maintain a decentralized and tamper-proof blockchain by validating state changes and rejecting unauthorized modifications. All full node operators play a key role in preserving the network’s security and resilience.

Faster transactions

Running your own node eliminates reliance on third-party providers, leading to faster, more reliable transaction execution. This independence can be critical for applications that require high throughput and low latency.

Validation and delegation

Becoming a validator allows users to stake AVAX, contribute to transaction validation, and participate in governance. Delegates, while staking less, still earn passive rewards between 8–10% APY by supporting trusted validators.

Web3 development

RPC nodes enable the creation of decentralized apps by providing a programmable API interface with the Avalanche blockchain. Developers can run custom smart contracts, interact with tokens, and deploy entire platforms using their own infrastructure.

Conclusion: Using a node provider

Running your own Avalanche node grants full control but requires hardware, setup time, and ongoing maintenance. For commercial Web3 projects, using a node provider like GetBlock can be more cost-effective and time-saving.

Here are the benefits of using a node provider:

Fast deployment — ready-to-use API access within minutes.
Lower cost — starts at $39/month (for GetBlock), no hardware needed.
No maintenance — node is managed by dedicated specialists.
Custom options — choose between shared or dedicated nodes.
Developer support — promotional help, partner benefits, and Dapp Hub access.

Choosing GetBlock lets startups and enterprises scale their Avalanche-based solutions quickly and securely, while focusing on what matters most: building their Web3 products.