Introduction
Web3 RPC & API infrastructure companies serve as the backbone of the Dapp industry, servicing data and write access to blockchains to the large majority of the industry. However, with the evolution and maturation of the industry, the business model supporting this backbone faces a challenge. Termed by DIN as the “RPC trilemma,” web3 RPC & API providers are confronted with the difficulty to simultaneously achieve three competing priorities:
-
High Reliability: Consistent uptime, low latency, and quality of service
-
Breadth of Services: Support for the multitude of idiosyncratic Layer-1 and Layer-2 networks and the many features and diverse APIs required
-
Economic Sustainability: The ability to maintain a margin positive offering in the face of diverse competition
In the post-2022 landscape, this trilemma has become more pronounced. The Web3 industry has matured, with meaningful financial activity on-chain that requires 100% uptime. DeFi and AI agents demand faster and more performant blockchain access to execute advanced strategies. As Dapps go multi-chain, the elevated performance requirement is expanding across a swiftly growing number of new blockchains. As these blockchains become more complex with higher throughput and idiosyncratic features, infrastructure costs spiral with limited economies of scale to be realized.
This blog post examines how these priorities are in tension and the practical challenges faced by API providers. Finally, it examines how Infura, the industry's leading RPC company, is solving this challenge by leveraging the superpowers of web3, permissionless innovation and community empowerment, via its evolution into DIN.
The RPC Trilemma: Reliability vs. Coverage vs. Cost
The RPC trilemma can be summarized as the need for Remote Procedure Call (RPC) services to be reliable, performant, and cost-efficient – often a “pick two of three” situation.
Pick any two, traditional providers can’t deliver all three:
| Picked dimensions | Hidden downside
| Reliability + Coverage | Run-rate costs explode, forcing price hikes.
| Coverage + Cost | One-off nodes per chain lead to throttling and outages.
| Cost + Reliability | Narrow chain menu; developers go elsewhere.
In practice, an ideal RPC provider would have maximal uptime and responsiveness, support all the networks and features a developer needs, and remain affordable and easy to use. In reality, maximizing one dimension often undermines another. For example:
-
High Reliability & Performance: This requires robust infrastructure with globally distributed nodes, rapid scalability, failover mechanisms, and heavy monitoring, which can drive up costs.
-
Breadth of Services (Multi-Chain Support)**: After L2s became popular, the number of prominent blockchains exploded. Dapps have evolved to need access to these networks to create a seamless cross-chain UX for users. Supporting many L1s/L2s means running more nodes and adapting to different protocols, from Ethereum’s account model to UTXO or novel consensus designs. This divergence adds to R&D costs and complicates maintenance.
-
Cost Efficiency: Developers are highly sensitive to infrastructure costs and a competitive market exists among the large number of companies that can offer node services. In the effort to be competitive on cost, RPC companies have to consider focusing on an area of specialization, forgo investments in performance improvement or cut other operational overhead costs.
Rising Demands: Dapps and AI Agents Need High Reliability & Performance
Modern Dapps (DeFi protocols, NFT marketplaces, etc) and emerging AI agents increasingly require fast and reliable on-chain data in real time. Automated trading bots, on-chain games, and AI-driven DeFi managers can make split-second decisions and thus depend on low-latency, high-throughput RPC access.
For example, AI agents in DeFi rely on “real-time, high fidelity data” with updates in milliseconds to act on fast-moving markets. Any downtime or lag in accessing blockchain state can lead to lost opportunities or even financial loss.
Uptime is critical. Speed is a must.
In response, Dapp developers increasingly build in their own redundancy. It’s now a best practice to use multiple RPC endpoints with automatic failover and parallel processing. For example, OpenZeppelin’s tooling recommends configuring at least three endpoints and rotating to ensure high availability. If one returns errors (e.g. HTTP 429 rate limits), the client library can seamlessly switch to another. This multi-endpoint strategy significantly improves resiliency, as no single point of failure will take the Dapp offline.
However, maintaining such redundancy comes with cost and complexity. A project may need subscriptions to Infura, Alchemy, QuickNode, etc., concurrently, paying each for sufficient capacity. Dapps must also implement logic to route requests and handle inconsistent data between providers. Most Interesting; however, these clunky solutions organically, unintentionally, aim to solve the problem inherent to centralization. The opportunity exists, then, for a more elegant solution that leverages crypto-native solutions to deliver the never down, decentralized promise of blockchains.
OmniChain Complexity and Fragmented Services
Since 2022, the Ethereum ecosystem has become unequivocally multi-chain. A quick look at Dapp Radar and you will find 100s of L1/L2s and user activity and liquidity spread across Ethereum mainnet and an array of L2 networks (Optimism, Arbitrum, Polygon’s chains, zk-rollups), as well as alternative L1s (Avalanche, BNB Chain, Fantom, etc.).
Many Dapps have followed suit, deploying their contracts on several chains to reach a broader user base. This brings clear benefits like access to more users and lower fees on L2s, but it magnifies infrastructure challenges.
It becomes difficult for a single RPC provider to scale their chain coverage at the accelerating growth of the L1/L2 ecosystem. RPC companies take on financial risk when launching a new chain and trade-off other roadmap potential. For modern, high-throughput blockchain designs, the time teams need to devote to truly understand the intricacies of running and optimizing nodes adds to the R&D cost and time. In an informal DIN survey of 15 of the leading RPC providers, two-thirds indicated they prefer to not split focus on greater than 10-15 blockchains at one time.
When a Dapps primary provider doesn’t have sufficient coverage for access to its necessary blockchains, they rely on multiple third-party RPC providers to get the coverage required; often looking for specialists in a certain ecosystem (e.g. EVM, SVM, Cosmos). This means managing multiple provider accounts, introducing integration friction. Each provider may have different pricing, rate limits, dashboards, and sometimes require using different authentication tokens or even paying in different currencies.
Yes, some providers do advertise coverage for 60+ or even 100+ chains. However, the dirty-little-secret of the RPC industry is that in order to support that breadth of networks, teams either have insufficient infrastructure running, maybe one single node, that comes with a performance cost. Or, more common, the RPC provider white-labels and up-charges another RPC provider’s service to give its customer access.
Our industry deserves better.
Costs and Friction in a Multi-Provider World
The third side of the trilemma, cost control, has grown in importance as the market has evolved since 2021. The exuberance of the 2021 boom faded and projects became more cost-conscious. Dapps were competing more fervently over user acquisition and shifted-focus toward value-added layers; while looking for ways to cut at the non-differentiating API/RPC plumbing layers.
The number and diversity of chains exploded and Dapps sought early entry in search of ecosystem growth. Not too long ago, it was headline news when a Dapp added support for a new chain; now every Dapp is beginning to launch its own chain, and an omnichain, frictionless Dapp experience is the new expectation. With the growth in new L1s and L2s, these chains started to get more complex and idiosyncratic in search of differentiation from one another. This resulted in running node infrastructure getting more complex and expensive to run.
For a web3 infrastructure team, as you add new chains you split your team’s attention and resources. Each chain has its own requirements, nuances, and infrastructure. Even among opStack chains, which are fairly uniform, you have instances like Hemi and BOB which run a parallel BTC chain and Unichain which has adopted a unique TEE scheme. These differences result in real challenges for professional infrastructure companies; particularly at the rate with which chains are expanding and being demanded by customers.
Another trend is the growth in ZK-chains or high-throughput blockchains as our industry chases more real-world use cases. These types of chains require large server instances with disc sizes exceeding 20, 30, even 40 TBs to run nodes. This drives up the fixed cost requirements to run nodes profitably; often leaving teams to build less redundant, lower quality, setups to cut costs. This trade-off has resulted in decreased industry performance
With this evolution of the market, running RPC infrastructure has become economically challenging. All of this makes clear why the RPC trilemma is a real and practical challenge: it’s hard to simultaneously maximize uptime/quality, connect to everything, and keep costs low. However, the ecosystem is actively seeking solutions to ease these trade-offs.
DIN: A Unified, Elegant Solution to the Trilemma
Blockchains have the expectation that they are never-down; and so too should the infrastructure API gateways through which the ecosystem connects to them. The industry deserves a solution that breaks through the RPC Trilemma.
We should embrace the superpowers of web3. The industry should no longer stitch together clunky solutions that aggregate a multitude of web2-style API SaaS companies. Instead a permissionless, incentivized protocol should represent the dial-tone the industry taps into to access the redundancy, chain breadth, and specialized performance needs.
Infura introduced the DIN in late 2022. DIN tackles the RPC trilemma by building a unified Web3 API Marketplace and services layer. Instead of Dapps connecting to a single provider’s server cluster, they connect to the DIN protocol, which routes their requests to a pool of 50+ independent providers in the network. These providers include both large infrastructure firms and smaller node operators around the world.
DIN acts as an intelligent gateway: if one provider fails or is overloaded, the request seamlessly fails over to another, without the Dapp needing to do anything.
Finally, DIN is building a marketplace. If you disagree with DIN’s intelligent gateway; you can tap into the marketplace, optimizing API requests across the community of over 50+ independent web3 API providers.
Stay tuned for more by following @DINBuild across socials.