/data-availability-enforcement

name: "data-availability-enforcement"
description: "L1 supplement - audits storage / data-availability chains (Arweave / Celestia-class) for unenforced data commitments: producer commits to data inclusion but the validator never verifies the data was actually published / gossiped / sampled."

Injectable Skill: Data Availability Enforcement

> **L1 trigger**: `L1_PATTERN=true` AND protocol-type is one of: storage, data_availability, da_chain, da_layer, blob_storage. Detection: recon finds a "publish ledger", "data root", "blob commitment", "DA root", or "ingress proof" structure in the block header AND the protocol's economic model assumes miners store data. > **Inject Into**: `depth-consensus-invariant`, `depth-state-trace` > **Language**: Go and Rust > **Finding prefix**: `[DA-N]` > **Status**: v0.1 — derived from a prior DA-chain audit post-mortem

When This Skill Activates

Data availability chains are L1s whose primary function is to commit to and serve user data, not just to settle transactions. Examples: Arweave (permanent storage), Celestia (rollup blob DA). The trust model is fundamentally different from settlement L1s: validators must enforce that **committed data is actually available**, not just that the commitment is well-formed.

The single most common DA-chain bug class is: **the block header carries a commitment to data X, the producer is paid for committing to X, but nothing in the protocol forces the producer to actually publish X.** Honest miners assigned to store X cannot, get penalized, and the chain becomes unreliable.

1. Commitment Inventory

Enumerate every block-header field that commits to data the protocol expects to be stored elsewhere:

• "Publish ledger" / "Submit ledger" / "DA root" / "blob commitment" / "data root"
• "Ingress proof root" / "chunk merkle root"
• "Replication committee assignments" / "partition assignments"

For each, identify: 1. The exact field path in the block header struct 2. The economic action attached to inclusion (reward, partition assignment, slashing trigger) 3. The set of actors expected to store the committed data after inclusion

Write the inventory to `scratchpad/da_commitment_inventory.md`.

2. Availability Check Audit

For EACH commitment in the inventory, the validator must enforce that the data is actually available. Three valid mechanisms:

2a. Sample-and-prove (Celestia / DAS)

• Validator picks K random chunks of the committed data
• Verifies each chunk's Merkle proof against the committed root
• Accepts only if all K chunks return valid proofs within timeout
• **Check**: random chunk selection (not attacker-influenceable), K large enough for security target, timeout bounded

2b. Full retrieval (Arweave-style)

• Validator downloads the entire committed data from a peer claiming to host it
• Hashes and compares against the commitment
• **Check**: peer selection is permissionless (not just from producer's peer list), retrieval timeout bounded, fallback to multiple peers

2c. Attestation from N peers (Filecoin-style)

• N independent peers attest they have the data (signed messages)
• Validator collects ≥ threshold attestations before accepting the commitment
• **Check**: attestation threshold ≥ Byzantine fraction + 1, attesters are sybil-resistant, no producer-attesting

If NONE of these mechanisms exists for a commitment → **CRITICAL finding**. The producer is paid for a commitment with no enforcement. Honest miners assigned to store the data can be poisoned.

Tag: `[DA-COMMITMENT-NO-AVAILABILITY:{ledger-name}]`

2d. Merkle Proof Primitive Audit

Whenever the DA flow relies on `validate_path`, `verify_proof`, `validate_chunk`, or any Merkle-style helper, audit the verifier itself rather than trusting that the caller used it correctly.

Questions: 1. **Leaf binding**: does the proof chain the claimed leaf all the way to the committed root, or does it only compare a caller-supplied hash at the end? 2. **Length bounds**: before slicing / advancing the proof buffer, does the verifier assert enough bytes remain? 3. **Range binding**: if an offset chooses left vs right branch, does the same offset also prove the queried chunk is in-range for that branch? 4. **Operator direction**: where the proof combines offset and hash checks, are `&&` and `||` used with the intended meaning?

Tag: `[DA-MERKLE-PROOF:{function}]`

3. Gossip-Path Trace

For each committed data root, trace the gossip handler that is expected to deliver the actual chunks to other peers. The validator side does NOT replace gossip — both must exist:

1. Find the producer-side function that broadcasts the data after inclusion (e.g., `gossip_chunks_for_data_root`) 2. Verify the function is called UNCONDITIONALLY after the producer's block is accepted, not just on best-effort 3. Verify the receive-side handler stores the chunks AND signals success to the validator's availability check 4. **Common bug**: producer broadcasts on its own initiative (no protocol enforcement), but if it doesn't, no consequence — validators never check

Tag: `[DA-GOSSIP-NOT-ENFORCED:{handler-path}]`

3a. Publish-Ledger Gossip Duty Matrix

For each ledger / blob / chunk class whose availability depends on peer-side replication, write a row:

| Data class | Publisher | Required recipients | Gossip trigger | Validator check | Penalty on missing gossip | Evidence | |------------|-----------|---------------------|----------------|-----------------|---------------------------|----------|

Required enumeration: 1. Identify every publish-ledger or data-ledger field that creates an obligation for a producer or relay to gossip bytes after block acceptance. 2. Locate the exact trigger that sends the bytes. A best-effort background task is not enforcement unless block validity, reward, or reputation depends on success. 3. Locate the verifier or challenge that detects missing gossip before honest assigned peers are penalized for not storing