The Hidden Centralization in Web3: DNS as a Single Point of Failure

Your contracts are immutable. Your domain isn't.

By Kofi Otuo · 29 July 2026 · 6 min read

Decentralised access — a three-part series
  1. The Hidden Centralization in Web3: DNS as a Single Point of Failure — you are here
  2. The Browser Is the Bottleneck: Why dApps Can’t Escape HTTP
  3. Deterministic IPFS as a Browser-Compatible Discovery Layer
The path from a browser to a chain: four single points of failure, none of them on-chain.
The path from a browser to a chain: four single points of failure, none of them on-chain.

On June 21, 2022, half the internet went dark for about an hour. Cloudflare pushed a misconfigured network update, 19 of its data centers stopped serving traffic, and the blast radius covered Discord, Shopify, Coinbase, and a long tail of dApps that all happened to route their frontends through the same CDN.

The contracts didn't go down. Ethereum kept producing blocks. Solana kept producing blocks (well, mostly). The chain was fine.

You just couldn't reach it.

That's the gap I want to talk about. We've spent a decade building "decentralized" backends. We have not, in any meaningful sense, decentralized access to them.

What "decentralized" actually means today

When someone says they built a Web3 app, they usually mean:

Two out of four steps are decentralized. The first contact a user has with your "decentralized" app is the most centralized part of the entire stack.

The DNS chokepoint, in plain English

Every time you type app.uniswap.org into a browser, here's what happens:

  1. Your computer asks a DNS resolver for the IP address behind that domain.
  2. That resolver chains up through ICANN's root servers, Verisign's .org registry, and the operator's authoritative DNS provider.
  3. You get an IP. You connect.

Each link in that chain is owned by exactly one entity. Each one can:

The blockchain doesn't care about any of this. The blockchain doesn't have a domain.

Real incidents, not hypotheticals

Tornado Cash, August 2022. OFAC sanctions hit. The smart contracts on Ethereum kept running — they're just code. But the tornado.cash domain went dark within days, the GitHub repository was taken down, and the official frontend disappeared. Users with funds locked in the contracts had to dig up community-maintained mirrors or interact with the contract directly via Etherscan to recover their assets. The protocol was "decentralized." The access wasn't.

Uniswap, July 2021. Uniswap Labs delisted around 100 tokens from app.uniswap.org citing "regulatory developments." The liquidity pools were still on-chain. The pairs still traded. They just disappeared from the official frontend. Most users never knew they were still tradeable.

OpenSea, March 2022. Users from Iran reported being locked out of the OpenSea UI based on geo-IP. They still owned the NFTs on-chain. They just couldn't list, buy, or transfer them through the app.

Cloudflare, November 2023 and again June 2024. Multi-hour outages took down a significant chunk of the dApp ecosystem because most projects route through Cloudflare for DDoS protection.

ENS. Even ENS — the supposed decentralized naming system — usually resolves to dApps through gateways like eth.limo and eth.link, which are themselves DNS-resolved domains hosted on regular CDNs. Decentralization at one layer is undone at another.

The pattern is the same every time. The chain is fine. The access path failed.

Decentralized backend ≠ decentralized access

Putting your state on Ethereum doesn't make your app censorship-resistant if the way users reach the app is a single domain on a single CDN. Think of it like a bank vault buried fifty feet underground in a fortified bunker — with the only key taped to the front door of the bunker. The vault is fine. The door isn't.

What good is an immutable contract if the gate to it can be padlocked?

The "last mile" problem

In telecom, the last mile is the connection from the network backbone to your house. It's the most expensive, most fragile, and most political part of the network. It's also the part that determines whether you actually have internet.

Web3 has the same problem, and almost nobody is working on it.

Look at where the funding goes:

Each of those problems already has half a dozen working answers. What I almost never see funded is the path from a user's browser tab to the chain. That's the last mile. That's where censorship actually happens. That's where outages actually bite.

We don't need another chain

I'm tired of projects whose pitch is "we built a new blockchain because [reason]." We have enough chains. The chains work.

What we need is to fix the part that doesn't.

Where VoiceBan fits

VoiceBan isn't another chain trying to compete with Ethereum, Solana, or Polkadot. The problem we're solving sits one layer above that: how does the frontend that talks to the chain get to the user without DNS, without a CDN, and without a domain registrar with a kill switch?

The answer involves three pieces I'll cover in detail across this series:

  1. The frontend itself ships as content-addressed assets — pinned to IPFS, fingerprinted by hash. voiceban.com exists as a convenience for newcomers — most users will hit that first — but the same app is reachable through any IPFS gateway by content hash, and after the first visit the PWA runs locally regardless of whether the domain is up. If voiceban.com is seized tomorrow, the app doesn't go with it.
  2. The list of validator backends rotates deterministically and is published to IPNS. No hardcoded RPC endpoints, no Infura, no Alchemy. The frontend computes where the backends should be at any given minute and finds them through public IPFS gateways. Multiple gateways. In parallel. Any one going down doesn't matter.
  3. The user's wallet is local-first. Keys never leave the device, and the entire app works offline-first against a cached state.

The result: there is no single domain that can be seized, no single CDN that can fail, no single RPC provider that can rate-limit you out of your own funds. The same forces that protect a smart contract from being rewritten now protect the path to it.

That's the last mile.

What's next

The obvious question after reading this is: if DNS has been broken for this long, why hasn't anyone fixed it? In the next post I'll dig into why — specifically, why the browser, of all things, is what keeps every dApp tied to HTTP, DNS, and a domain registrar in the first place. The constraints are real, and they explain why "just use libp2p" is not the answer people think it is.

References

NextThe Browser Is the Bottleneck: Why dApps Can’t Escape HTTP