Checkpoints

A compact commitment to complete execution

A checkpoint commits an ordered range of LayerX activity and its resulting state to Paxeer. The checkpoint registration carries header commitments; individual activity envelopes, payloads, and receipts remain in the replayable batch and its availability material. Custody remains on Paxeer, where finalized roots become the basis for verified withdrawals and exits.

Checkpoint consumers verify the signature and domain, follow the registered checkpoint chain, verify finality, and then verify the particular receipt or state witness they need. A correctly signed candidate establishes its signer and committed bytes. Settlement additionally requires guarantor admission and the Paxeer finality rules.

What the header binds

The native anchor accepts the canonical 354-byte batch header and its 64-byte Ed25519 sequencer signature. Obtain commitments from verified canonical header bytes; copying a root from an unverified JSON response loses the signature binding.

Epochs and batches

Epoch identifies an authority lifecycle. Several batches can share an epoch. Checkpoint ordering version 2 requires a nonzero, nonregressing epoch, the next consecutive batch number, the next consecutive first activity sequence, and continuity with the finalized state root. Timestamp, signer membership, freshness, and invalidation checks also apply.

From signed candidate to settled root

1. The sequencer accepts activities, executes deterministic transitions, and issues receipts.
2. It seals the batch and signs the canonical header, fixing the activity order and committed roots.
3. Guarantors download the complete batch and availability bundle, verify signatures and authority, and independently replay every transition.
4. Guarantors recompute all committed roots and attest matching results. A mismatch withholds the attestation.
5. A submitter presents the header, signature, and guarantor certificate to the Paxeer anchor.
6. The anchor finalizes after threshold, continuity, availability, and challenge conditions clear.
7. Consumers verify finalized roots and their claim-specific witnesses before releasing custody.

Guarantor certificates and availability

A guarantor signature attests correctness and possession of the required data classes. The certificate carries the header, validity-proof field, ordered attestations, threshold, and settlement reference. The native anchor supports up to 32 attestations in ascending guarantor-identifier order. Threshold attestations are a bonded economic guarantee; they do not replace independent verification with a cryptographic validity proof.

The availability commitment covers five classes: activities and oracle inputs, tagged receipts and events, canonical state differences, and recovery metadata. Chunks use the canonical size of 65,536 bytes and bind class, ordering, and metadata. Activity, receipt, event, and oracle roots remain independent commitments, so a matching availability root alone does not establish correct execution.

Candidate retrieval

Authorized guarantors retrieve durable sealed candidates before finalization and verify completeness, chunk proofs, ordering, bounds, and record roots against the signed header. They replay before attesting. Finalized retrieval selects settled history; candidate retrieval preserves the distinction between a proposed batch and a finalized checkpoint.

Read and advance the Paxeer anchor

The checkpoint anchor is 0x0000000000000000000000000000000000001014. Its certificate is self-verifying, so any account can submit it. Read methods return both identities and status so applications can bind proofs to the intended checkpoint.

interface ICheckpointReads {
    function latestFinalized()
        external view returns (uint64 batchNumber, bool exists);
    function statusOf(uint64 batchNumber)
        external view returns (uint8);
    function finalizedStateRoot(uint64 batchNumber)
        external view returns (bytes32 stateRoot, bool finalized);
    function finalizedReceiptRoot(uint64 batchNumber)
        external view returns (bytes32 receiptRoot, bool finalized);
    function checkpointBatch(bytes32 checkpointId)
        external view returns (uint64 batchNumber, uint8 status);
}

Status 0 means unknown, 1 submitted, and 2 final. checkpoint(batchNumber) returns roots, sequence range, sequencer, signer count, availability mask, open challenges, and submitted/finalized heights. checkpointGuarantors(batchNumber) returns admitted guarantor identities in certificate order. Use the complete LayerXAnchor.sol ABI for bindings.

Challenges and bonded accountability

openChallenge(batchNumber, kind, evidenceHash) requires the challenge bond and distinguishes fraud (0) from data availability (1). Authorized resolution records whether the challenge is upheld. Open challenges prevent finalization. finalize(batchNumber) advances a submitted checkpoint only when its challenge and timing conditions permit.

Conflicting 274-byte attestations by the same guarantor for different checkpoints in one batch support submitEquivocation(evidenceA, evidenceB) and slashing. Guarantor registration, activation, bond increases, and delayed unbonding make authority and economic exposure inspectable. Sequencer authorizations bind public keys to explicit batch ranges.

Publish the evidence consumers need

Version-2 settlement publication attaches withdrawal and balance witness vectors to a canonical checkpoint. Only its recorded proposer publishes once. The publication commits the exact vectors and verifies native inclusion, recipient authorization, certificate identity, and request-anchor ancestry. Signed deposit-root registration separately commits real positional deposit ordering under the configured Ed25519 authority.

Two checkpoint identities in a claim

A withdrawal's request anchor names the checkpoint referenced by its committed request and remains in its nullifier domain. Its inclusion checkpoint selects the registered state root proving that request. The request anchor must equal the inclusion checkpoint or be a recorded canonical ancestor. Consumers reject unknown, future, or invalidated anchors and require a finalized inclusion root.

A receipt proof proves committed execution evidence. A state witness proves the account or immutable withdrawal fact under the composite native root. Neither substitutes for recipient authorization, committed debit, nullifier checks, withdrawal timing, or emergency-exit eligibility.

Consumer verification checklist

1. Verify endpoint TLS trust, Paxeer chain ID, expected LayerX network, and supported encoding versions.
2. Decode the canonical header and verify its sequencer signature and authority range.
3. Check checkpoint identity, sequential history, roots, and the registered certificate.
4. Read the checkpoint's finality status and the finality flag accompanying the required root.
5. Verify publication transaction/receipt/block consistency, confirmation depth, proposer, event version, canonical ABI, and committed digest.
6. Verify native Merkle paths with exact counts, indices, positional siblings, and account authority bindings.
7. Verify request/inclusion ancestry and recipient signature, then apply the custody claim's debit, delay, limit, eligibility, and nullifier rules.
8. Retain the verified proof and confirm payout events and consumed claim state.

Public activity commitments use executed, batched, and finalised; Human journeys expose their own evidence levels. Preserve these meanings in application interfaces. Process readiness, a wallet signature, or a submitted checkpoint does not justify presenting a claim as settled.

Continue with settlement evidence encodings, custody and exit workflows, Paxeer consensus, and native EVM interfaces.