Data Availability
Retrieve authenticated batch data, replay the complete transition, and preserve independent evidence through archives and mirrors.
Availability makes replay possible
Paxeer X commits batch data in a canonical five-class availability bundle. Guarantors fetch these bytes, authenticate every chunk against a signed header and independently replay the transition before attesting. An availability proof establishes committed data; replay establishes the computed result.
| Bundle class | Canonical contents |
|---|---|
| Activities | Big-endian record count followed by length-prefixed activity records |
| Receipts and events | Tagged length-prefixed records: kind-1 receipts followed by kind-2 events |
| Oracle inputs | Big-endian record count followed by length-prefixed oracle records |
| State diff | Account-ID-sorted changed account IDs and canonical post-batch leaf values |
| Recovery metadata | Settled kernel module roots, canonical account frontier and sequence/watermark values |
lxp_batch_availability_root(body, arena, root) commits ordered, metadata-bound chunk hashes. Canonical chunks contain 65,536 bytes. Activity, receipt, event and oracle record roots are independent commitments and are checked alongside bundle completeness and ordering.
Fetch and replay workflow
- Obtain and verify the signed batch header using your independently configured authority.
- Select the finalised batch or an authorized sealed candidate.
- Fetch chunks and validate their hashes, Merkle paths, class offsets, ordering and bounds against the header's commitments.
- Require complete coverage of all five bundle classes and validate the reconstructed record roots.
- Replay activities and oracle inputs through the real kernel; compare state roots and the recomputed account diff.
- Attest only after replay reaches the exact committed result.
Sealed-candidate retrieval uses layerx_client::availability::fetch_sealed_candidate with commitments from the verified tag-12 signed batch header. It applies the same chunk, class-completeness and record-root checks as finalised retrieval. Candidate retrieval does not itself make a batch finalised.
Native availability selectors
The tag-18 request carries an empty proof section and one canonical selector. Integers are unsigned big-endian. These are native protocol selectors, not HTTP route names.
| Selector bytes | Selection | Boundary |
|---|---|---|
01 || checkpoint_id[32] | The batch covered by a finalised checkpoint certificate | Finalised history |
02 || batch:u64be | One retained batch | At or before the latest finalised batch |
03 || first:u64be || last:u64be | An inclusive activity sequence range | Entire range must resolve inside one batch |
04 || activity_id[32] | The activity's batch | Finalised history |
05 || batch:u64be | A durable, sealed, header-signed candidate | Authenticated UID/GID principal authorization; may precede checkpoint registration |
Resolution has an eight-batch bound, while the client consumes one batch per request and refuses multi-batch results. Use a single resolved batch for each fetch. Unknown, incomplete, unsealed and corrupt candidates fail closed.
Chunk stream
Each tag-19 response carries exact chunk bytes as its canonical payload and this proof material:
batch:u64be || index:u32be || class:u8 || class_offset:u64be
|| chunk_hash[32] || leaf_index:u32be || leaf_count:u32be
|| depth:u8 || siblings[depth][32]Tag 20 ends the stream with empty payload and proof material. A checkpoint candidate uses the existing tag-12 signed batch header; candidate retrieval introduces no additional checkpoint-header tag.
Retention and durable recovery
LAYERX_NODE_DA_RETAIN_BATCHES defaults to 100000 and rejects values below 1024. Pruning preserves the newest finalised checkpoint. Until a finalised checkpoint exists, all bundles remain retained.
The checkpoint directory contains a header-only batch log, canonical bodies in da-bodies.log and served bundles in the sibling da directory. Prepared publication persists state diff and recovery metadata in WAL version 4 under the existing WAL byte bound. Bundle storage completes before publication completes.
Startup checks the retained interval against signed headers before advertising availability_fetch. A missing or corrupt served bundle withholds that capability. Fetch verifies stored bundles again; body-log records provide independent commitment reconstruction if a served bundle is unavailable.
Refusals and recovery
| Result | Meaning |
|---|---|
LXP_ERR_MALFORMED_ENVELOPE | Malformed selector encoding |
LXP_ERR_NON_CANONICAL | Reversed or zero-start range |
LXP_ERR_UNKNOWN_ACTIVITY | Unknown selection |
LXP_ERR_LENGTH_LIMIT | Multi-batch or over-limit resolution |
LXP_ERR_BATCH_GAP | Range extends beyond the resolved batch |
LXP_ERR_DA_MISSING | Unavailable capability or an unfinalised batch selected through selectors 01–04 |
Keep storage and proof failures as typed refusals. Retry a retained single-batch selection or restore authenticated archive data; do not treat missing chunks as an empty batch or replace a verified header with an untrusted newer one.
Ethereum and Solana mirrors
Mirror archives extend independent access to batch history. layerx-mirror-publisher publishes archives to Ethereum or Solana, while layerx-mirror-verify checks a receipt obtained from an untrusted mirror archive without a hosted gateway.
Verification validates the archive, binds its batch header to operator-configured trust, proves receipt inclusion and returns freshness. Archive provenance and freshness are separate from the receipt's signed outcome. Preserve the archive commitment, trusted header context, inclusion proof and checkpoint references for later audit.
See Receipts & Proofs for portable offline verification and native state witnesses, or Finality & Commitment for how data availability supports settlement.