Pull the exact bytes of a batch, re-derive the commitment and replay the transition yourself instead of taking a sequencer's word for it. Each class splits into 65,536-byte chunks whose hashes bind the batch number, chunk index, class and offset, so a chunk only verifies in the position it was committed at. Guarantors that claim to hold a batch answer challenges on sampled chunks. This path is not yet qualified for runtime evidence.

What it does

Every Paxeer X batch commits a data availability root over five classes of batch data: activities, receipts, oracle inputs, the state diff and recovery metadata. The root is built from ordered chunk hashes, each bound to its batch number, chunk index, class and offset, so a served chunk can only verify in the position it was committed at. Nodes serve individual chunks with a Merkle path back to that root, and a retrieving client re-hashes the bytes it receives before accepting them. Guarantors that attest to holding a batch can be challenged on randomly sampled chunks, and a failed challenge is slashable.

Key capabilities

• Commits activities, receipts, oracle inputs, state diff and recovery metadata under one availability root.
• Splits each class into 65,536-byte chunks whose hashes bind batch, index, class and offset.
• Serves any chunk with its inclusion proof against the committed availability root.
• Re-verifies the stored bundle on every fetch and withholds the capability when it is missing or corrupt.
• Samples challenge chunk indices from the checkpoint hash, making an unanswered challenge slashable.
• Refuses further finalisation after data loss while keeping emergency exit valid.

Differentiators

Chunk hashes are metadata-bound rather than plain content hashes, so a chunk cannot be substituted from another position or class. Retrieval re-verifies the stored bundle independently instead of trusting the serving node. Data loss behind an unfinalised checkpoint refuses finalisation; loss behind a finalised checkpoint keeps emergency exit valid and halts further finalisation.

Outcomes

• Reconstruct LayerX state without trusting the node that serves it
• An unanswered challenge is slashable for the attesting guarantor
• Data loss stops further finalisation and keeps emergency exit valid

Technical notes

• Canonical chunk size is 65,536 bytes; a bundle holds at most 4,096 chunks. Batch bodies are capped at 16,777,216 bytes and 65,535 activities, with a 354-byte batch header.
• Retrieval is selector-driven: by checkpoint id, batch number, inclusive sequence range, activity id, or sealed candidate batch. Selectors 01 to 04 refuse batches newer than the latest finalised batch; the sealed-candidate selector permits them but is never finality evidence and is limited to the same authenticated principal set as the batch-header request.
• Each response carries the exact chunk bytes plus proof material holding the batch number, chunk index, class, class offset, chunk hash, leaf index, leaf count, depth and siblings.
• A resolution may cover at most eight batches, but the shipped client consumes one batch per request, so every multi-batch result is refused.
• Typed refusals include LXP_ERR_BATCH_GAP (-800) for a range extending past its resolved batch and LXP_ERR_DA_MISSING (-804) for an unavailable capability or an unfinalised candidate selected by 01 to 04.
• Served bundles live in a da directory beside the checkpoint log, with a separate da-bodies.log for independent reconstruction. LAYERX_NODE_DA_RETAIN_BATCHES defaults to 100000 and rejects values below 1024; retention preserves the newest finalised checkpoint, and with no finalised checkpoint pruning retains everything.
• A challenge samples up to 16 distinct chunk indices derived from the checkpoint hash, and is only issued against an attestation that claims possession of all five classes. The judge rejects a late, mismatched, wrongly hashed or wrongly proved response.
• Not yet qualified. The repository states that real-kernel replay fixture migration, daemon recovery and retention tests, and real-daemon selector and corruption tests must complete before build, sanitizer, daemon and Rust gates can establish runtime evidence for this path.

More in Network