Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
security-post-mortems-hacks-and-exploits
Blog

Why Decentralized Oracles Are Still Centralized

An analysis of the hidden points of centralization in major oracle networks like Chainlink, focusing on governance, data sourcing, and node operation risks that contradict their decentralized marketing.

introduction
THE TRUST FALLACY

Introduction

Decentralized oracle networks like Chainlink and Pyth operate with centralized bottlenecks that contradict their core value proposition.

Decentralized Oracles Are Centralized. The core contradiction is that while the data source network is decentralized, the oracle node operators themselves are centralized entities. These are often the same professional staking services that run L1 validators, creating a single point of failure for data delivery across hundreds of protocols.

The Data Source Is The Bottleneck. Protocols like Chainlink aggregate data from centralized APIs (e.g., CoinGecko, Binance). The decentralization is in the relay of this data, not its origin. A compromised or manipulated API endpoint corrupts the entire oracle network, regardless of node count.

Committee-Based Consensus Fails. Networks like Pyth use a permissioned committee of major market makers and exchanges to publish prices. This creates a trusted cartel model where security depends on the collusion resistance of a small, identifiable group, not cryptographic proof.

Evidence: The 2022 Mango Markets exploit demonstrated this. A single oracle price feed from Pyth was manipulated, leading to a $114M loss. The attack vector was the centralized data source, not the blockchain or the smart contract logic.

thesis-statement
THE ORACLE PROBLEM

The Centralization Trilemma

Decentralized oracle networks fail to solve their core problem, creating a trilemma between security, cost, and speed.

Decentralization is a cost center. Every oracle node adds latency and expense for data fetching and consensus. Protocols like Chainlink and Pyth optimize by using a small, permissioned committee of professional node operators to achieve finality in seconds, not hours.

The data source is the root. An oracle network with 100 nodes is irrelevant if all query the same centralized API from CoinGecko or Binance. True decentralization requires sourcing from hundreds of independent data providers, which no major oracle currently does at scale.

Security is a trade-off. The trilemma forces a choice: high security with slow, expensive updates (e.g., MakerDAO's 1-hour delay), low cost with trusted committees (Pyth), or low latency with centralization risk. There is no free lunch.

Evidence: Chainlink's dominant DeFi market share relies on ~30 node operators for its core ETH/USD feed, not thousands. Pyth's speed comes from a whitelisted publisher set. The decentralization is in the aggregation, not the source.

THE DATA LAYER'S HIDDEN HIERARCHY

Oracle Network Centralization Scorecard

A first-principles breakdown of where decentralization fails in major oracle networks, from node selection to data sourcing.

Centralization VectorChainlinkPyth NetworkAPI3

Node Operator Selection

Permissioned, Council-Governed

Permissioned, Pyth DAO-Governed

Permissionless, Staking-Based

Active Node Operators (Count)

~50

~90

100 (dAPI)

Data Source Curation

Centralized Team

Pyth Data Association

dAPI Providers (Direct)

On-Chain Aggregation Model

Off-Chain Report (OCR) → On-Chain

Pull Oracle (Wormhole)

First-Party (Airnode)

Single-Source Data Feeds (%)

< 5%

95%

0% (Multi-Source Aggregated)

Governance Token Required for Node Operation

Upgradeability / Admin Key Control

4/9 Multisig

Pyth DAO Multisig

API3 DAO

Historical Data Availability (Blocks)

Limited via OCR

On-Demand via Pythnet

Not Applicable

deep-dive
THE NODE OPERATOR PROBLEM

The Governance Black Box

Decentralized oracle networks like Chainlink and Pyth are operationally centralized due to concentrated node operator control and opaque governance.

Node operator cartels control oracle networks. The economic and technical barriers to running a high-reputation node create a small, entrenched group of professional operators, replicating the centralized validator problem seen in early Proof-of-Stake chains.

Governance is a facade for most users. While token holders vote on upgrades, the critical power—selecting and slashing node operators—resides with a centralized multisig or foundation, as seen in Chainlink's early phases and Pyth's publisher council.

Data sourcing remains opaque. Oracles aggregate off-chain data, but the initial sourcing from centralized APIs like Bloomberg or CoinGecko creates a single point of failure that decentralization downstream cannot fully mitigate.

Evidence: Chainlink's dominant market share (>45% TVS) and reliance on ~30 professional node operators demonstrates that decentralization is a spectrum, not a binary state achieved by any major oracle today.

case-study
THE ARCHITECTURE TRAP

Case Studies in Oracle Failure

Decentralized applications built on centralized oracle data feeds inherit a single point of failure, making systemic risk inevitable.

01

The Synthetix sKRW Incident

A single Chainlink node operator submitted a stale Korean Won price feed, causing a $1B+ DeFi protocol to reference incorrect data. The 'decentralized' network failed because the architectural dependency was on one node's API call.\n- Failure Mode: Data Source Centralization\n- Root Cause: Reliance on a single external API endpoint

1 Node
Single Point
$1B+
Protocol TVL
02

The bZx Flash Loan Attack

Attackers manipulated a low-liquidity KyberSwap pool to create a skewed price, which was then reported by the oracle (Kyber itself) to bZx's lending protocol. This allowed a profitable flash loan exploit.\n- Failure Mode: Manipulable Price Source\n- Root Cause: Oracles sourcing from their own DEX liquidity

$954K
Funds Lost
1 Tx
Attack Vector
03

The Mango Markets Exploit

An attacker artificially inflated the price of MNGO perpetuals on Mango's internal oracle, then borrowed against the inflated collateral. The 'oracle' was just the protocol's own DEX mid-price, not a decentralized feed.\n- Failure Mode: Self-Referential Data\n- Root Cause: Lack of independent, multi-source validation

$114M
Value Extracted
100%
Internal Feed
04

The Chainlink Fallback Mechanism Gap

While Chainlink uses ~31 decentralized nodes, its security model relies on honest majority assumptions and trusted data providers (e.g., BraveNewCoin). If the primary data source is compromised or censored, all nodes report the same corrupted data.\n- Failure Mode: Data Aggregation Centralization\n- Root Cause: Common off-chain dependencies across nodes

~31 Nodes
Decentralized?
1 Source
Common Dependency
05

MakerDAO's PSM Reliance on USDC

Maker's Peg Stability Module (PSM) for DAI relied entirely on Circle's attestations for USDC collateral value. When USDC depegged after Silicon Valley Bank's collapse, it threatened DAI's stability, forcing emergency governance.\n- Failure Mode: Centralized Stablecoin Oracle\n- Root Cause: Legal/Off-Chain Trust in a Corporate Entity

$3B+
PSM Exposure
$0.87
Depeg Low
06

The Solution: Intent-Based Architectures

Protocols like UniswapX and CowSwap bypass oracle risk entirely for swaps by using a fill-or-kill intent model. Solvers compete to provide the best execution, with settlement guaranteed by the base layer. The oracle is the blockchain state itself.\n- Key Shift: From Trusted Data to Verifiable Execution\n- Emerging Standard: Across Protocol and LayerZero's OFT for cross-chain, Anoma for generalized intents

0 Oracles
For Swaps
Solver Network
New Primitive
counter-argument
THE ARCHITECTURAL REALITY

The Rebuttal: "But It Works!"

Operational success does not negate the underlying centralization vectors inherent in current oracle designs.

The oracle is the root signer. The final data point delivered on-chain is signed by a single, centralized oracle node or a multi-sig controlled by the provider like Chainlink or Pyth. This makes the provider's key management and internal governance the ultimate security bottleneck, a single point of failure.

Data sourcing remains opaque. While nodes may aggregate from multiple sources, the initial data ingestion layer—the API connections to TradFi feeds or CEXes—is a centralized chokepoint. A provider like Chainlink cannot decentralize the New York Stock Exchange's data pipeline.

Decentralization theater is prevalent. Running 100 nodes means nothing if they all source from the same three centralized data providers, run by the same team, on the same cloud infrastructure (AWS, GCP). This creates systemic correlated risk.

Evidence: The Solana Pyth network outage in April 2024, where price updates stalled for over an hour, demonstrated that even high-throughput oracles are vulnerable to centralized coordination failures in their core protocol layer.

FREQUENTLY ASKED QUESTIONS

FAQ: Oracle Centralization

Common questions about why decentralized oracle networks still face centralization risks.

No, most decentralized oracle networks (DONs) like Chainlink and Pyth are operationally centralized at the node operator and data source layers. The network's security depends on a small, permissioned set of node operators, and they often aggregate data from a handful of centralized data providers like Binance or Coinbase, creating single points of failure.

future-outlook
THE ORACLE DILEMMA

The Path Forward: Less Trust, More Proof

Decentralized oracles like Chainlink and Pyth rely on centralized data sourcing and committee models, creating systemic trust assumptions that must be minimized.

Data sourcing remains centralized. Chainlink and Pyth nodes aggregate price feeds from centralized exchanges like Binance and Coinbase. The decentralized network merely relays data from these single points of failure, inheriting their vulnerabilities.

Consensus is social, not cryptographic. Oracle networks use committee-based attestation, where a quorum of known nodes votes on data validity. This is a trusted setup that differs fundamentally from the cryptographic guarantees of the underlying blockchain.

Proof-based designs are emerging. Protocols like EigenLayer AVS and Brevis coChain are pioneering zk-proofs for data attestation. These systems cryptographically prove the correctness of source data and its computation, moving from trust to verification.

Evidence: Chainlink's dominant Proof of Reserve service relies on manual attestations from a handful of auditors, not on-chain cryptographic proofs, exposing a critical trust vector for DeFi's $50B+ in bridged assets.

takeaways
ORACLE VULNERABILITY

Key Takeaways for Builders

The 'decentralized' oracle narrative often obscures critical centralization vectors that threaten protocol security.

01

The Data Source Problem

Oracles like Chainlink and Pyth aggregate data from centralized CEX APIs, creating a single point of failure. The decentralization is in the node network, not the data origin.

  • Vulnerability: A coordinated API shutdown or manipulation at the source (e.g., Binance, Coinbase) can corrupt the entire feed.
  • Reality: Most price feeds rely on <10 primary data aggregators, a systemic risk for $10B+ in DeFi TVL.
<10
Primary Sources
$10B+
TVL at Risk
02

The Node Cartel Risk

Oracle networks often have permissioned, reputation-based node sets dominated by a few large entities (e.g., staking providers, VCs). This creates governance and liveness risks.

  • Centralization: A ~5-10 entity cartel can collude to censor or manipulate data if economic incentives align.
  • Solution Path: Builders must audit oracle node operator diversity and mandate designs like UMA's optimistic oracle or API3's first-party oracles to reduce intermediary risk.
5-10
Entity Cartel
High
Collusion Risk
03

The Upgrade Key Centralization

Admin keys or multi-sigs controlling oracle contract upgrades are a near-universal backdoor. This includes major players like Chainlink and Pyth.

  • Single Point of Failure: A compromised multi-sig can instantly alter feed logic or drain funds from dependent protocols.
  • Builder Action: Favor oracles with time-locked, governance-controlled upgrades or immutable configurations. Treat admin keys as an active security debt.
24-48h
Safe Time-Lock
Critical
Security Debt
04

The L1 Consensus Dependency

Oracle security is only as strong as the underlying blockchain's consensus. A >33% attack on Ethereum or Solana could irreversibly finalize corrupted oracle data.

  • Systemic Risk: This creates a hidden correlation where oracle decentralization is capped by L1 decentralization.
  • Mitigation: For ultra-high-value contracts, consider multi-chain oracle aggregation (e.g., across Ethereum, Solana, Cosmos) to break consensus dependency.
>33%
L1 Attack Threshold
Multi-Chain
Mitigation
ENQUIRY

Get In Touch
today.

Our experts will offer a free quote and a 30min call to discuss your project.

NDA Protected
24h Response
Directly to Engineering Team
10+
Protocols Shipped
$20M+
TVL Overall
NDA Protected Directly to Engineering Team
Why Decentralized Oracles Are Still Centralized (2024) | ChainScore Blog