Your sequencer is centralized. Rollups like Arbitrum and Optimism use a single, permissioned sequencer for transaction ordering. This creates a single point of failure and censorship, making the L2's security dependent on the honesty of one entity.
Why Your Decentralized App Is Still Centralized
A technical audit of the hidden centralization vectors in modern dApps, from RPC endpoints and frontend hosting to data indexing. We map the critical chokepoints and analyze emerging solutions.
The Decentralization Illusion
Your application's decentralization is limited by the most centralized component in its tech stack.
RPC endpoints are centralized. Over 80% of dApp traffic flows through centralized providers like Infura and Alchemy. If these services fail or censor, your application stops functioning for most users.
Oracles are centralized. Price feeds from Chainlink dominate DeFi, creating systemic risk. A failure or manipulation of these centralized data feeds can cascade through protocols like Aave and Compound.
Cross-chain bridges are centralized. Most bridges, including early versions of Multichain and Stargate, rely on a multisig council for security. This replaces trust in a blockchain's validators with trust in a handful of key holders.
Executive Summary: The Three Chokepoints
Decentralization is a spectrum, and most dApps are far more centralized than their smart contracts suggest. The chokepoints are in the infrastructure.
The RPC Chokepoint
Your dApp's gateway to the blockchain is a single point of failure. Centralized RPC providers like Infura and Alchemy see >50% of Ethereum traffic, creating systemic censorship and downtime risk.
- Single Point of Failure: One provider outage can brick your entire frontend.
- Data Centralization: Providers can track, front-run, and censor user transactions.
- Vendor Lock-in: Creates dependency on a centralized entity's pricing and policies.
The Sequencer Chokepoint
Rollups trade base-layer decentralization for scalability, but their sequencers are often a single, centralized operator. This creates a temporary but critical centralization vector.
- Transaction Ordering: Central sequencers (e.g., Arbitrum, Optimism) can extract MEV and reorder transactions.
- Liveness Risk: A single sequencer failure halts the entire L2 chain.
- Withdrawal Delays: Users must trust the sequencer to post data back to L1, requiring a 7-day challenge period for security.
The Oracle Chokepoint
DeFi's trillion-dollar TVL rests on a handful of data feeds. Chainlink dominates with >50% market share, creating a critical dependency for price discovery and liquidation events.
- Single Source of Truth: A bug or attack on the primary oracle can cascade through the entire DeFi ecosystem.
- Data Latency: In volatile markets, even slight delays can be exploited for millions in arbitrage.
- Governance Risk: Oracle networks, while decentralized, still have upgrade keys and governance tokens controlled by core teams and whales.
The Central Thesis: Infrastructure is the Final Frontier
Your application's decentralization is only as strong as its weakest infrastructure dependency.
Your dApp is a facade. The front-end logic on-chain is a veneer over a centralized infrastructure stack. The user's wallet, the RPC endpoint they query, and the sequencer ordering their transactions are single points of failure.
RPC providers dominate access. Over 90% of Ethereum traffic flows through centralized RPC gateways like Infura or Alchemy. This creates a permissioned layer that can censor or front-run transactions, negating the base chain's properties.
Sequencers control execution. On L2s like Arbitrum and Optimism, a single sequencer has the exclusive right to order transactions. This creates a centralized bottleneck for MEV and liveness, a trade-off for scalability that most users ignore.
Evidence: The 2022 Infura outage took down MetaMask, OpenSea, and Polygon, proving that decentralized applications rely on centralized services. The failure of one AWS region halted billions in economic activity.
The Centralization Scorecard: Major dApp Dependencies
A quantitative breakdown of the centralized dependencies that persist in top-tier DeFi and NFT applications, exposing their operational and security risks.
| Critical Dependency | Uniswap (v3/v4) | Aave (v3) | OpenSea (Seaport) | Compound (v3) |
|---|---|---|---|---|
RPC/Node Provider | Alchemy (Primary), Infura | Alchemy, Infura, QuickNode | Alchemy, Infura | Alchemy, Infura |
Data Indexing / Subgraph | The Graph (Hosted Service) | The Graph (Hosted Service) | Proprietary API | The Graph (Hosted Service) |
Fiat On-Ramp Provider | MoonPay, Transak | Transak | MoonPay | |
Off-Chain Orderbook / Solver | UniswapX (0x, 1inch) | Seaport Protocol (Off-chain) | ||
Governance Execution (Multisig) | Uniswap Labs (4/6) | Aave Companies (5/9) | OpenSea (5/9) | Compound Labs (4/6) |
Price Oracle (Primary) | Uniswap V3 TWAP | Chainlink | Proprietary | Chainlink |
Max Time-to-Censorship (RPC) | < 5 min (Provider TOS) | < 5 min (Provider TOS) | < 5 min (Provider TOS) | < 5 min (Provider TOS) |
Client-Side Code Hosting | Cloudflare / AWS | Cloudflare / AWS | AWS | Cloudflare / AWS |
Anatomy of a Centralized dApp
Most dApps are centralized products built on decentralized protocols, with critical failure points in their operational stack.
Frontend Centralization is the norm. Your dApp's website relies on centralized DNS, AWS/Azure hosting, and Cloudflare. A single takedown notice disables user access, as seen with Tornado Cash.
RPC endpoints are a single point of failure. Relying on a single provider like Infura or Alchemy means your app fails if their service degrades, which centralizes transaction censorship.
Admin keys control the protocol. Upgradeable contracts with multi-sigs held by the founding team represent the ultimate centralization vector, enabling rug pulls or unilateral changes.
Oracle dependencies create centralized truth. Price feeds from Chainlink or Pyth are trusted data layers; if compromised, they manipulate your entire application's logic and user funds.
Evidence: Over 95% of Ethereum dApps use Infura or Alchemy RPCs, and the SEC's case against Uniswap highlighted frontend control as a regulatory attack surface.
The Builders Fighting Back
Your dApp's frontend, data, and logic are likely controlled by single points of failure. These projects are fixing that.
The RPC Monopoly
Your dApp's gateway to the blockchain is probably a single, centralized RPC provider like Infura or Alchemy. This creates a critical censorship vector and data bottleneck.
- Solution: Decentralized RPC networks like POKT Network and Lava Network.
- Key Benefit: Fault tolerance via multi-provider routing and slashing for downtime.
- Key Benefit: Unbundled access, preventing a single entity from seeing all user traffic.
Hosting on AWS is a Trap
A centralized frontend hosted on AWS or Cloudflare is a kill switch. A government or provider can take it down, bricking user access.
- Solution: Decentralized frontend protocols like IPFS, Arweave, and Fleek.
- Key Benefit: Censorship-resistant hosting via content-addressed storage.
- Key Benefit: Global persistence—once uploaded to Arweave, it's permanent.
The Oracle Problem
DeFi protocols relying on a single oracle (e.g., a sole Chainlink data feed) reintroduce centralization. The oracle is the truth.
- Solution: Decentralized Oracle Networks (DONs) and Pyth Network's pull-based model.
- Key Benefit: Data signed by 80+ first-party publishers, not a single oracle node.
- Key Benefit: Economic security via staking and slashing on inaccurate data.
MEV Extraction as a Service
Users lose value to centralized searchers and builders who monopolize block space. This distorts transaction fairness and finality.
- Solution: SUAVE (Single Unifying Auction for Value Expression) by Flashbots and MEV-Share.
- Key Benefit: Decentralizes block building by creating a competitive marketplace.
- Key Benefit: Returns MEV value back to users and applications via order flow auctions.
Sequencer Centralization
Rollups like Arbitrum and Optimism use a single, permissioned sequencer. This creates liveness risks and enables transaction censorship.
- Solution: Shared sequencer networks like Espresso Systems and Astria.
- Key Benefit: Decentralized sequencing across multiple rollups for atomic cross-rollup composability.
- Key Benefit: Censorship resistance via a validator set, not a single operator.
The Indexer Cartel
DApp data queries are served by centralized indexers like The Graph's hosted service, creating a data availability and reliability bottleneck.
- Solution: The Graph's decentralized network and competitor Subsquid.
- Key Benefit: Fault-tolerant queries with ~1000+ Indexers serving data.
- Key Benefit: Censorship-resistant APIs where data is served by a staked, slashed network.
The Pragmatist's Rebuttal (And Why It's Wrong)
Most dApp decentralization claims fail under scrutiny of their core infrastructure dependencies.
Infrastructure is the bottleneck. Your dApp's decentralization is capped by its weakest dependency. A decentralized frontend is irrelevant if the RPC endpoint, indexer, or sequencer is a single point of failure. This is the dependency hierarchy problem.
RPC providers centralize access. Over 80% of Ethereum traffic flows through centralized RPC services like Infura or Alchemy. Your dApp's users never touch a peer-to-peer node. Decentralized alternatives like POKT Network or Lava exist but require architectural commitment most teams avoid.
Sequencers control execution. On L2s like Arbitrum or Optimism, the single, centralized sequencer dictates transaction ordering and censorship. While decentralization roadmaps exist, the current operational reality is a trusted coordinator. This makes your 'decentralized' app a client of a centralized service.
Evidence: The MEV cartel. Look at Flashbots' SUAVE or the dominance of builders like Jito Labs. The entities that produce blocks and extract value are centralized cartels. Your dApp's economic fairness is outsourced to a black box.
The Bear Case: What Could Go Wrong?
Your dApp's decentralization is only as strong as its weakest dependency. These are the centralized bottlenecks you're likely running on.
The RPC Endpoint Monopoly
Your smart contract is on-chain, but every user query and transaction is routed through a centralized gateway. A single provider outage (e.g., Infura, Alchemy) can brick your entire frontend. This creates systemic risk for DeFi protocols and NFT marketplaces.
- >60% of Ethereum traffic flows through two providers.
- Censorship vector: Providers can blacklist addresses or contracts.
- Data integrity risk: Malicious RPCs can return false chain data.
The Sequencer Sovereignty Problem
Rollups like Arbitrum and Optimism rely on a single, permissioned sequencer to order transactions. This creates a temporary but critical centralization point where the sequencer can censor, front-run, or reorder transactions for MEV. While fraud proofs offer eventual security, liveness depends on a single entity.
- ~7-day challenge window for fraud proofs on Optimistic Rollups.
- Single sequencer controls transaction ordering and latency.
- Centralized upgrade keys often held by founding teams.
The Oracle Oligopoly
DeFi's trillion-dollar TVL is secured by a handful of data providers. Chainlink dominates, creating a systemic reliance where a bug or governance attack could destabilize major protocols like Aave and Compound. Alternative oracles (e.g., Pyth, API3) face similar centralization in their node operator sets.
- Chainlink secures >$50B in DeFi TVL.
- Permissioned node operators with high staking barriers.
- Data source centralization: Many feeds pull from the same few APIs.
The Frontend Kill Switch
Your decentralized application is hosted on a centralized domain (AWS, Cloudflare) and served via a centralized DNS. This allows for legal or technical takedowns, as seen with Tornado Cash and dYdX's frontend. IPFS helps but doesn't solve discovery. True decentralization requires resilient hosting and censorship-resistant gateways.
- >90% of dApp frontends hosted on centralized cloud providers.
- Single-point DNS failure enables easy censorship.
- ENS + IPFS is a partial solution with poor UX and latency.
The Bridge Custodian Risk
Cross-chain assets are often just IOU tokens backed by a centralized multisig or a small validator set. Bridges like Multichain (hacked) and Wormhole (exploited) show the catastrophic failure mode. Even "decentralized" bridges (e.g., Across, LayerZero) rely on external assumptions and relayers that can be points of control.
- >$2B stolen from cross-chain bridges since 2020.
- ~8/15 multisigs common for "canonical" bridge security.
- Relayer centralization creates liveness and censorship risks.
The Governance Illusion
Protocol governance tokens are often concentrated among early investors and teams, making "decentralized" upgrades a formality. Voter apathy leads to <5% participation, enabling whale manipulation. Snapshot votes are off-chain and non-binding, while on-chain execution relies on a privileged multisig (e.g., Uniswap, Compound).
- <5% tokenholder participation in most governance votes.
- Top 10 addresses often control >30% of voting power.
- Timelock + multisig is the de facto execution mechanism.
The Path to True Decentralization
Your application's decentralization is a myth if its core infrastructure relies on centralized choke points.
RPC endpoints are centralized. Most dApps default to Infura or Alchemy, creating a single point of failure and censorship. The network's liveness depends on these centralized API gateways.
Sequencer control is centralized. Rollups like Arbitrum and Optimism use a single, corporate-operated sequencer. This creates a trusted execution layer that contradicts the base chain's security model.
Oracle feeds are centralized. Price data from Chainlink or Pyth relies on a permissioned set of nodes. The entire DeFi stack becomes vulnerable if this small committee fails or colludes.
Evidence: Over 80% of Ethereum traffic routes through Infura or Alchemy. A takedown request to these providers would cripple the front-end for most major dApps.
TL;DR for Architects
Your dApp's frontend, RPC, and oracle dependencies create single points of failure that undermine your protocol's core value proposition.
The Frontend is a Single Point of Censorship
Hosting your UI on centralized services like AWS or Cloudflare makes it trivial for regulators to take it down, severing user access. The protocol lives on-chain, but users can't reach it.
- Key Risk: A single takedown notice can kill your entire application's accessibility.
- Key Solution: Explore decentralized frontend hosting via IPFS, Arweave, or networks like Fleek and Spheron.
Your RPC Provider is a Centralized Gateway
Defaulting to Infura or Alchemy for node access means your app inherits their compliance policies and infrastructure risk. They can censor transactions or fail, breaking your app.
- Key Risk: RPC providers can filter or block transactions based on OFAC lists.
- Key Solution: Implement fallback RPCs, use decentralized RPC networks like POKT, or incentivize users to run their own light clients.
Oracle Reliance Creates a Centralized Truth
Dependence on a single oracle like Chainlink, while robust, reintroduces a trusted third party. Your DeFi protocol's solvency hinges on their data feed's correctness and liveness.
- Key Risk: A corrupted or delayed price feed can be exploited for $100M+ in minutes.
- Key Solution: Use multiple oracle providers (e.g., Pyth, API3), implement TWAPs, or design for oracle-minimized architectures.
The Sequencer is Your New Validator
On L2s like Arbitrum or Optimism, the sole sequencer orders all transactions. This creates a central point for MEV extraction and potential downtime, reverting to L1 security only in failure modes.
- Key Risk: Sequencer can front-run, censor, or go offline, halting the chain.
- Key Solution: Advocate for and design with decentralized sequencer sets, shared sequencers like Espresso, or based sequencing that uses Ethereum for ordering.
Governance Tokens Are Not Control
Low voter turnout and whale concentration mean a handful of entities control protocol upgrades and treasury funds. This makes your "DAO" a de facto multisig controlled by VCs or foundations.
- Key Risk: <5% token holder participation enables capture by insiders or attackers.
- Key Solution: Implement rage-quit mechanisms, futarchy, or minimal governance that delegates only parameter tuning, not full upgrade power.
The Bridge is a Centralized Vault
Most cross-chain bridges rely on a multisig or a small validator set to custody funds. This creates a $2B+ honeypot for hackers and a critical trust assumption (e.g., Multichain, Wormhole).
- Key Risk: A bridge hack destroys the canonical representation of your asset on other chains.
- Key Solution: Prefer native asset transfers (LayerZero, CCIP), light client bridges (IBC), or liquidity network models (Connext, Across).
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.