Finality & Commitment

One history, increasing assurance

Paxeer X combines the fast LayerX activity path with Paxeer settlement. Sequencers order activities, replicas preserve sealed history, guarantors independently replay batches, and settlement contracts register checkpoints. Custody stays on Paxeer, EVM chain ID 125.

Stage	Name	Evidence and responsibility
L0	Accepted	The sequencer orders the activity into the current batch and issues a state-root-bound receipt; it is responsible for ordering and inclusion.
L1	Sealed	Batch ordering is fixed. Replicas retain sealed bytes; sequencer liveness and empty-seal timers apply.
L2	Distributed	The sealed batch and availability bundle reach the guarantor quorum for independent replay.
L3	Attested	Bonded guarantors attest byte-identical replay results; conflicting attestations expose their bonds to slashing.
L4	Settled	The checkpoint is registered on Paxeer, subject to custody rules, challenge windows, withdrawal limits and emergency exits.

The assurance model uses bonded re-execution and challenge mechanisms. Guarantor signatures are attestations, not zero-knowledge validity proofs. Before using evidence to release value, apply the configured settlement and withdrawal rules for the relevant network.

Public commitment levels

Activity submission and payment middleware expose three exact commitment names. These are evidence requirements rather than interchangeable progress labels. They do not replace the L0–L4 lifecycle.

Commitment	Required evidence	Application decision
`executed`	A verified canonical receipt for the submitted activity	Inspect the authenticated outcome and its payment or program effects.
`batched`	Executed evidence plus an authenticated receipt proof naming the same activity and carrying byte-identical canonical receipt bytes	Require signed-batch inclusion before releasing a resource.
`finalised`	Batched evidence plus the selected latest finalised checkpoint whose canonical header exactly equals the proof's signed batch header	Require the checkpoint evidence bound to that exact batch.

batch_evidence carries the authenticated receipt proof and checkpoint_evidence carries the checkpoint. A different checkpoint or a newer head cannot substitute for the exact required header. Admission acknowledgements, queue entries, activity IDs and HTTP 202 responses do not establish execution.

Use the exact wire vocabulary

The spelling is finalised. Values such as finalized, accepted, ack and uppercase variants produce invalid-parameter error -32602.

Recover a pending commitment

When a bounded wait cannot establish the requested evidence, the gateway returns an error rather than silently returning a weaker success:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32001,
    "message": "Requested commitment unavailable",
    "data": {
      "state": "pending",
      "requested_commitment": "finalised",
      "evidence": {}
    }
  }
}

Keep the original signed activity and activity ID.
Read lx_getActivityStatus and lx_getReceipt to recover the existing outcome.
Retrieve the required authenticated receipt and checkpoint evidence.
Verify exact activity, canonical receipt and signed-header bindings before satisfying your release policy.

An upstream HTTP 202 is translated into pending error -32001 with the requested commitment. Creating another activity to escape an unknown result can duplicate the economic action.

Payment release policies

An x402 offer carries its requested level in extra.layerx.commitment. An exact offer that omits the LayerX extra defaults to executed; metered and subscription offers require their LayerX payer and purpose terms. The seller verifies the requested evidence before releasing the resource.

A successful settlement reference is lxp:<receipt_digest>. Validate the receipt, payment facts, configured authority and commitment evidence together. The reference or an HTTP success is insufficient on its own.

Replay covers the whole economic system

Guarantors replay payments, program calls, program-owned transfers and storage occupancy settlement from the same ordered history. Program monetary effects are explicit 402LXP transfer sets, while occupancy charges remain replay-checkable batch evidence. Deterministic execution excludes local clocks, floating point and unstable iteration from consensus decisions.

Checkpoint continuity

Checkpoint ordering version 2 treats an epoch as an authority lifecycle. Multiple batches can share an epoch. Registration requires a nonzero epoch that does not regress, a batch number exactly one greater than the finalised batch, consecutive activity ranges, continuous state roots and increasing timestamps, alongside signature, membership, freshness and invalidation checks.

Advancing an epoch cannot bypass the batch or activity sequence checks. A repeated batch cannot occupy the next sequence, and skipped batches are refused. Request anchors and inclusion checkpoints remain separate fields when proving settlement facts.

Liveness and exits

Empty-seal and liveness timers make sequencer stalls observable. The settlement path provides exits onto Paxeer when the ordinary activity path stalls; the applicable checkpoint evidence, challenge window, withdrawal limits and eligibility checks still govern custody release.

Continue with Receipts & Proofs, Data Availability and Consensus.