Data Availability Committee (DAC)

A Data Availability Committee (DAC) is a permissioned set of known, often reputable, entities that cryptographically attest—typically by signing—that the data for a rollup's transactions has been published and is available for a sufficient period. This model is a pragmatic alternative to posting all data directly to a base layer like Ethereum, which is secure but expensive. By relying on a committee's signatures, the system can operate with the assumption that the data can be retrieved if needed for fraud proofs or to reconstruct the chain state, thereby reducing transaction costs while maintaining a high security threshold.

The core function of a DAC is to bridge the data availability problem. In optimistic rollups, for a fraud proof to be challenged, the full transaction data must be accessible. A DAC provides a verifiable guarantee of this availability without requiring every byte to be stored on-chain. Members store copies of the data and periodically commit Merkle roots or signatures to a smart contract. If a user needs the data to submit a fraud proof, they can request it from any committee member. This structure is central to validium and certain zk-rollup architectures, which prioritize extreme throughput and low fees.

While efficient, the DAC model introduces a distinct trust assumption compared to purely on-chain data availability. Security depends on the honesty and liveness of a majority of committee members. If the committee were to collude or become unavailable, users might be unable to challenge invalid state transitions or withdraw their assets. To mitigate this, implementations often feature robust incentives, slashing conditions for misbehavior, and mechanisms to progressively decentralize the committee over time. This trade-off is explicitly chosen to achieve scalability characteristics that pure Layer 1 settlement cannot provide.

Prominent examples of DAC usage include StarkEx's validium mode (e.g., as used by dYdX and Immutable X) and early versions of Arbitrum Nova. In these systems, the DAC acts as a high-performance data layer, while the base chain (Ethereum) secures asset custody and verifies state commitment proofs. The evolution of data availability sampling (DAS) and dedicated data availability layers like Celestia and EigenDA represents a shift towards trust-minimized, scalable data availability without relying on a permissioned committee, addressing the same core scaling bottleneck.

A Data Availability Committee (DAC) is a permissioned, multi-party system designed to solve the data availability problem for certain Layer 2 (L2) rollups. Instead of publishing all transaction data directly to the underlying Layer 1 (L1) blockchain, the rollup operator submits only a cryptographic commitment (like a Merkle root) to the L1. The raw data is then transmitted and stored off-chain by the members of the DAC. Each committee member cryptographically signs an attestation confirming they have received and are storing the data, and these signatures are posted to the L1. This provides a verifiable guarantee that the data exists and can be retrieved if needed.

The core mechanism relies on a threshold signature scheme. For a rollup's state to be considered finalized and for users to be able to withdraw funds, a pre-defined quorum (e.g., 4 out of 7 members) must sign off on the data's availability. This model significantly reduces L1 transaction costs compared to posting all data on-chain, as only small signatures are published. However, it introduces a trust assumption: users must trust that the committee members are honest and will not collude to withhold data. This is a key differentiator from validiums, which use DACs, and optimistic rollups or zk-rollups, which typically post data directly to the L1 for stronger security guarantees.

A DAC's operational workflow is continuous. For every new batch of L2 transactions, the sequencer sends the data to all committee members. Each member independently verifies the data's integrity against the commitment posted on the L1. Upon successful verification, they contribute their partial signature to a collective attestation. If a user or a verifier needs to challenge a transaction or construct a fraud proof, they can request the data directly from any honest committee member. Prominent implementations of this model include StarkEx's "Data Availability Committee" (often used by dYdX and ImmutableX) and Polygon Avail, which itself can function as a DAC for other chains.

The security model of a DAC involves careful selection of members, who are typically well-known and reputable organizations in the ecosystem to bootstrap trust. Slashing conditions or bonding mechanisms can be implemented to financially penalize members who fail to provide data upon request or who sign for unavailable data. While more centralized than pure L1 data availability, a well-designed DAC offers a pragmatic balance for applications requiring very high throughput and low fees where the full cost of on-chain data is prohibitive. It is a stepping stone technology between centralized solutions and fully trustless, on-chain data availability layers.