Data Availability Committee (DAC)

A Data Availability Committee (DAC) is a permissioned set of trusted nodes or entities that cryptographically attest to the availability of transaction data for a layer-2 rollup or modular blockchain. In scaling architectures like validiums or certain optimistic rollups, transaction data is stored off the main chain (e.g., Ethereum) to reduce costs. The DAC's primary role is to sign attestations, often in the form of Data Availability Certificates, confirming they possess the data and will provide it upon request for fraud proofs or state reconstruction. This creates a trust assumption distinct from pure data availability sampling (DAS) used in networks like Celestia.

The operational model involves the rollup's sequencer or prover sending batch data to each DAC member. Members independently verify the data's integrity and, if valid, sign a commitment (like a Merkle root). A threshold of these signatures is then posted on the parent chain, acting as a guarantee. If a user or verifier needs the data to challenge a fraudulent state transition, they can request it from any honest committee member. This structure significantly reduces gas fees compared to posting all data on-chain, but it introduces a trust assumption that a majority of the committee remains honest and available.

Key technical components include the attestation signature scheme (e.g., BLS signatures for aggregation), the data dispersal mechanism across members for redundancy, and slashing conditions or reputational stakes to incentivize honest behavior. Prominent implementations include StarkEx's DAC for validiums and Polygon Avail's initial design. The security model is explicitly trusted-but-verifiable, sitting between purely trustless on-chain availability and entirely centralized data storage.

The primary trade-off is between cost, security, and decentralization. DACs enable high-throughput, low-cost transactions but are criticized for their semi-centralized nature, creating a potential single point of failure or censorship if the committee colludes. This contrasts with enshrined data availability layers that use cryptographic proofs and peer-to-peer networks. Consequently, DACs are often considered a pragmatic interim solution or suitable for enterprise applications where a known set of entities is acceptable, while the ecosystem evolves towards more decentralized data availability solutions.

A Data Availability Committee (DAC) is a permissioned set of reputable nodes or organizations that provide a data availability guarantee for a rollup or layer-2 blockchain. In a modular blockchain architecture, execution is separated from data availability and consensus. A DAC's primary function is to store a complete copy of the rollup's transaction data and provide cryptographic attestations—typically signatures or Merkle roots—that prove the data is available for download. This allows the underlying layer-1 blockchain (e.g., Ethereum) to verify that the data exists without needing to store it directly, significantly reducing costs while maintaining security assumptions.

The operational workflow involves the rollup's sequencer or proposer submitting batch data (the compressed transactions) to the DAC members. Each member independently verifies and stores the data, then returns a signed attestation. A predefined threshold of signatures (e.g., a majority or supermajority) is aggregated into a single proof, which is posted to the layer-1. This proof acts as a compact data availability certificate. Validators on the main chain can then trust that the data is available for the fraud proof or validity proof challenge period, enabling secure withdrawals and state resolution.

DACs represent a trusted but efficient alternative to purely on-chain data availability solutions like data availability sampling (DAS) or data availability layers. While systems like Celestia or EigenDA use cryptographic and economic guarantees with permissionless validators, a DAC relies on the collective reputation and legal accountability of its members. This model, used by early optimistic rollups like Arbitrum Nova and some zk-rollups, offers lower costs and latency but introduces a trust assumption that the committee will not collude to withhold data.

The security model hinges on the committee's honest majority assumption. If the committee fails to provide data upon request, the rollup may halt, but user funds typically remain safe due to enforced escape hatches or force withdrawal mechanisms coded into the rollup's smart contracts. The trade-off is clear: DACs provide practical, low-cost data availability for high-throughput applications, sacrificing some decentralization for performance. This makes them suitable for enterprise consortia or applications where the committee members are known, auditable entities.

In the broader ecosystem, DACs are often a transitional architecture. Projects may start with a DAC to bootstrap network effects and optimize costs before migrating to a more decentralized data availability solution as the technology matures. The core innovation is decoupling the verification of data availability from its storage, a key principle in modular blockchain design that enables scalable execution without compromising on settlement layer security.

A Data Availability Committee (DAC) is a permissioned group of trusted entities responsible for storing and attesting to the availability of transaction data for a Layer 2 (L2) rollup. This model was pioneered by solutions like Validium to provide scalable data availability off-chain while relying on a committee's cryptographic signatures—rather than on-chain publication—to guarantee that data can be reconstructed to validate state transitions or facilitate withdrawals. The core trade-off is sacrificing the pure cryptographic security of publishing all data directly on Layer 1 (L1) for significantly higher transaction throughput and lower costs, introducing a trust assumption in the committee's honesty and liveness.

The evolution of DACs is directly tied to the data availability problem, which asks: how can verifiers be sure that all necessary data for validating a block is actually published and accessible? Early optimistic and zero-knowledge rollups initially defaulted to posting all transaction data as calldata on Ethereum L1, ensuring maximum security but at a high cost. DACs emerged as a pragmatic, intermediate architecture where a known, often reputable, set of members cryptographically commits to holding the data, providing an availability attestation that the rollup's smart contracts can verify. This created a spectrum of data availability solutions, with rollups on one end (full L1 security) and Validiums with DACs on the other (scalability with trust).

The context for DACs has shifted with the development and adoption of data availability sampling (DAS) and dedicated data availability layers, such as EigenDA and Celestia. These newer systems aim to provide scalable, cryptographically secure data availability without trusted committees, using technologies like erasure coding and probabilistic sampling. Consequently, the role of the traditional DAC is evolving, with many projects viewing it as a stepping stone or a configurable option within a modular stack. Modern implementations may use a hybrid model or allow users to choose between a DAC for ultra-low cost and a pure rollup mode for high-value transactions, reflecting the ongoing innovation in the blockchain scalability landscape.