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
zk-rollups-the-endgame-for-scaling
Blog

The Hidden Centralization of Decentralized Data Availability Committees

Data Availability Committees (DACs) are marketed as a pragmatic scaling solution for ZK-Rollups. This analysis reveals the inevitable economic and technical pressures that centralize them, creating a critical, unspoken vulnerability in the scaling endgame.

introduction
THE FLAWED PROMISE

Introduction

Decentralized Data Availability Committees (DACs) are a critical scaling component, but their security models are often dangerously centralized.

Data Availability Committees (DACs) are a pragmatic scaling solution for rollups, offering cheaper data posting than full on-chain settlement. However, their security model hinges on a multi-signature quorum of trusted signers, not cryptographic proof.

The centralization is operational, not just theoretical. A DAC's security collapses to the weakest signer's security practices, creating a single point of failure that invalidates the rollup's liveness guarantees. This is a direct trade-off with pure solutions like EigenDA or Celestia.

Evidence: Major L2s like Arbitrum Nova and Polygon CDK chains rely on DACs (e.g., the EigenLayer AVS network) for cost-effective data. Their security is defined by the committee's honesty, not the underlying blockchain's.

deep-dive
THE DATA

The Inevitable Slide: Why DACs Can't Stay Decentralized

Decentralized Data Availability Committees structurally degrade into centralized bottlenecks, undermining the security of optimistic rollups.

Committees are centralized by design. A DAC's security model relies on a small, permissioned set of signers. This creates a single point of failure that is antithetical to the decentralized security of the underlying L1, like Ethereum.

Economic incentives drive centralization. The operational cost of running a high-availability node favors large, well-funded entities like Coinbase or Binance. Smaller participants get priced out, consolidating power.

The liveness assumption is fragile. Unlike Ethereum's robust validator set, a DAC's liveness depends on a handful of nodes. A coordinated outage or regulatory action against these few nodes breaks the rollup.

Evidence: The Celestia-inspired modular stack exposes this. Rollups using EigenDA or Avail inherit their security from those networks, not from a small committee. DACs are a temporary, centralized stepping stone.

THE DATA AVAILABILITY SPECTRUM

DAC vs. Full DA: The Trade-Off Matrix

A quantitative comparison of Data Availability Committee (DAC) solutions versus full on-chain Data Availability (DA), mapping the security-performance trade-offs for rollup architects.

Feature / MetricDAC (e.g., Celestia, EigenDA)Hybrid (e.g., Avail, Near DA)Full On-Chain (e.g., Ethereum, Arbitrum Nova)

Data Availability Guarantee

Probabilistic (K-of-N Signers)

Cryptoeconomic + Probabilistic

Cryptoeconomic (Full Consensus)

Time to Finality

< 2 seconds

~20 seconds

~12 minutes (Ethereum)

Cost per MB

$0.01 - $0.10

$0.10 - $0.50

$100 - $500

Trust Assumption

Honest Majority of Committee

Honest Majority + Light Client Sync

Honest Majority of L1 Validators

Censorship Resistance

Committee-dependent

Economic Slashing + Light Clients

L1-level (e.g., 33% honest assumption)

Data Redundancy

10-100 Nodes

100-1000+ Nodes

~1,000,000+ Nodes (Full Ethereum)

Interoperability Footprint

Limited to DAC Members

Native Light Client Bridges

Universal (EVM, WASM, etc.)

Upgrade Governance

Off-chain, Committee-led

On-chain + Off-chain Hybrid

On-chain, Protocol-governed

protocol-spotlight
THE HIDDEN CENTRALIZATION OF DECENTRALIZED DATA AVAILABILITY COMMITTEES

Case Studies in Centralization Pressure

Data Availability Committees (DACs) promise scalable security but often mask critical trust assumptions and centralization vectors.

01

Celestia's Rollup-Centric Model

Celestia's modular design outsources execution, creating a pure-play data availability (DA) market. Its security depends on a decentralized validator set, but early adoption is concentrated among a few high-stake operators. The economic model pressures smaller validators, risking a <10 entity oligopoly for critical L2 data.

  • Centralization Vector: Proof-of-Stake validator set consolidation under high hardware requirements.
  • Systemic Risk: A coordinated fault among top validators could censor or withhold data for major rollups like Arbitrum Orbit or Optimism Stack chains.
~100
Active Validators
>60%
Top 10 Stake Share
02

EigenDA's Restaked Security Dilemma

EigenDA leverages EigenLayer's restaking ecosystem to bootstrap a DA layer. While it uses a committee of operators, participant selection and slashing are managed by a centralized, upgradable contract suite controlled by Eigen Labs. This creates a single-point-of-failure in governance, not cryptography.

  • Centralization Vector: Administrative control over the operator set and slashing parameters.
  • Market Reality: Designed for high-throughput, low-cost demand from hyperchains within the EigenLayer and Polygon CDK ecosystems, creating a captive market.
200+
Operators
1
Governance Multisig
03

Avail's Proof-of-Stake vs. Committee

Avail uses a Nominated Proof-of-Stake (NPoS) model for its DA layer, blending validator decentralization with user-nominated security. However, its "Project Galaxy" DAC for Polygon zkEVM creates a separate, permissioned committee of known entities. This bifurcated model highlights the trade-off: decentralized base layer vs. centralized high-throughput client.

  • Centralization Vector: The DAC is a fixed set of institutional nodes, creating a trusted bridge for high-value state transitions.
  • Adoption Driver: Offers ~16KB per blob efficiency, attracting rollups needing cost-effective, enterprise-grade DA with faster finality.
100+
Validators
<10
DAC Members
04

The Near DA Gateway Risk

NEAR Protocol's DA solution uses its high-throughput blockchain as a data layer. While the NEAR base layer is decentralized, its integration as a DA provider for Ethereum rollups (e.g., via Caldera) funnels all external demand through a single, canonical bridge contract. This creates a centralized gateway where data availability for Ethereum L2s depends on the security and liveness of one cross-chain bridge.

  • Centralization Vector: All L2 data commits to Ethereum via a single verifier bridge contract.
  • Ecosystem Lock-in: Primarily serves the NEAR and Polygon ecosystems, creating a siloed DA market dependent on bridge security.
1
Canonical Bridge
Ethereum
Security Dependency
counter-argument
THE FLAWED DEFENSE

The Builder's Rebuttal (And Why It Fails)

Proponents of DACs argue their security model is sufficient, but their core assumptions are architecturally unsound.

The 'Sufficient Security' Fallacy: Builders claim a multi-signature committee with reputable members provides adequate security. This conflates trust minimization with trust redistribution, creating a permissioned bottleneck that contradicts the base layer's trustless design.

The Liveness Assumption Failure: DAC advocates assume committee liveness is guaranteed. Real-world outages from Celestia's data availability sampling or EigenDA operators prove this is a critical, unhedged risk for rollup finality.

Incentive Misalignment: A DAC's economic security relies on slashing reputational collateral, not cryptographic stake. This creates weaker penalties than Ethereum's restaking or Bitcoin's proof-of-work, making collusion cheaper.

Evidence: The Ethereum Foundation's danksharding roadmap explicitly moves away from committees, prioritizing data availability sampling and KZG commitments because DACs are a temporary, centralized crutch.

FREQUENTLY ASKED QUESTIONS

Frequently Challenged Questions

Common questions about the hidden centralization risks within Decentralized Data Availability Committees.

A DAC is a permissioned set of entities that cryptographically attest to data availability for layer 2 rollups. This is a lighter alternative to full on-chain posting, used by networks like Arbitrum Nova and Mantle. Members sign attestations, but the system's security depends entirely on their honesty and liveness, creating a trust assumption distinct from pure cryptographic guarantees.

takeaways
THE DAC ILLUSION

TL;DR for Architects and VCs

Data Availability Committees (DACs) are marketed as a decentralized scaling solution, but their security models often collapse to a single, trusted entity.

01

The 1-of-N Trust Assumption

Most DACs operate on a signature threshold model (e.g., 4-of-7). If even one honest member posts data, liveness is assured. However, this creates a single point of failure: you must trust that at least one member is honest and will not collude or be compromised. This is a softer, but still critical, trust assumption compared to a single sequencer.

  • Security Model: Weakens to 1-of-N honesty.
  • Failure Mode: Collusion or coercion of all members.
  • Example: Early Celestia and Polygon Avail used DACs as a stepping stone.
1-of-N
Trust Model
~$0
Slashable Stake
02

The Economic Abstraction Trap

DACs abstract away cryptoeconomic security (staking, slashing) for speed and low cost. Members are often known entities (VCs, foundations) with reputation, not stake, on the line. This creates misaligned incentives and a regulatory attack surface.

  • Incentive Misalignment: No skin-in-the-game via slashing.
  • Centralization Vector: Committee selection is a permissioned, off-chain process.
  • Comparisons: Contrast with EigenDA's restaking or Celestia's rollup-centric sampling.
0%
Slashable
High
Regulatory Risk
03

The Data Withholding Endgame

The core failure mode is data withholding. A malicious DAC can sign availability for data they never publish, creating an invalid but 'verified' state. Users and bridges (like LayerZero, Axelar) must then trust the light client verifying DAC signatures, which itself may be centralized.

  • Critical Flaw: Signatures ≠ Data Availability.
  • Propagation Risk: Compromised light client leads to chain halt.
  • Architectural Debt: Becomes a permanent trusted setup if not migrated to full DA layers.
100%
Chain Halt Risk
Trusted
Light Client
04

The Validium vs. Volition Tradeoff

DACs are the backbone of Validium scaling solutions (e.g., StarkEx, zkPorter). Here, the tradeoff is explicit: ~10,000 TPS and low fees vs. accepting the DAC's security model. Volition architectures (like StarkNet) let users choose per-transaction between DAC (Validium) and on-chain DA (ZK-Rollup).

  • Throughput: ~10,000 TPS vs. ~100 TPS for full rollups.
  • User Choice: Volition models shift risk assessment to the user.
  • Market Reality: High-value assets (>$1M) will likely avoid DAC-based chains.
10,000+
TPS
User's Choice
Risk Profile
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
The Hidden Centralization of Decentralized Data Availability Committees | ChainScore Blog