You choose how much evidence a submission must carry: executed returns a verified canonical receipt, batched adds the receipt proof, and finalised adds a checkpoint whose canonical header matches the signed batch header. The gateway never downgrades a request into a weaker success; when the bounded wait falls short it refuses with error -32001 and state pending. Each rung names who is liable, from the sequencer at L0 to Paxeer custody at L4.

What it does

Paxeer X qualifies an agent-domain activity through five steps rather than declaring it final at once. L0 accepted is the sequencer ordering the activity into the current batch and issuing a receipt chained to the state root; L1 sealed fixes the ordering; L2 distributed sends the sealed batch and its data-availability bundle to the guarantor quorum; L3 attested is bonded guarantors re-executing and attesting byte-identical results; L4 settled is the checkpoint landing on the Paxeer chain. Each step names the party on the hook if its claim turns out to be wrong, from the sequencer at L0 to Paxeer custody, the challenge window and withdrawal limits at L4.

Key capabilities

• Names a liable party at every step: sequencer, replicas, data availability, guarantor bonds, then Paxeer custody.
• Separates the fast path (L0 to L1, an in-channel receipt) from the settlement path (L2 to L4).
• Exposes three public commitment names on submission: executed, batched, finalised.
• Treats a commitment as an evidence requirement, refusing rather than returning a weaker success.
• Matches finalised evidence by exact canonical header, not by a merely newer chain head.
• Replays every batch effect, including program calls and storage-occupancy charges.

Differentiators

Each rung names the liable party rather than only a confidence level. The gateway never converts a stronger commitment request into a weaker success: finalised requires a checkpoint whose exact canonical header equals the signed batch header in the receipt proof, and a different checkpoint or a newer head is not substituted. Consensus execution forbids floating point, local clocks and unstable iteration specifically so two honest machines reach the same bytes at L3.

Outcomes

• Request finalised and get checkpoint evidence or an explicit refusal.
• Know the liable party before you act on a receipt.
• Recover a pending submission by reading status and proofs, not resubmitting.

Technical notes

• The ladder is the internal lifecycle. Public submission and verification vocabulary is three names: executed, batched and finalised. No API returns an L0 to L4 rung. The checkpoint status ladder the ILayerXAnchor.statusOf view returns is three values: 0 unknown, 1 submitted, 2 final.
• Evidence per commitment: executed needs a verified canonical receipt; batched adds the authenticated receipt proof whose canonical_value equals the returned receipt byte for byte; finalised adds checkpoint evidence whose canonical_header equals the proof's signed batch header. An admission acknowledgement, queue state, HTTP 202 or activity id without a receipt is not execution evidence.
• When the bounded wait cannot establish the requested level, JSON-RPC returns error -32001 "Requested commitment unavailable" with state: "pending" and the requested commitment, not a result. An upstream HTTP 202 is translated the same way. Recover with lx_getActivityStatus, lx_getReceipt and the proof reads rather than resubmitting.
• The wire spelling is British finalised. ack, accepted, finalized and uppercase variants are invalid parameters (-32602).
• Nothing proves validity before L4. What stands behind a pre-L4 batch is guarantor bonds, the challenge window and withdrawal limits, not a validity proof; a guarantor signature is an attestation, not a SNARK. A checkpoint becomes final only once the required threshold of bonded, active guarantors attested it, it continues the finalised chain, no challenge is open and the challenge window has elapsed.
• Not yet implemented: the five-level x402 verification vocabulary. The 402LXP middleware declares sequencer-signed, batch-included, state-proven, checkpoint-finalised and settlement-anchored as a type, but only ever emits and accepts sequencer-signed, and the spec forbids copying an RPC commitment into verificationLevel or inferring one from it.
• Canonical activity bytes are capped at 524,288 on submission. The verified wallet's waitFor defaults to a 30,000 ms bounded wait.

// npm install layerx-sdk  (Node.js 22 or newer)
import { JsonRpcClient, type Commitment } from "layerx-sdk";

const client = new JsonRpcClient("https://gateway.example/rpc");
const commitment: Commitment = "finalised";
const result = await client.sendActivity(canonical, commitment);
// result.commitment === "finalised", with batch_evidence and checkpoint_evidence attached.
// A level that cannot be established refuses with -32001 and state "pending".

More in Network