Data Availability
Choose and operate the data publication layer that lets a rollup state be reconstructed.
Data availability answers whether transaction data is obtainable by the parties who need to verify or reconstruct rollup state. It is separate from execution correctness. A valid commitment or proof is not sufficient if users cannot obtain the data that explains the state transition. Ethereum's data-availability documentation explains why this is a core rollup security property, particularly for independent verification and fraud proofs.
Choose the availability model deliberately
| Model | Strength | Operational trade-off |
|---|---|---|
| Settlement-layer calldata or blobs | Strong alignment with the settlement layer. | Cost and throughput depend on the settlement layer. |
| Dedicated DA layer | Can improve throughput and cost profile. | Adds an external availability and integration dependency. |
| Operator-hosted data | Flexible for controlled environments. | Introduces a stronger operator availability and recovery obligation. |
Define the maximum acceptable publication delay, retention period, retrieval path, and user recovery procedure. Monitor data-publication success separately from local block production, and alert on missing batches, retrieval failures, and an increasing publication backlog.
Availability acceptance tests
Test availability from a consumer perspective, not only from the publisher's success response:
- Fetch recently published batches from an independent reader in a different network location.
- Reconstruct a known state range from retained data and compare its state root with the committed value.
- Simulate delayed publication and verify the sequencer, alerts, and user-facing status follow the documented policy.
- Test provider errors, rate limits, and an unavailable primary endpoint if a fallback is claimed.
- Measure retrieval time for the oldest data needed by the configured recovery objective.
Publication and recovery policy
Decide in advance what happens when publication fails. A safe policy states how many unpublished batches are permitted, who may pause sequencing, whether transactions are rejected or queued, and how operators reconcile locally produced blocks after the availability path returns. Do not let each incident invent this decision under pressure. In an OP Stack deployment, the batcher is the component that submits L2 transaction batches to L1, which makes it a separate operational dependency from the sequencer.
Back up the metadata that maps rollup blocks and state commitments to their published data locations. The availability layer may retain data while an operator loses the index that tells it which data belongs to a particular batch.