Data Availability Committee (DAC)

What Is a Data Availability Committee?

A data availability committee (DAC) is a trusted set of nodes that stores copies of Layer 2 transaction data off-chain and publishes on-chain attestations proving that the data is available. Rather than posting every transaction to the parent chain (as a standard rollup does), a system using a DAC posts only a compact certificate: a hash of the data plus aggregated signatures from committee members. Anyone who needs the underlying data can request it from the committee.

DACs exist because on-chain data availability is expensive. Storing transaction data directly on Ethereum costs gas, and even with blob transactions introduced by EIP-4844, the capacity is limited. DACs offer a tradeoff: dramatically cheaper L2 operations in exchange for trusting a small group of identified parties to keep data accessible. This makes DACs particularly attractive for high-throughput applications like gaming and social platforms where cost matters more than maximum security.

How It Works

The mechanics of a DAC follow a straightforward signing and attestation flow. The process varies slightly between implementations, but the general pattern used by systems like Arbitrum AnyTrust illustrates the core design:

1. The L2 sequencer produces a batch of transactions and sends it to all DAC members simultaneously via RPC
2. Each DAC member stores the data in its own backing store, indexed by the batch hash
3. Each member signs the (hash, expiration_time) pair using its BLS key and returns the signature to the sequencer
4. Once enough signatures are collected to meet the threshold, they are aggregated into a Data Availability Certificate (DACert)
5. The sequencer posts the DACert to the parent chain's inbox contract instead of the full data batch
6. The L1 contract verifies the correct number of signers, the aggregated BLS signature validity, and that the expiration is sufficiently far in the future

A DACert typically contains: the data hash, an expiration time, a bitmap indicating which members signed, an aggregated BLS signature, and the hash of the keyset used. Because only this compact certificate goes on-chain rather than megabytes of transaction data, the cost savings are substantial.

Threshold Requirements

Different protocols configure their DAC thresholds differently, and the choice has direct implications for both security and liveness:

Arbitrum AnyTrust uses a notably high threshold: N-1 of N signatures. The reasoning is that if N-1 members promise data access, and at least 2 members are honest, then at least one honest member must be among the signers and will serve the data. This creates an "honest minority" assumption (only 2 of N need to be honest), which is a weaker trust requirement than the honest majority assumption used by most other DAC designs.

Fallback to Rollup Mode

Some DAC-based systems include a critical safety mechanism: if the sequencer fails to collect enough DAC signatures within a timeout window (typically a few minutes), it falls back to full rollup mode and posts the complete data directly to the parent chain. Arbitrum AnyTrust implements this fallback, ensuring that a committee outage degrades to higher cost rather than a complete halt. Pure validium designs typically lack this fallback.

DACert Structure

The on-chain certificate is compact enough to fit in a single transaction:

// Simplified DACert structure
{
  dataHash:       bytes32,   // Hash of the off-chain data batch
  expirationTime: uint64,    // Must be ≥ 2 weeks in the future
  signerBitmap:   uint256,   // Bitmap of which members signed
  aggregateSig:   bytes,     // BLS aggregated signature
  keysetHash:     bytes32    // Identifies the active committee
}

DAC vs Other DA Solutions

Data availability exists on a spectrum from fully trusted committees to fully trustless on-chain posting. Understanding where DACs sit on this spectrum helps evaluate the security tradeoffs:

The security hierarchy from weakest to strongest DA guarantees is: permissioned DAC (no slashing), proof-of-stake DAC (committee with slashing), decentralized DA layers (Celestia, Avail, EigenDA), and full on-chain DA (Ethereum blobs or calldata).

For a deeper analysis of how rollup architectures compare across these tradeoffs, see the research article on rollup vs state channel scaling tradeoffs.

Use Cases

Validium Chains

The most common use of DACs is in validium architectures. A validium uses validity proofs (like a ZK-rollup) to verify state transitions but stores transaction data off-chain with a DAC rather than posting it to Ethereum. StarkEx-based platforms like Immutable X and the earlier version of dYdX (v3) used this model to achieve high throughput for trading and NFT operations while keeping costs low.

AnyTrust Chains

Arbitrum's AnyTrust protocol is a hybrid model where the chain normally operates with a DAC but can fall back to full rollup mode. Arbitrum Nova used this architecture to serve gaming and social applications that generate high transaction volumes. The DAC kept fees low during normal operation, while the rollup fallback provided a safety net if the committee became unavailable.

Application-Specific L2s

Frameworks like Polygon CDK and Arbitrum Orbit allow developers to launch custom app chains with configurable DA options. Teams building gaming platforms, social networks, or other high-volume applications can start with a DAC for low costs and later migrate to a decentralized DA layer or on-chain blobs as the ecosystem matures.

Why It Matters

DACs represent an important point on the blockchain scaling spectrum. They demonstrate that not every application requires the same level of data availability guarantees. For many use cases, the marginal security provided by fully on-chain DA does not justify the cost increase, especially for applications handling small-value transactions at high frequency.

However, the trend in the industry is moving away from pure permissioned DACs. As on-chain DA becomes cheaper (through upgrades like EIP-4844 and proto-danksharding) and decentralized DA layers offer competitive pricing with stronger security, the niche for DACs is narrowing. Arbitrum Nova's transition to full rollup mode using Ethereum blobs in 2026 illustrates this shift: the cost advantage of DACs has diminished enough that the security tradeoff is harder to justify. For Bitcoin-based Layer 2 solutions, the data availability question takes a different shape since Bitcoin lacks native smart contract verification, leading to alternative approaches like client-side validation and statechains.

Risks and Considerations

Committee Collusion

The fundamental risk of any DAC is that committee members can collude to withhold data. If a quorum of members refuses to serve data, users cannot construct the Merkle proofs needed to prove their balances and execute withdrawals through the escape hatch. This can effectively freeze user funds, a catastrophic failure mode that does not exist with on-chain DA.

Ransom Attacks

Security researcher Justin Drake documented a specific attack vector for StarkEx validiums: an attacker who compromises enough DAC signing keys can advance the system state using hidden transactions, then extort users by processing withdrawals only in exchange for a bribe. DAC members typically use hot signing keys, which are difficult to secure against sophisticated attackers.

No Cryptoeconomic Penalties

Unlike proof-of-stake validators or restaking operators, traditional DAC members face no slashing penalties for misbehavior. Their incentive to behave honestly comes from reputation alone. This contrasts with decentralized DA layers where operators stake capital that can be destroyed if they withhold data.

Small Committee Sizes

Most DACs consist of 5 to 10 members, many of whom are entities already associated with the protocol (such as the rollup operator, its investors, or infrastructure partners). L2BEAT, a Layer 2 risk assessment platform, flags projects with fewer than 5 external DAC members as having elevated risk that a small set of entities could collude with the proposer to finalize an unavailable state.

Data Expiration

DAC members store data with expiration times, typically a few weeks. After expiration, the data may no longer be retrievable. While this is usually sufficient for dispute resolution (which has its own challenge period), it means historical data access depends on archival services rather than on-chain permanence.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.