Skip to content
Financial Context Wiki

Data Availability Committee (DAC) risk

A verification-first guide to DAC attestations, q-of-n acceptance rules, actual data possession and retrieval, correlated failure domains, key rotation, retention, fallback and exit risk.

Updated

For educational purposes only; not investment or security advice. A DAC certificate can satisfy contract rules while data custody, retrieval, governance, fallback, recovery or exit still fails.

Direct answer

A Data Availability Committee is a bounded set of members whose signatures or attestations can satisfy a protocol’s rule for accepting an off-chain data-availability claim. The certificate proves only that the configured keyset and threshold accepted a specific signed object under those rules. It does not independently prove that every signer fetched the complete bytes, retained a durable copy, serves users now, validated execution or made settlement final.

Safety and liveness are different. If the contract accepts q-of-n signatures, control of q valid keys may satisfy that acceptance rule for an unavailable object unless another check prevents it. Fewer than q willing and reachable signers normally cannot form a new certificate, so updates stop or use a documented fallback. Actual recovery also depends on honest pre-signing checks, independent copies, retention, serving capacity, key and governance history, and executable reconstruction and exit software.

How it works

  1. Pin the deployment: chain, protocol mode and version, settlement and availability-verifier contracts, batch and data object, encoding, commitment, keyset, threshold q, member count n, mandatory signers, activation, expiry, revocation and governance authority.
  2. Reconstruct the exact signed claim and acceptance logic. Verify domain, chain and contract binding, batch identifier, commitment or state root, expiry, signer bitmap or aggregation, replay protection and the contract’s actual threshold calculation. A member logo or API response is not the acceptance rule.
  3. Require every member to fetch the complete object before signing, verify its commitment and encoding, decode it and preserve the data needed for independent state derivation or user exit. Record what members attest and whether the protocol can prove that these checks occurred.
  4. Map independent failure domains instead of counting names. Identify legal entities, beneficial control, cloud accounts and regions, DNS and networking, software and database stacks, key custody, storage backends, operations and jurisdiction. Mirrors or endpoints behind one control plane are not independent members.
  5. Test possession and retrieval. Fetch recent and historical batches from multiple members without the operator’s API, verify hashes and roots, reconstruct state or a withdrawal proof, measure retention and egress, and distinguish certificate production, present retrieval, execution validity, consensus finality and archival durability.
  6. Exercise lifecycle and recovery: member and key rotation, historical keysets, expiry and revocation, fewer-than-threshold availability, threshold-key compromise, selective serving, operator outage, fallback to full data, freeze or escape mode, forced inclusion, independent archives and the actual gas and time needed to exit.
  7. Monitor accepted signer bitmaps, certificate delay, retrieval success, byte integrity, storage age, keyset and threshold changes, upgrades, pauses and fallback capacity. Archive certificates, data and contract state, and stop adding exposure when certificates are accepted but independent retrieval or recovery no longer works.

Worked examples

  • Threshold liveness and safety are not the same. In a toy 5-of-7 committee, two unavailable members leave 5 signers and a new certificate can still form; three unavailable members leave 4, so 4 < 5 and certificate production stops unless a documented fallback applies. Conversely, control of 5 accepted keys can satisfy the threshold rule; the certificate still does not prove present byte retrieval or execution validity.
  • Independent-online model. Assume, only as an IID toy model, that each of 7 members is independently available with probability 0.95 and a certificate needs at least 5. Then P(quorum) = sum(C(7,k) * 0.95^k * 0.05^(7-k), k=5..7) = 0.9962429570, so modeled stall probability is 1 - 0.9962429570 = 0.0037570430. Shared cloud, software, operator, legal or key dependencies invalidate this binomial estimate.
  • Storage copies and serving are separate. A batch is 120 MB. Seven full independent copies would store 120 * 7 = 840 MB; if only three members actually persist it, stored bytes are 120 * 3 = 360 MB even if five keys signed. Serving the object once to 100 clients transfers 120 * 100 = 12,000 MB, so a signature count is neither a copy count nor an egress-capacity measure.
  • Reconstruction threshold. A toy object has 1,024 records split into 16 chunks of 64 records, with a stated recovery threshold of 12 chunks. Eleven chunks expose 11 * 64 = 704 records, but 11 < 12, so the object cannot be reconstructed under that rule. A valid committee certificate cannot replace a missing chunk or change the recovery threshold.

Risks

  • Inspecting the wrong chain, contract, deployment, batch or protocol version.
  • Reconstructing the wrong signed claim, domain, commitment or expiry.
  • Accepting replay across chains, contracts, versions or historical keysets.
  • Using an invalid, stale, expired or revoked keyset.
  • Misreading q, n, mandatory signers, bitmaps or aggregate signatures.
  • Exploiting a signer or contract-verification implementation bug.
  • Signing before complete data fetch, integrity checking and persistence.
  • Accepting partial, malformed or wrongly encoded data.
  • Losing safety through compromise or collusion of threshold keys.
  • Losing liveness because fewer than threshold members can sign.
  • Counting correlated entities, clouds, regions or operators as independent.
  • Sharing DNS, TLS, software, databases or storage control planes.
  • Suffering eclipse attacks, selective service or private-gateway dependence.
  • Deleting or pruning data after signing or before the exit window ends.
  • Breaking historical retrieval through member churn or key rotation.
  • Letting governance replace members, lower the threshold or bypass delay.
  • Referencing a stale, unsafe or reorganized settlement commitment.
  • Treating a validity proof or finalized root as current data retrieval.
  • Discovering that fallback, freeze, forced inclusion or exit is not executable.
  • Underestimating storage, egress, recovery, fallback, fee and capacity costs.

Common misconceptions

  • More committee members automatically mean more independent failure domains.
  • q signatures prove q durable full copies exist and are publicly retrievable.
  • A validity proof removes the need to verify DAC data availability.
  • An old valid certificate guarantees current retrieval and permanent archiving.
  • One honest or official member guarantees that every user can always exit.

Sources

Navigation

Search the wiki...