Data Availability Committee (DAC)

A Data Availability Committee (DAC) is a cryptographic and economic construct designed to solve the data availability problem in scaling solutions like validiums and certain optimistic rollups. Instead of posting all transaction data to the base layer (e.g., Ethereum L1), the rollup submits only a cryptographic commitment (like a Merkle root). The DAC, composed of reputable and often staked nodes, then signs attestations that the full data is available off-chain and can be provided upon request. This drastically reduces on-chain data costs while maintaining security assurances for users.

The core function of a DAC is to provide a cryptoeconomic guarantee of data availability. Members typically run a node that stores the complete data and provide Data Availability Attestations (DAAs), which are cryptographic signatures confirming they hold the data. If a user needs to challenge a state transition or withdraw funds, they can request the data from any committee member. Failure by the committee to provide the data would be a provable fault, allowing for slashing of members' stakes or triggering a fallback to a more secure, full-data-on-chain mode.

DACs represent a trusted but permissioned model, contrasting with data availability layers like Ethereum itself or dedicated data availability (DA) networks (e.g., Celestia, EigenDA) which are trust-minimized and permissionless. The security of a DAC-based system depends on the honesty and liveness of its members, making member selection, legal frameworks, and stake slashing conditions critical. They are a pragmatic solution for applications prioritizing ultra-low transaction fees where the trust assumptions of a known committee are acceptable.

In practice, a DAC's operation involves a continuous cycle: 1) The rollup sequencer generates a batch and its data root, 2) The data is distributed to all DAC members via a peer-to-peer network, 3) Members validate and sign an attestation, 4) The attestation is posted on-chain alongside the state root. Projects like StarkEx (with its DAC for Validium) and Polygon Miden have implemented DACs. Their role is often transitional, with many ecosystems planning to migrate to fully permissionless DA solutions as the technology matures.

A Data Availability Committee (DAC) is a permissioned, off-chain group of reputable entities—often including exchanges, foundations, or institutional validators—that collectively guarantees the availability of transaction data for a rollup or layer-2 network. Instead of posting all transaction data directly to a base layer like Ethereum, the rollup submits only a cryptographic commitment (e.g., a Merkle root). The DAC members individually sign attestations confirming they have received and are storing the complete data blob, making it available for anyone to download and verify the rollup's state transitions. This model significantly reduces on-chain data costs while relying on the committee's honesty.

The core operational flow involves a sequence of cryptographic promises and verifications. When a rollup sequencer produces a new batch of transactions, it generates the data and sends it to all DAC members. Each member verifies the data's integrity against the posted commitment and, if correct, provides a cryptographic signature attesting to its availability. These signatures are aggregated into a single multi-signature or threshold signature that is posted on-chain. Users and light clients can then trust that the data is available because a sufficient number of trusted parties have attested to it, without needing to download the data themselves.

This trust model introduces a distinct security assumption compared to pure cryptographic methods like data availability sampling (DAS). Security depends on the assumption that at least one honest DAC member will make the data public if others withhold it. To mitigate centralization risks, DACs are often designed with economic incentives, slashing conditions, and a diverse, geographically distributed membership. A prominent example is the Arbitrum AnyTrust chain's configuration, which uses a DAC to achieve lower fees while allowing users to fall back to the fully secure, data-on-chain Arbitrum Rollup if the committee fails.

The primary trade-off is between cost, decentralization, and security. DACs enable extremely low transaction fees by minimizing on-chain data footprints, making them suitable for high-throughput applications. However, they represent a trusted setup, as users must rely on the committee's continued honesty and liveness. This contrasts with validiums, which use cryptographic proofs and a decentralized network of attestors, and zkRollups, which typically post data availability directly to Layer 1. The choice between these models depends on the application's specific security requirements and cost constraints.

In practice, interacting with a DAC-based chain is seamless for end-users. Wallets and applications query the committee's attested data availability proofs transparently. Developers must integrate with the specific DAC's APIs to ensure their applications can retrieve the necessary off-chain data for fraud proofs or state verification. The evolution of DACs includes trends toward cryptoeconomic security models, where members stake collateral that can be slashed for malfeasance, and hybrid models that combine committee assurances with light-client sampling for enhanced robustness.

A Data Availability Committee (DAC) is a trusted, permissioned group of entities responsible for storing and attesting to the availability of transaction data for a blockchain scaling solution, most commonly a validium or a volition. Unlike rollups, which post all transaction data to a base layer like Ethereum, DAC-based systems only post cryptographic proofs (e.g., zk-SNARKs or zk-STARKs) to the chain. The committee's primary role is to sign cryptographic attestations that the underlying data is available off-chain, enabling light clients to verify data availability without downloading the entire dataset. This model represents a significant trade-off, sacrificing the pure cryptographic security of on-chain data availability for substantially higher transaction throughput and lower costs.

The evolution of DACs is a direct response to the data availability problem in scaling. While rollups solve this by using the base layer as a robust data availability layer, their scalability is ultimately bounded by that layer's capacity. DACs emerged as a pragmatic alternative for applications where ultra-low cost is paramount and a degree of trust in a reputable committee is acceptable. Early implementations, such as those proposed by StarkWare for StarkEx validiums, formalized the DAC model. Committee members are typically well-known, reputable organizations (e.g., exchanges, foundations, infrastructure providers) who run nodes to store data and provide signed Data Availability Attestations (DAAs). The security assumption shifts from "trust the blockchain" to "trust the committee not to collude and withhold data."

The operational mechanics of a DAC involve several key steps. When a user submits a transaction to a DAC-secured chain, the sequencer processes it and generates a validity proof. The transaction data is then distributed to all DAC members via a peer-to-peer network. Each member independently verifies they have received and can serve the complete data, then signs an attestation to that effect. These signatures are aggregated and published on-chain alongside the validity proof. Users and light clients can verify that a threshold of trusted signatures (e.g., 5 out of 7) exists, providing assurance that the data is available for fraud proofs or state reconstruction if needed, without relying on any single member.