A Data Availability Committee (DAC) Node is a core component in a hybrid data availability model, primarily used by validium and certain optimistic rollup networks. Unlike a standard blockchain full node, a DAC node's primary function is to cryptographically sign attestations confirming it holds the complete data for a batch of L2 transactions. This committee of nodes, operated by reputable and often permissioned entities, provides a collective signature that the data is available for download, which is then posted to the base Layer 1 (L1) chain, such as Ethereum. This model offers a significant reduction in L1 gas fees compared to posting all data on-chain, while still providing a stronger availability guarantee than systems with no data posting at all.
Data Availability Committee (DAC) Node
What is a Data Availability Committee (DAC) Node?
A Data Availability Committee (DAC) Node is a specialized server operated by a trusted entity that stores and attests to the availability of transaction data for a Layer 2 (L2) rollup, providing a security guarantee between full on-chain data posting and pure cryptographic solutions.
The operational mechanics involve the sequencer or prover sending the compressed transaction batch data to each member of the DAC. Each DAC node independently verifies the data's integrity and structure before signing a data availability attestation. A predefined threshold of signatures (e.g., a majority or supermajority) is required to form a valid committee attestation. This attestation, often just a Merkle root and the signatures, is then published on the L1. Users and light clients can trust that the data is available because they trust the collective security and honesty of the committee members. The system's security relies on the assumption that the committee members are independent and that not all will collude to withhold data simultaneously.
Key trade-offs define the use of DAC nodes. The primary advantage is cost efficiency, as only tiny attestations are stored permanently on the expensive L1. However, this introduces a trust assumption—users must trust the committee members to be honest and available. This contrasts with data availability sampling (DAS) used in danksharding or validiums using validity proofs, which aim for trust-minimized security. Furthermore, DACs can face liveness risks if too many members go offline, halting the chain's ability to finalize state. Prominent examples include early implementations of StarkEx validiums and Polygon Avail before its evolution into a standalone chain, showcasing the model's role in scaling evolution.
How a DAC Node Works
A Data Availability Committee (DAC) node is a specialized server responsible for storing, verifying, and attesting to the availability of off-chain data for a Layer 2 (L2) blockchain, enabling secure and scalable transaction processing.
A DAC node is a core operational component within a Data Availability Committee framework, a scaling solution used by optimistic rollups and some validiums. Its primary function is to cryptographically commit to holding a complete copy of transaction data that is posted off-chain. Instead of publishing all data to the base layer (L1), the rollup sequencer sends data batches to the committee members. Each DAC node signs a cryptographic attestation, often a BLS signature, confirming it has received and stored the data, making this attestation available on-chain.
The operational workflow involves several key steps. First, the rollup's sequencer compresses a batch of transactions and generates a data availability certificate. This certificate, which includes Merkle roots or KZG commitments of the data, is distributed to all DAC nodes. Each node independently verifies the data's integrity and structure before adding it to its secure, redundant storage. Upon successful verification, the node contributes its signature to a collective attestation. This multi-signature is then posted to the L1 contract, serving as a verifiable proof that the data is held by the committee and can be reconstructed if needed.
This architecture provides a critical security guarantee known as data availability. If a sequencer acts maliciously and withholds data, any honest DAC member can reconstruct and publish the full dataset using their stored copy, allowing anyone to verify L2 state transitions or challenge invalid ones. The security model shifts from trusting a single entity to trusting that at least one member of the honest majority of the committee will act correctly. Compared to posting all data on-chain, this model significantly reduces gas costs and increases throughput, while offering stronger availability guarantees than a single operator model.
Implementing a DAC node requires robust infrastructure, including high-availability storage, secure key management for signing, and constant monitoring of the rollup's data pipeline. Nodes must be resilient to faults and attacks to maintain the committee's liveness. The specific technical implementation varies; some networks use a threshold signature scheme where a subset of signatures is sufficient, while others may employ more complex distributed storage protocols. The choice of committee members—often reputable entities in the ecosystem—is crucial for maintaining trust in this trust-minimized but not trustless system.
In practice, DAC nodes enable scalable applications by ensuring data is available for fraud proofs or for users to exit the rollup without relying on the sequencer. For example, in a gaming or high-frequency trading dApp on a validium, transaction details are secured by the DAC, keeping costs low while maintaining verifiability. The ongoing evolution of data availability sampling (DAS) and EigenDA represents a move towards more decentralized and cryptographically assured models, but DAC nodes remain a pragmatic and widely deployed solution for balancing scalability with security.
Key Features of a DAC Node
A Data Availability Committee (DAC) Node is a specialized server responsible for storing, attesting to, and serving transaction data off-chain, enabling scalable Layer 2 solutions like validiums and certain optimistic rollups.
Data Storage & Attestation
The core function is to securely store the full transaction data for a Layer 2 block. The node cryptographically signs an attestation (or data availability certificate) confirming it holds the data and will serve it upon request. This attestation is posted to the Layer 1, allowing the rollup's state transition to be verified without publishing all data on-chain.
Committee-Based Security Model
Security is derived from a cryptoeconomic quorum. A predefined committee of nodes (e.g., 10 of 13) must sign attestations for each block. This creates a fault-tolerant system where the compromise of a minority of nodes does not compromise data availability. Users and verifiers trust the committee's collective stake and reputation.
Data Serving Interface
When a user or verifier needs to reconstruct a state or challenge a transaction, they request the data from the DAC nodes via a standardized API (e.g., REST or RPC). The node must serve the exact data it attested to with low latency. Failure to do so is a provable fault that can trigger slashing or committee reorganization.
Contrast with On-Chain DA
This architecture is a key alternative to publishing all data directly to a Layer 1 (like Ethereum calldata).
- Cost: Drastically reduces transaction fees.
- Throughput: Enables higher transactions per second (TPS).
- Security Trade-off: Introduces a trust assumption in the committee's honesty and liveness, whereas on-chain DA is secured by the base layer's consensus.
Implementation Examples
DAC nodes are a foundational component of several major scaling solutions.
- Validiums (e.g., StarkEx applications): Always use a DAC for data availability.
- Optimistic Rollups with DAC ("Optimiums"): Can optionally use a DAC instead of posting all data to L1.
- Celestia or EigenDA: Can act as the data availability layer for which nodes provide attestations.
Operational Requirements
Running a DAC node requires robust infrastructure and operational discipline.
- High Uptime: Must be available to serve data 24/7.
- Substantial Storage: Must scale with the rollup's transaction history.
- Key Management: Secure handling of private keys for signing attestations.
- Monitoring: Continuous health checks for the node and its connection to the rollup sequencer.
Protocols Using DACs
A Data Availability Committee (DAC) is a trusted, permissioned set of nodes that attest to the availability of transaction data for a Layer 2 (L2) or modular blockchain. The following protocols implement DACs as a core component of their data availability strategy.
Common DAC Architecture
Protocols using DACs share a common technical architecture for integrating the committee's attestations.
- Core Components:
- Committee Nodes: Run by selected entities to store data and generate signatures.
- Attestation Contract: An on-chain smart contract (on L1) that verifies the committee's threshold signatures.
- L2 Sequencer: Posts compressed batch data to the DAC and submits the resulting attestation to L1.
- Security Model: Relies on the honest majority assumption of the committee members, making it more trust-dependent than pure on-chain data availability.
DACs vs. Alternative DA Solutions
DACs represent one point on the spectrum of data availability solutions, balancing cost, speed, and decentralization.
- Compared to On-Chain DA (e.g., Ethereum): DACs are ~100x cheaper but introduce a trust assumption.
- Compared to Validium: Similar trust model, but Validiums typically use a proof-of-stake style committee with slashing, whereas DACs often use a fixed, permissioned set.
- Compared to Celestia/EigenDA: These are decentralized DA layers that do not rely on a small, known committee, offering stronger cryptographic guarantees without the same trust requirements.
DACs vs. Other Data Availability Solutions
A technical comparison of key architectural and performance characteristics between Data Availability Committees (DACs), On-Chain Data Availability, and Data Availability Sampling (DAS) networks like Celestia.
| Feature / Metric | Data Availability Committee (DAC) | On-Chain DA (e.g., Ethereum Mainnet) | Data Availability Sampling (DAS) Network |
|---|---|---|---|
Core Architecture | Trusted, permissioned committee of known entities | Decentralized, permissionless blockchain | Decentralized, permissionless blockchain |
Data Availability Guarantee | Committee's cryptographic signatures (trust assumption) | Consensus-enforced, with full data on-chain | Probabilistic guarantee via light client sampling |
Throughput (Data Bandwidth) | Very High (off-chain, limited by committee nodes) | Low (constrained by base layer block size/gas) | High (scales with number of light clients) |
Latency to Finality | < 1 sec (committee attestation) | ~12 minutes (Ethereum finality) | ~1-2 minutes (block time + sampling) |
Cost per MB of Data | $10-50 (operational cost) | $1000+ (Ethereum calldata gas cost) | $1-10 (native token fee) |
Trust Model | 1-of-N honest majority (e.g., 7 of 10) | 1-of-N cryptographic consensus (e.g., 2/3 of validators) | 1-of-N cryptographic consensus + light client security |
Ethereum Integration | Off-chain service, uses EigenDA or custom contracts | Native layer 1 | Separate sovereign chain, bridges via rollups |
Data Redundancy | Replicated across committee nodes (e.g., 10x) | Replicated across all full nodes (1000s) | Replicated across all full nodes (100s-1000s) |
Security Model & Considerations
A Data Availability Committee (DAC) Node is a trusted entity responsible for storing and attesting to the availability of transaction data in a layer-2 scaling solution, acting as a security fallback to full on-chain data posting.
Core Function: Data Attestation
The primary role of a DAC node is to cryptographically sign attestations, confirming it has received and stored the complete transaction data for a new rollup block. These signatures are posted on-chain, providing a verifiable promise that the data is available off-chain for anyone to reconstruct the chain's state. This mechanism is central to fraud proof systems, as verifiers need the data to challenge invalid state transitions.
Trust Model & Decentralization Spectrum
DACs operate on a trusted, multi-party model. Security depends on the assumption that a threshold of committee members (e.g., 4 of 7) is honest and available. This is more decentralized than a single sequencer but less trustless than posting all data directly to Ethereum as calldata. The security level is configurable based on the number, reputation, and economic stake of the node operators.
Data Storage & Retrieval
Each DAC node maintains a redundant, high-availability storage system for the rollup's transaction data. They must serve this data upon request to any full node or verifier in the network. Standard protocols like Data Availability Sampling (DAS) can be used by light clients to probabilistically verify data is held by the committee without downloading it all.
Security Failure Modes
Key risks for systems relying on a DAC include:
- Collusion: If a malicious threshold of nodes withholds data or signs false attestations, the chain can stall or accept fraudulent state.
- Liveness Failure: If insufficient nodes are online to provide signatures or data, block production halts.
- Centralization Risk: The committee members become critical points of failure and potential censorship. These risks are mitigated by the fallback to posting data fully on-chain if the DAC fails.
Comparison to Validium
A Validium is a specific type of zero-knowledge rollup that uses a DAC for data availability instead of Ethereum. This trade-off drastically reduces transaction fees but introduces the trust assumptions of the committee. In contrast, a ZK-Rollup posts data to Ethereum, offering stronger security guarantees at a higher cost. The DAC node is the operational backbone of the Validium's data availability layer.
Committee Membership & Incentives
DAC nodes are typically operated by established, reputable organizations in the ecosystem. Incentives are often non-monetary (reputation, ecosystem alignment) or involve service fees. Some models implement slashing conditions or bond requirements to penalize malicious behavior. The selection process (permissioned vs. permissionless) and governance are critical to the system's overall security.
Common Misconceptions About Data Availability Committees (DACs)
Data Availability Committees are a popular scaling solution, but their architecture is often misunderstood. This section clarifies the technical realities behind common DAC misconceptions.
No, a DAC node is not a blockchain validator; it is a specialized node responsible for attesting to the availability of off-chain data, not for validating the correctness of transactions or producing new blocks. A validator's role is to execute transactions and achieve consensus on the canonical state, while a DAC node's sole function is to cryptographically sign a statement that specific data is available for download. This separation of duties allows layer-2 solutions like validiums to scale by keeping data off the main chain while maintaining a trust-minimized guarantee that the data can be retrieved to reconstruct the state if needed.
Frequently Asked Questions (FAQ)
A Data Availability Committee (DAC) is a trusted group of entities responsible for ensuring that transaction data for a Layer 2 (L2) rollup is available off-chain. This glossary answers common technical questions about DAC nodes, their role, and their security model.
A Data Availability Committee (DAC) is a permissioned set of trusted entities that collectively sign and store transaction data off-chain for a Layer 2 (L2) rollup, providing a data availability guarantee. It works by having the rollup sequencer send the compressed transaction data (the calldata) to each committee member. Each member verifies the data's integrity and signs a cryptographic attestation, often a BLS signature, confirming they have received and stored it. This aggregated signature is then posted on the parent chain (e.g., Ethereum) as proof that the data is available for download, allowing anyone to reconstruct the L2 state if needed, without storing all data directly on-chain.
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.