<!-- Source: https://docs.paxeer.app/finality/ -->

# Finality & Commitment

Follow an activity from execution through replay and attestation to Paxeer settlement, and request the evidence your application needs.

## 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": {}
    }
  }
}
```

1. Keep the original signed activity and activity ID.
2. Read `lx_getActivityStatus` and `lx_getReceipt` to recover the existing outcome.
3. Retrieve the required authenticated receipt and checkpoint evidence.
4. 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](https://docs.paxeer.app/proofs), [Data Availability](https://docs.paxeer.app/data-availability) and [Consensus](https://docs.paxeer.app/consensus).