A receipt for every activity

Most systems tell you a payment worked by returning a success response. A webhook fires, a status flips to green, and you trust the party that told you.

That is not good enough for software that pays other software thousands of times a day. An agent needs evidence it can check itself, and it needs to know how much weight that evidence carries at the moment it acts.

LayerX answers both needs. Every activity returns a signed receipt, and every receipt sits somewhere on a staged finality ladder that says exactly what stands behind it.

What a receipt contains

Every action in LayerX is submitted as the same twelve-field envelope: the actor, the authority key, the account sequence, timestamp bounds, an idempotency key, a fee limit, and the payload bound by hash. It is signed with Ed25519.

The kernel checks the envelope in a fixed order, executes it once, and issues a receipt signed by the sequencer. The receipt records:

• the result code
• the state root before and after the activity
• the effects it produced
• the fee charged
• the batch it settled in

Two properties follow. First, a retry cannot double-charge. If the same actor resubmits the same idempotency key, the kernel returns the stored receipt instead of executing again. Second, anyone holding a receipt can check the sequencer’s signature and the state roots offline, without trusting the node that served it.

Verification without a node

The layerx-verify tool pins the signed genesis manifest as its trust root. From there it can check a receipt on its own, or a receipt together with a Merkle inclusion proof and the signed batch header that commits it.

It re-encodes the input and compares the bytes, recomputes the leaf hash, folds the sibling path to the root in the header, and checks the signatures. Every input comes from a local file. Verification touches no node and no chain state.

The verifier also refuses to be talked into trust. It ignores any public key its input carries and checks the header signature against the key pinned from genesis. A responder cannot widen the trusted set. All seven client SDKs verify receipts locally in the same spirit.

The ladder, L0 to L4

A receipt in hand is not the same as a settled outcome. Paxeer X does not declare an activity final at once. It qualifies it through five named steps, and each step names the party that is liable if its claim is wrong.

• L0, accepted. The sequencer orders the activity into the current batch and issues a receipt chained to the state root. The sequencer is on the hook for that ordering.
• L1, sealed. The batch is sealed and its ordering is fixed. A 354-byte header commits to the activity, receipt, event, availability and oracle roots.
• L2, distributed. The sealed batch and its data-availability bundle go out to the guarantor quorum.
• L3, attested. Bonded guarantors re-execute the batch and attest to byte-identical results. Their bonds stand behind that attestation.
• L4, settled. The checkpoint lands on the Paxeer X chain. Custody, the challenge window and withdrawal limits now stand behind the outcome.

L0 and L1 are the fast path: an in-channel receipt the agent can act on immediately. L2 through L4 are the settlement path.

Three names on the wire

The ladder is the internal lifecycle. Developers work with three public commitment names: executed, batched and finalised (the British wire spelling is the one the API accepts).

Each name is an evidence requirement, not a mood:

• executed needs a verified canonical receipt.
• batched adds the authenticated proof that the receipt is included in a signed batch header.
• finalised adds checkpoint evidence whose canonical header matches that signed batch header exactly.

If the gateway cannot establish the level you asked for within its bounded wait, it does not quietly return a weaker success. It returns an explicit refusal with the state marked pending. You then recover with the status, receipt and proof reads rather than resubmitting.

Honest about what stands behind each step

It matters to say clearly what the ladder is not. Nothing proves validity before L4. A guarantor signature is an attestation, not a validity proof. What stands behind a batch before settlement is guarantor bonds, the challenge window and withdrawal limits.

A checkpoint becomes final only once the required threshold of bonded, active guarantors has attested it, it continues the finalized chain, and no challenge is open. Guarantors who sign two conflicting checkpoints for the same batch can be slashed, and the two signed attestations are the whole proof.

Naming the liable party at every step tells a caller what recourse exists at the moment it uses a result.

Choosing the right level

Different actions deserve different certainty. A low-value API call can proceed on an executed receipt. A large transfer can wait for finalised. A seller using 402LXP can state the required commitment in its payment offer, and a request that cannot reach that level is refused rather than downgraded.

Why it matters

A receipt that anyone can check, plus a ladder that says how much it is worth, turns “trust us” into “check for yourself”. An agent can act fast where speed is safe and wait where it is not. An auditor can re-derive what happened months later from a pinned genesis manifest and a file.

The documentation covers receipt formats, proofs and the commitment API in full.