Major RPC Outage Freezes Wallets and DeFi Front-Ends for Two Hours
A two-hour outage at a single dominant RPC provider knocked out wallet balances, swap interfaces and dashboards across multiple chains at once, reviving the debate over how decentralized 'decentralized' finance really is.
For roughly two hours, a large slice of the DeFi user experience simply stopped working. Wallets showed zero balances, swap interfaces failed to quote prices, and dashboard front-ends across multiple unrelated chains threw errors at the same time. The cause wasn't a smart contract exploit or a validator halt. It was a single RPC infrastructure provider going down, and it's a reminder of a fact the industry likes to talk around: most of the apps calling themselves decentralized are, in practice, routed through a small handful of centralized chokepoints.
What actually broke
RPC providers are the middleware layer that lets a wallet or website ask a blockchain a question — what's this address's balance, has this transaction confirmed — without the end user running their own full node, which almost nobody does. A handful of companies now handle the overwhelming majority of that traffic across Ethereum, its rollups, and several other major chains. When one of them has an infrastructure failure, every app that defaults to its endpoints goes dark simultaneously, even though the underlying blockchains themselves kept producing blocks the entire time without incident.
That distinction matters and it's the one most outraged users online got wrong within minutes of the outage starting. The chains were fine. The view into the chains broke. Funds were never at risk, contracts kept executing, and anyone running their own node or pointed at a backup provider noticed nothing unusual. But that cohort is a rounding error of total users, and for everyone else the practical experience was indistinguishable from the network itself being down.
Why this keeps happening
This is not the first time a single RPC provider's downtime has cascaded into a multi-protocol front-end failure, and it won't be the last, because the economics push hard toward consolidation. Running reliable, low-latency RPC infrastructure at scale is expensive and operationally demanding, and most application teams reasonably decide it's not their core competency. So they default to whichever provider offers the best free tier or the most generous enterprise deal, and the ecosystem's resilience quietly narrows as a result.
The irony writes itself. Projects spend enormous energy decentralizing consensus, validator sets and governance tokens, then route the actual user-facing experience through infrastructure with fewer independent operators than a typical regional bank's data centres. It's not fraud and it's not negligence exactly — it's a rational response to genuine engineering costs — but it does mean the industry's marketing regularly outruns its architecture.
What good practice looks like
The teams that shrugged off this outage were the ones running multi-provider fallback logic, where a front-end automatically switches to a secondary or tertiary RPC endpoint the moment the primary starts timing out. That pattern exists, it's well understood, and it's not particularly expensive to implement. It's simply been deprioritised by teams optimising for shipping features over resilience, which is an understandable trade-off until the day it very publicly isn't.
The takeaway for users
None of this should shake confidence in the underlying chains, which performed exactly as designed throughout. But it's a useful, low-stakes reminder to distinguish between a blockchain being down, which is rare and serious, and an interface to that blockchain being down, which is common and usually harmless beyond the inconvenience. For anyone holding meaningful value, knowing how to point a wallet at an alternative RPC endpoint, or running a light client locally, is a cheap insurance policy against the next provider that has a bad afternoon. There will be one.
