If you've spent any time building in web3, you know "pick an RPC provider" is one of those questions that gets a lot of marketing answers and very few honest ones. Every provider claims to be fast, reliable, and competitively priced. The reality is messier: they're optimised for different workloads, the metrics they advertise don't always match production behaviour, and the right choice depends heavily on what you're building.
This piece is an honest take on web3 RPC providers — what they do, how they differ, and the framework for picking one without falling for the marketing.
What a Web3 RPC Provider Actually Provides
At the basic level: an HTTPS endpoint that speaks the chain's RPC protocol. Your client makes calls; the provider returns answers or forwards transactions.
What good providers actually do beyond that:
- Run their own node fleets in geographically distributed locations
- Filter abusive traffic so noisy customers don't degrade the rest
- Provide observability — query logs, latency metrics, status pages
- Provide SWQoS support (Solana-specific) or bundle relays (Ethereum)
- Support failover to handle node failures without dropping customer traffic
- Offer tiered pricing that matches different traffic profiles
The differences between providers come down to how well each of these is done. Two providers handing you HTTPS endpoints can have wildly different production behaviour.
How Web3 RPCs Differ Across Chains
The provider landscape varies by chain because the underlying network architectures differ:
Ethereum and EVM chains. Mature ecosystem. The established vendors there have been around for years. The differences are mostly in features (parsed APIs, NFT metadata, indexing) and pricing.
Solana. Faster network, no public mempool, validator-side dynamics, MEV in different shapes. Providers need different optimisations. The market splits into general-purpose read vendors, send-focused platforms like BoltTx, and vendors sitting closer to validator infrastructure.
Layer 2s (Arbitrum, Optimism, Base). Often inherit Ethereum tooling but have specific quirks. Providers usually support these as additional offerings on top of mainnet.
Multi-chain providers. Some vendors support many chains at once. The breadth comes at the cost of depth — they are rarely best-in-class on any specific chain.
For your specific use case, the question is: do you need cross-chain breadth or single-chain depth? Most teams optimising for one chain pick a specialist; teams handling many chains pick a generalist.
Reading Marketing Pages Critically
Marketing claims you should evaluate sceptically:
"Sub-second latency." Average? P95? P99? In what conditions? "Sub-second average" can hide P95 of 5 seconds during congestion.
"99.99% uptime." Reasonable claim but check the SLA — what's the uptime measurement methodology? Does it count partial outages?
"Auto-scaling." Many providers say this; few actually have customer-isolated capacity that scales automatically without manual intervention.
"Best-in-class infrastructure." Meaningless without specifics. What infrastructure?
"Used by [list of big companies]." Big companies use lots of providers; doesn't tell you much about whether it's right for you.
What to ask for instead:
- Documented P95 latency under stated load conditions
- Specific SLA terms (uptime measured how, credits for breach)
- Per-customer isolation model
- Methodology for any benchmark numbers
- Pricing structure that aligns with your traffic profile
Pricing Models
Different providers price differently:
Per-credit / per-request. You pay for each RPC call, often metered. Predictable for read-heavy traffic; expensive for high-frequency sends.
Per-month tiers. Flat fee for X requests/sec. Predictable but you may overpay if your usage is bursty.
Tip-based / per-landed-transaction. You only pay when transactions actually land. Aligns with successful outcomes; great for write-heavy workloads.
Reserved capacity. Pay for dedicated capacity; charges constant regardless of usage.
For trading bots and other write-heavy workloads, tip-based pricing is usually the most cost-effective because failed sends don't cost anything. For read-heavy applications, per-credit or tiered models work fine.
Feature Comparison: What Matters
The features that actually matter for production:
RPC method support. All providers should support standard methods. Look for less-common methods you need (account subscriptions, log filters, etc.) — not all providers support everything.
WebSocket subscriptions. Many providers offer these but quality varies. Some have dropped-connection issues that are painful in production.
Streaming (WebSocket-based or purpose-built protocols). For high-volume reactive applications. Not every provider offers it; the ones that do vary in quality.
Parsed transaction history. Solana's raw JSON is ugly. Some vendors do the parsing for you. Saves real work.
NFT and token metadata APIs. Side features for relevant applications. Worth checking if your app needs them.
Anti-MEV / private routing. Solana-specific. Critical for any directional trading workload. Not every provider supports it natively.
Telemetry and observability. Per-signature delivery records, latency dashboards, query logs. Quality varies enormously.
Trade-offs You Have to Make
The honest framing of the trade-off space:
Specialisation vs breadth. A provider focused on one workload (e.g., Solana transaction sending) usually does that workload better than a multi-chain generalist. But you may need multiple providers.
Free tier vs production tier. Free tiers are useful for evaluation but aren't always representative of paid tier behaviour. Test with workload that approximates production.
Cheaper vs better. The cheapest provider that loses you trades is more expensive than the more expensive one that doesn't.
Multi-region vs single endpoint. Multi-region with manual selection: you pick the right one for your client. Single endpoint with smart routing: provider picks for you. Each has trade-offs.
Production Pattern: Multiple Providers
Most production deployments use more than one provider:
Primary read RPC. Your main read traffic.
Backup read RPC. For failover.
Write RPC. Different optimisation; often a different provider.
Event streaming. May be a third provider depending on the chain and use case.
For Solana specifically, a common pattern: a general-purpose vendor for reads and parsed APIs, BoltTx for writes, and either one for streaming.
What to Look at When Comparing
A practical comparison framework:
- Test the free tier with your real workload for a week. Don't trust marketing; measure.
- Compare P95 latency under your load profile. Average is meaningless for production.
- Compare effective fills (for trading workloads) and not just latency. Sandwich exposure compounds.
- Ask about per-customer isolation. "Are my requests isolated from other customers'?"
- Read the SLA terms carefully. What's actually guaranteed and what's marketing.
- Check support responsiveness. Open a real ticket during evaluation.
- Review the pricing math at your projected scale. Some providers are great at $100/mo and impossible at $10k/mo.
What to Do This Week
If you're picking a provider:
- Pick by workload, not by name recognition. Big-brand providers aren't always best for specific use cases.
- Test with real traffic before committing. Free tiers exist for this reason.
- Use separate read and write providers if your workload has both.
- Plan for failover from day one. Single provider single point of failure.
- Set up monitoring early. You'll need it to debug provider issues when they happen.
- Don't lock into long contracts. Flexibility matters; needs change.
Try BoltTx for Solana Write Traffic
If you're on Solana and your workload is transaction-sending heavy:
import { Connection } from "@solana/web3.js";
const connection = new Connection(
"https://bolttx.io/?api-key=YOUR_API_KEY",
"processed"
);
Single global endpoint. Native Anti-MEV. Sub-second confirmation. Tip-based pricing — pay only on landed transactions.
Free tier signup. Pair with whatever read provider fits your read traffic. Run real workload for a week and compare.
FAQ
Should I use a multi-chain provider or a chain-specific one? For one chain, specialist usually wins. For many chains, a multi-chain provider may be more practical even if not best-in-class on each.
Can I switch providers easily? For most code, yes — environment variables, swap URL, done. The work is in adjusting to provider-specific features (parsed APIs, etc.) if you used them.
Is it worth paying for premium providers? Depends on workload. For production trading, the right RPC pays for itself in better fills. For development, free tiers are fine.
Do I need both Ethereum and Solana RPC providers? If you're building cross-chain, yes. If you're single-chain, just one.
What's the difference between an RPC and a gateway? Often used interchangeably. Some "gateways" add features beyond raw RPC (caching, analytics, multi-chain abstraction). Functional distinction is fuzzy.