Introduction to the Web3 Conundrum
On October 20, a brief hiccup in Amazon’s US-EAST-1 region sent shockwaves across the crypto industry, affecting services like Coinbase, Infura, and Alchemy, and causing timeouts for several wallets and rollups. This incident highlighted a critical issue: despite the rhetoric of decentralization, much of Web3 is still heavily reliant on Web2 infrastructure, making it vulnerable to single points of failure.
The root cause of these errors wasn’t the blockchains themselves, which maintained consensus without issues. Instead, the problems lay in the surrounding infrastructure, including cloud databases, RPC gateways, DNS, indexers, and key management systems that make blockchains usable as applications.
The Invisible Monoculture of Web3
Behind the scenes of Web3’s decentralized facade lies a complex dependency map that is surprisingly centralized. A typical decentralized application (dApp) often starts with a frontend hosted on services like S3 or Cloudflare Pages, served via content delivery networks (CDNs) like Fastly, and resolved by DNS services such as Route 53 or Cloudflare DNS.
These applications typically include read and write RPCs (Remote Procedure Calls), frequently provided by services like Infura, Alchemy, or QuickNode, most of which run on Amazon Web Services (AWS) or one of the other “Big 3” cloud providers. Additionally, indexers like The Graph or Covalent, sequencing services for rollups, and custody or key management systems like Fireblocks are also part of the stack, each introducing a potential single point of failure.
The recent AWS outage, which affected DynamoDB and DNS services, had a cascading effect on multiple tiers of the crypto ecosystem. Coinbase’s API slowed down, Infura and Alchemy reported issues related to AWS, and several rollups experienced sequencer stalls that required manual intervention. This incident, along with previous ones such as The Graph’s indexer for zkSync showing fragility weeks earlier, underscores the lack of redundancy in the system.
The Myth of Independence in Web3
It’s common to conflate chain resiliency with application resiliency, but the reality is that while blockchains like Ethereum or Solana can maintain consensus across global nodes, the tools and services used to interact with these blockchains often depend on centralized intermediaries.
Each layer of the Web3 stack introduces its own vulnerabilities. For instance, sequencers on Layer 2 (L2) solutions are mostly single-operator setups, making them susceptible to disruptions if their connection to Ethereum’s RPC is interrupted. Similarly, content delivery networks (CDNs) and DNS services can lead to further fragility, as seen in Cloudflare’s resolver issue that left parts of the internet unreachable for almost an hour.
Even “decentralized” storage solutions can still rely on a single company, as evidenced by the failure of Infura’s IPFS gateway, which stopped access to assets that were theoretically mirrored across the network. Custody and key management platforms, such as Fireblocks, used by exchanges and funds, have also experienced processing delays, impacting withdrawals and settlements.
Towards a More Resilient Web3
The solution to these issues isn’t revolutionary but is gradually being implemented. Developers are introducing vendor quorum RPCs that query multiple endpoints, including self-hosted, SaaS, and decentralized options, and only show a result if two out of three agree. Tools like Helios are bringing light client verification directly to wallets and mobile apps, enabling users to validate data without relying on a central gateway.
Infrastructure teams are adopting multi-CDN and multi-DNS setups with active failover. For storage, running one’s own IPFS gateway or mirroring assets on Arweave or Irys is becoming a standard practice. In the rollup world, projects are building shared or decentralized sequencers, while others are rolling out permissionless proof of errors.
Institutional pressures, including the EU’s Digital Operational Resilience Act (DORA) and the UK’s Critical Third Parties regime, will further reinforce these changes, making multi-cloud architectures a policy requirement rather than a preference for major custodians and exchanges.
Conclusion: Decentralization in Progress
The recent outages serve as a stark reminder that the underlying framework of Web3 has not yet caught up with its ideals of decentralization. None of this means that crypto will become completely independent of traditional infrastructure, but it will narrow the gap between the ideals and the operational reality.
A truly decentralized application doesn’t necessitate every user running a server; it means that no single server can shut down the system. Until this becomes the default, any “Web3” outage will still start the same way: when the cloud sneezes, the blockchain shakes.
For more insights and details on this critical aspect of Web3’s development, visit https://cryptoslate.com/if-web3-is-decentralized-why-do-dapps-break-when-the-cloud-goes-down/.
