# Checkpoint settlement & evidence Follow LayerX activities from ordered receipts to bonded replay, finalized Paxeer checkpoints, and verifiable custody claims. ## Execution and settlement form one history Paxeer X settles LayerX activity on EVM chain ID `125`. The sequencer orders activities; guarantors independently replay sealed batches; Paxeer records the resulting checkpoints and enforces custody releases. Payments, program calls, program-owned transfers, and storage occupancy charges participate in the same deterministic history. | Level | Evidence | Meaning | | --- | --- | --- | | L0 · Accepted | Sequencer receipt | The activity is ordered in the current batch and bound to a state transition. | | L1 · Sealed | Fixed batch history | Ordering is fixed and the batch is ready for distribution. | | L2 · Distributed | Batch and availability bundle | Guarantors receive the material needed for independent replay. | | L3 · Attested | Bonded guarantor certificate | Guarantors attest byte-identical replay results. | | L4 · Settled | Paxeer checkpoint | Settlement custody enforces finality, challenge windows, withdrawal limits, and exits. | A guarantor attestation is bonded re-execution evidence. Its security combines bonds, challenges, availability checks, and release limits. Applications retain the receipt for the fast path and follow the same activity into settlement evidence before presenting settled funds. ## Native checkpoint anchor The `layerxanchor` precompile at `0x0000000000000000000000000000000000001014` records checkpoints, finality, availability attestations, and guarantor bonds. Anyone can submit a self-verifying checkpoint certificate. Finalization requires the configured threshold of active bonded guarantors, continuity with the finalized chain, no open challenge, and completion of the challenge window. | Method | Purpose | | --- | --- | | `submitCheckpoint(header, headerSignature, certificate)` | Admit a canonical 354-byte header, 64-byte sequencer signature, and guarantor certificate. | | `submitAvailabilityAttestation(attestation)` | Record a 274-byte attestation for a known checkpoint. | | `finalize(batchNumber)` | Finalize a checkpoint after its challenge conditions clear. | | `latestFinalized()`, `checkpoint(batchNumber)` | Read finalized progress and full checkpoint metadata. | | `finalizedStateRoot(batchNumber)`, `finalizedReceiptRoot(batchNumber)` | Retrieve roots together with their finality flags. | | `openChallenge(batchNumber, kind, evidenceHash)` | Open a bonded fraud or data-availability challenge. | | `submitEquivocation(evidenceA, evidenceB)` | Present conflicting guarantor attestations for slashing. | Anchor status is `0` unknown, `1` submitted, or `2` final. Read the finality flag with a root; the existence of a root alone does not establish payout eligibility. The exact interface is `precompiles/layerxanchor/LayerXAnchor.sol`. ## Checkpoint ordering and authority Checkpoint ordering version 2 treats an epoch as an authority lifecycle. Multiple batches can share an epoch. Every registered batch advances the finalized batch number by exactly one, starts its activity range at the preceding last sequence plus one, and continues the preceding state root. Epochs cannot regress. Timestamp, signer membership, freshness, and invalidation checks remain mandatory. ### Request anchor and inclusion checkpoint The request anchor identifies the checkpoint referenced when a withdrawal is created and remains part of its nullifier domain. The inclusion checkpoint identifies the registered root that proves the committed request. These fields are separate: the request anchor must be the inclusion checkpoint or a recorded canonical ancestor. Unknown, future, and invalidated checkpoints are refused. ## Version-2 settlement publications The settlement publication contracts expose `EVIDENCE_VERSION() == 2`. The recorded checkpoint proposer publishes withdrawal and balance vectors once for a canonical checkpoint. Publication verifies native inclusion, recipient bindings, the recorded guarantor certificate, and request-anchor ancestry before committing the evidence digest. | Publication | Contents | Commitment | | --- | --- | --- | | Withdrawal witnesses | Withdrawal ID, semantic withdrawal leaf, and checkpoint proof. | `SHA256(abi.encode(checkpointHash, uint16(2), withdrawals, balances))` | | Balance witnesses | Account, asset, unsigned 128-bit amount, recipient, and checkpoint proof. | | Deposit root registration | Registration bytes, checkpoint-authority signature, and positional leaf ordering. | `SHA256(abi.encode(uint16(2), registration, signature, leafOrdering))` | Legacy version-1 consumers retain their matching proof paths. An evidence envelope cannot mix versions. Publication records evidence; payout still requires custody, debit, certificate, nullifier, recipient, and exit-eligibility checks. ### Independent signing roles The account authority authorizes the payout recipient. A separately configured Ed25519 checkpoint authority signs deposit-root registration. Guarantors attest replay. A guarantor key cannot substitute for an account key or deposit-root authority, and native replay cannot manufacture their signatures. ``` Recipient binding: "LX:SETTLE:RECIPIENT:v1" || 0x00 || network_id:u32 || account32 || asset32 || recipient20 || request_anchor32 Deposit-root registration: "LX:PAXEER:DEPOSIT:ROOT:v1" || checkpoint_id32 || checkpoint_state_root32 || deposit_root32 || custody_reference32 || network_id:u32 || protocol_version:u16 ``` Integers are unsigned big-endian. The recipient domain includes the zero separator shown above; the deposit registration domain has no terminating zero. Ed25519 verification checks canonical point and scalar encoding and refuses small-order inputs. An Ed25519 public key is not converted into an EVM address. ## Native state proofs A version-2 native witness proves a module key and value into the composite state root. Account witnesses additionally prove the canonical account record into the account registry, then the `account-tree` binding into module zero, and finally the module wrapper into the composite root. The account record binds balances, asset identity, and account authority. ``` leaf = SHA256("LXP/v1/state-leaf\0" || key_length:u32 || value_length:u32 || key || value) node = SHA256("LXP/v1/state-node\0" || left32 || right32) ``` Merkle paths use native positional order. At odd widths the last node duplicates itself. Verifiers check the exact sibling, counts, indices, depths, and trailing bytes. C, Rust, and Solidity verify the same witness representation. The native witness version, checkpoint protocol version, and publication envelope version are separate fields. ### Committed withdrawal facts A native withdrawal stores an immutable fact under `withdrawal:` followed by its 32-byte nullifier. Its version-2 value binds network, withdrawal ID, account, asset, amount, payout recipient, and request checkpoint. A failed monetary transfer rolls the staged fact back. This fact proves request creation; later payout status comes from the settlement claim and nullifier records. ## Producer and consumer workflow 1. Replay native history independently and construct real account, withdrawal, and deposit evidence. 2. Collect account-signed recipient bindings and the configured checkpoint authority's signed deposit registration. 3. Register the inclusion checkpoint with its complete guarantor certificate and canonical ancestry. 4. Publish version-2 withdrawal/balance vectors and signed deposit ordering. Ordering contains 1–4096 leaves and consumers reconstruct the root. 5. Fetch published evidence and verify the transaction, receipt, block, confirmation depth, proposer, canonical ABI, event version, digest, and native proof. 6. Apply claim-specific custody checks, wait for availability, and verify the final payout and nullifier consumption. Owner exit witnesses cover asset-bearing agent-main accounts. System reserves and withdrawal custody accounts are not owner exit balances. Empty balance publications cannot stand in for proofs. Publication retries compare recorded digests and refuse conflicting contents. ## Verify the transport and the money Settlement clients verify endpoint TLS trust and chain identity before consuming evidence. The Paxeer boundary relays admitted JSON-RPC requests and exposes readiness separately from finality. A healthy process or matching chain ID establishes connectivity, while finalized checkpoint evidence establishes the settlement claim. Keep vocabulary specific to its surface: public submit commitments use `executed`, `batched`, and `finalised`; Human journeys use `receipt-verified`, `checkpoint-finalised`, and `paxeer-finalised`. Do not elevate one level merely because an earlier stage succeeded. Continue with [deposits, withdrawals, and emergency exits](https://docs.paxeer.app/custody), [Paxeer consensus](https://docs.paxeer.app/consensus), and [native EVM interfaces](https://docs.paxeer.app/precompiles).