Submit a sequencer-signed batch header with a guarantor certificate and the Paxeer chain verifies both, records the checkpoint, and finalises it once the quorum, continuity and challenge-window rules hold. Your contracts then read the finalised state root and receipt root through the precompile at 0x1014 and know a bonded quorum stands behind them. Guarantors lose part of their bond when a challenge is upheld. Challenge resolution stays authority-arbitrated rather than verified on chain.

What it does

A sequencer-signed batch header and a guarantor certificate are submitted to the Paxeer chain, which verifies both, records the checkpoint as submitted, and finalises it once the quorum, continuity and challenge-window rules hold. Each finalised checkpoint carries the state root, receipt root and data-availability root of a contiguous run of LayerX activity, so the chain holds the record of what the agent domain settled. Anyone may submit a checkpoint or open a challenge against one; a challenge blocks finalisation until it is resolved. Guarantors post bonds and lose a configured fraction of them when a challenge is upheld or when they sign two different checkpoints for the same batch.

Key capabilities

• Verifies a sequencer header signature against a batch-range authorisation before recording anything.
• Requires a guarantor certificate declaring exactly the threshold, with signers still bonded and active.
• Enforces continuity: next batch number, next sequence, previous state root equal to the settled root.
• Records per-guarantor availability attestations over five data classes and derives a quorum mask.
• Slashes equivocation trustlessly: two conflicting signed attestations for one batch are the whole proof.
• Exposes finalised state roots, receipt roots and checkpoint status to EVM contracts through a precompile.

Differentiators

Equivocation slashing needs no arbiter: the two signed attestations verify themselves, any address may report them, and the reporter takes a configured share of the slashed bond. Availability is tracked as a five-class possession mask per guarantor rather than a single flag, and a guarantor may only widen its own mask. A checkpoint already submitted can be replaced only by a certificate with at least as many guarantors, and never once it is final or under challenge.

Outcomes

• Read finalised state roots and receipt roots straight from Solidity.
• Report equivocation yourself: two conflicting signed attestations are the whole proof.
• Track availability as a five-class possession mask for each guarantor.

Technical notes

• Limits: threshold must be within 1..32, a certificate carries at most 32 guarantor attestations, the canonical batch header is exactly 354 bytes, a validity proof is at most 1,048,576 bytes, header signatures are exactly 64 bytes, and max_attestation_delay_ms must be non-zero (default 3,600,000).
• Bonds and challenge bonds are posted as call value in the single configured bond denomination; a value in any other denomination is rejected. An opened challenge must match the configured challenge bond exactly. Leaving bond stays slashable for the unbonding delay, 21 days by default.
• Precompile gas is charged before execution as base plus 16 per calldata byte, 4,000 per signature and 100 per 32-byte proof node, with a base of 3,000 for views and 30,000 for state changes. A certificate too short to declare its own work is charged the 32-attestation maximum and reverts.
• Challenge resolution is authority-arbitrated, not verified on chain. ResolveChallenge takes a bare upheld boolean from the params authority, and the Solidity CheckpointChallengeManager.resolveChallenge is onlyGovernance; neither checks the evidence hash the challenger committed to.
• challenge_window_seconds defaults to 0, so a chain on default params finalises a checkpoint in the same transaction that submits it, with no dispute delay. The Solidity CheckpointChallengeManager instead refuses to deploy with a challenge period under one hour.
• Two implementations exist: the native module behind the precompile at 0x1014, and the Solidity CheckpointRegistry and CheckpointChallengeManager predeploys. In CheckpointRegistry.publishCheckpointWitnesses, the version 2 path verifies witnesses through NativePublicationVerifier, while the legacy version 1 path accepts them on a domain-prefix and length check alone.
• The module has no gRPC query service, no CLI and no proto package under api/; reads go through the precompile.

interface ILayerXAnchor {
    function latestFinalized() external view returns (uint64 batchNumber, bool exists);
    function finalizedStateRoot(uint64 batchNumber) external view returns (bytes32 stateRoot, bool finalized);
    function finalizedReceiptRoot(uint64 batchNumber) external view returns (bytes32 receiptRoot, bool finalized);
    function statusOf(uint64 batchNumber) external view returns (uint8);
    function openChallenge(uint64 batchNumber, uint8 kind, bytes32 evidenceHash)
        external payable returns (uint64 challengeId);
}

ILayerXAnchor anchor = ILayerXAnchor(0x0000000000000000000000000000000000001014);
(bytes32 stateRoot, bool finalized) = anchor.finalizedStateRoot(batchNumber);

More in Paxeer chain