Skip to content
Financial Context Wiki

Data availability

A verification-first guide to data publication, retrievability, commitments, validity, finality, sampling, retention, archives, rollup derivation and executable recovery.

Updated

For educational purposes only; not investment or security advice. Data availability depends on protocol parameters, networks, software, operators, archives and recovery paths that can fail or change.

Direct answer

Data availability means that enough protocol-specified data are published and obtainable within the required window for the intended participants to verify, derive or reconstruct the relevant state. The required object may be transaction inputs, state differences, encoded shares or another defined batch format; it is not simply a website, RPC endpoint or project API being online.

Four claims must remain separate. Availability concerns timely publication to the protocol’s consumers. Retrievability concerns whether a particular party can fetch the bytes now or later. Validity concerns whether a state transition follows the rules or proof constraints. Finality concerns whether consensus can still replace the commitment through normal protocol operation. A binding commitment, KZG proof, validity proof or finalized inclusion does not by itself prove all four claims, and temporary availability is not permanent archiving.

How it works

  1. Define the claim before measuring it: the exact batch, blob, namespace or encoded data object; protocol and version; intended consumer; required derivation, verification or exit task; and availability, challenge and recovery windows. Complete data means sufficient data under that protocol, not an undefined copy of every transaction.
  2. Pin the publication path and evidence: settlement chain, dedicated DA chain, calldata, blob sidecar, external commitment or committee certificate; block, slot and batch identifiers; encoding and compression; commitment; and the contract or bridge that consumes it. Publication in one place is not proof that another verifier checks it.
  3. Test binding and reconstruction independently. Fetch the bytes without the project’s API, verify their hash, KZG or other commitment and inclusion reference, validate framing and erasure encoding, decode the batch and reproduce the inputs needed for state derivation. A valid commitment without bytes is not successful reconstruction.
  4. Map the acceptance model. Record whether full nodes download the object, light nodes sample authenticated shares, validators have custody duties, or a data-availability committee signs a threshold certificate. State the sampling, erasure, peer-independence, threshold, stake, key and eclipse assumptions and what the settlement or bridge contract actually verifies.
  5. Track distinct states and clocks: submitted, included, available in the protocol window, retrievable by independent clients, decoded or derived, execution-valid, safe, finalized and archived. A validity proof can establish constrained computation while data needed for independent derivation or operation remain unavailable.
  6. Measure retention, bootstrapping and economics. Record the protocol serving minimum, pruning behavior, archive and snapshot providers, new-node requirements, raw and encoded bytes, overhead, unit price, proof and transaction costs, capacity limits, subsidies and fallback costs. Long-term retrieval is an additional dependency after temporary DA expires.
  7. Rehearse failures. Test withholding, selective serving, correlated or eclipsed samples, committee loss, DA halt or fork, settlement reorganization, missing frames, archive loss, sequencer censorship and fee spikes. Verify safe halt, forced inclusion, retry, fallback, reconstruction and exit with the actual software, data and gas, then retain commitments, receipts and independent archive evidence.

Worked examples

  • Correct data-cost units. A batch contains 400,000 bytes, covers 2,000 transactions and costs $0.00002 per byte. DA data charge is 400,000 * $0.00002 = $8 per batch, or $8 / 2,000 = $0.004 per transaction. If the unit price rises tenfold to $0.00020 per byte, cost becomes $80 per batch and $0.040 per transaction, not $0.04 per batch. Execution, proof, transaction overhead, archiving and margin are excluded.
  • Protocol serving window is not an archive promise. The EIP-4844 minimum request window is 4,096 epochs; with 32 slots per epoch and 12 seconds per slot, that is 4,096 * 32 * 12 = 1,572,864 seconds, or 1,572,864 / 86,400 = 18.2044444444 days. It is a protocol minimum in this model, not a guarantee that one provider will preserve a particular blob forever.
  • Stylized sampling probability. Assume, only for a toy model, that an attacker withholds 50% of uniformly sampled expanded shares and that 30 authenticated samples are independent and sampled with replacement. Probability that all samples miss the withheld region is 0.5^30 = 0.0000000009313225746, so detection probability is 99.9999999069%. This is not a live PeerDAS or another network’s service guarantee; correlated peers, biased sampling, coding parameters and adaptive attacks change the result.
  • Committee threshold does not equal current retrieval. A hypothetical DA committee requires 5-of-7 signatures. If three members are unavailable, only 4 remain, so no new threshold certificate can be formed. An old certificate with 5 signatures proves that the threshold attested under its rules; it does not prove that a particular user can retrieve the bytes now, that execution was valid or that settlement is finalized.

Risks

  • Inspecting the wrong chain, batch, blob, namespace or protocol version.
  • Confusing a commitment or certificate with the underlying bytes.
  • Treating current retrieval from one endpoint as protocol-wide availability.
  • Treating data availability as proof of execution validity.
  • Treating availability or validity as consensus finality.
  • Referencing a stale, unsafe or reorganized settlement block.
  • Missing the protocol retention window before fetching the data.
  • Depending on one archive, snapshot, indexer or project API.
  • Accepting malformed framing, compression or erasure encoding.
  • Failing to verify the hash, KZG or other commitment.
  • Sampling too few shares for the stated threat model.
  • Assuming samples, peers or custody groups are independent when they are correlated.
  • Suffering eclipse attacks, biased peer selection or selective serving.
  • Using erasure parameters or reconstruction thresholds inconsistent with the verifier.
  • Depending on a colluding or unavailable data-availability committee.
  • Letting the bridge or settlement contract accept a weaker object than users expect.
  • Losing data through sequencer withholding, censorship or missing batch frames.
  • Encountering a DA halt, fork, reorganization or incompatible client upgrade.
  • Discovering that forced inclusion, fallback, recovery or exit is not executable.
  • Underestimating capacity, fee spikes, overhead, archive cost or subsidy expiry.

Common misconceptions

  • A validity proof removes the need for data availability.
  • A commitment or KZG proof proves that the complete bytes were obtainable.
  • Finalized inclusion means the data remain permanently retrievable.
  • On-chain, blob, dedicated-DA or sampling labels automatically provide the same security.
  • More samples or lower cost alone proves that one DA design is superior.

Sources

Navigation

Search the wiki...