Sequencing & Finality
Follow an activity from deterministic ordering through independent replay, bonded attestation, and Paxeer settlement.
Paxeer X combines the LayerX activity execution plane with Paxeer custody and settlement. The sequencer orders activities into signed batches; replicas preserve history; bonded guarantors independently reproduce results; Paxeer registers checkpoint evidence. A normal payment or agent action does not require a separate settlement-chain transaction.
Global ordering and signed batches
Admitted activities receive contiguous global sequence numbers. A batch begins immediately after the previous batch’s last sequence and extends the state-root chain. A sequence gap, a reversed range, or a mismatched previous root refuses the batch. Account sequences enforce each actor’s own ordering alongside the network-wide sequence.
| Header commitment | Fields |
|---|---|
| Protocol and network | protocol_version, network_id, epoch |
| Ordered range | batch_number, first_sequence, last_sequence |
| State transition | previous_state_root, resulting_state_root |
| Execution evidence | activity_merkle_root, receipt_merkle_root, event_merkle_root |
| Reconstruction inputs | data_availability_root, oracle_root |
| Time and signer | Batch timestamp and sequencer_id; the native header stores time in timestamp_ms. |
The canonical header contains exactly these 15 fields and is signed by the key bound to the authorized sequencer identity. Batch time is the only time consulted during execution. Protocol-3 batches append a batch-maintenance/v1 receipt and a batch-maintenance-effects/v1 event leaf after activity leaves, including an empty effects frame when no maintenance module is enabled.
The L0–L4 finality ladder
| Level | Evidence | Responsibility |
|---|---|---|
| L0 · Accepted | The ordered activity has a receipt chained to its state root. | Sequencer inclusion and ordering. |
| L1 · Sealed | The signed batch fixes ordering and committed roots. | Sequencer liveness and replica preservation of sealed bytes. |
| L2 · Distributed | The batch and availability bundle reach independent guarantors. | Availability of the material needed for replay. |
| L3 · Attested | Bonded guarantors attest byte-identical replay results. | Guarantor bonds and slashing for conflicting attestations. |
| L4 · Settled | The checkpoint is registered on Paxeer. | Paxeer custody with challenge windows, withdrawal limits, and emergency exits. |
L0–L1 delivers the fast execution path. L2–L4 carries the same history into independently attested settlement evidence. A receipt’s existence does not imply L4 settlement. Guarantor signatures are bonded execution attestations, not a zero-knowledge validity proof.
Guarantor replay and checkpoint formation
- Retrieve the complete batch body: activities, receipts, events, oracle inputs, state-diff material, and recovery metadata.
- Verify actor, grant, oracle, and sequencer signatures.
- Replay from the previous state root using the committed protocol and parameters.
- Recompute every committed root and compare the canonical results byte for byte.
- Sign the identical checkpoint certificate only when replay and availability checks succeed.
- Register the configured threshold of eligible attestations on Paxeer.
Any disagreement withholds the signature and produces a dissent identifying the first divergent global sequence. Attesting also asserts possession of the availability material. Signatures from under-bonded, removed, or unresolved-slashing guarantors do not count. If the threshold is absent by the deadline, the prior finalised checkpoint remains the settlement anchor.
Domain-separated signatures
Certificates and attestations use the distinct domains LXP/v2/checkpoint-certificate and LXP/v2/guarantor-attestation, each with its terminating zero byte. Native, wire, and Solidity domain definitions agree byte for byte. Attestation freshness is evaluated against the shared header-relative window.
Public commitment levels
Submission uses the exact names executed, batched, and finalised. These are evidence requirements alongside the lifecycle ladder.
| Requested level | Required evidence |
|---|---|
executed | A verified canonical receipt for the submitted activity. |
batched | Execution evidence plus an authenticated receipt proof whose canonical value exactly matches the receipt. |
finalised | Batch evidence plus finalised checkpoint evidence whose canonical header exactly matches the proof’s signed batch header. |
The gateway never downgrades the requested assurance. If its bounded wait cannot establish the requested commitment, it returns pending error -32001. Preserve the original signed activity and recover through lx_getActivityStatus, lx_getReceipt, and the required proof reads. An acknowledgement, HTTP 202, or activity identifier alone is not an executed receipt. The accepted spelling is finalised.
Data availability and recovery
A state root without its reconstruction material is insufficient. Retrieval must re-hash to the committed availability roots. Failed availability challenges are slashable. Missing data before finalisation prevents finalisation; loss behind a finalised checkpoint halts further finalisation while preserving emergency-exit eligibility.
After a crash, recovery reads the durable log head, loads a usable snapshot, replays committed records, compares roots, and rebuilds disposable projections. Native recovery is exposed through lxp_sequencer_recover with snapshot-load, record-replay, and projection-rebuild callbacks.
Equivocation and sequencer handover
Two different signed batches at one batch number, or two activities at one global sequence, provide equivocation evidence. The later conflicting batch is refused and checkpoint eligibility at that height stops. Loss of the sequencer stops new ordering; governance explicitly authorizes the replacement through handover activity 0x00070009. Native interfaces include lxp_sequencer_equivocation_detect, lxp_sequencer_loss, and lxp_sequencer_handover_authorize.
The Paxeer custody boundary
Paxeer contracts consume finalised checkpoint certificates, membership or balance proofs, withdrawal nullifiers, guarantor signatures and bonds, challenge-window state, and emergency-exit eligibility. Economic rules for orders, service delivery, escrow, and ordinary transfers execute in LayerX. Deposits credit against proven finalised custody facts. Withdrawals debit LayerX first and pay on Paxeer at most once.
If Paxeer is unreachable, ordinary LayerX execution continues. Checkpoint registration, Paxeer payouts, and finalisation of disputes or emergency exits wait for settlement connectivity. Applications should choose their commitment requirement according to the value and reversibility of the action they release.