Receipts & Proofs
Verify what the protocol executed, what it charged, and how the result connects to a signed batch and settled checkpoint.
A receipt is evidence computed by the protocol. Clients submit signed activities; they do not choose receipt fields, balance outcomes, state roots, or result codes. Applications use verified receipts to reconcile payments, release paid resources, display completed work, and recover uncertain submissions.
Activity receipt anatomy
| Evidence | Native fields | What it establishes |
|---|---|---|
| Identity and order | activity_id, global_sequence, batch_id | The activity and its position in ordered execution. |
| State transition | previous_state_root, resulting_state_root, activity_root | The committed state chain and activity binding. |
| Outcome | result_code, effects, fee_charged | Success or refusal, computed effects, and execution charge. |
| Rules | protocol_version, module_id, module_version, parameter_version | The execution rules needed for independent interpretation and replay. |
| Authorization | authorization_hash, context_hash, sequencer_signature | The authorization and context commitments authenticated by the sequencer. |
402LXP payment evidence
A successful 402LXP operation provides protocol-computed before and after balances, asset and amount, sender and recipient account identifiers, sequence facts, transfer-set root, authorization and context hashes, chained state roots, batch identifier, timestamp, and signature. Client-supplied balances cannot establish payment.
A failed payment produces a failure result with its result code and unchanged payment balances; it does not produce a signed successful 402LXPReceipt. The enclosing admitted activity can still incur protocol fee and sequence bookkeeping. Distinguish the payment’s economic outcome from the activity’s execution record.
Programs produce receipt-native outcomes
Program calls bind terminal success, failure, or resource exhaustion to the activity receipt. Outcome evidence includes runtime and ABI versions, fee and metering schedules, CPU fuel, memory and storage counters, output size, occupancy charges and evidence, call-graph commitments, terminal payload commitments, and transfer roots. A program’s local response or application log does not substitute for the protocol receipt.
Three evidence requirements
| Commitment | Verify |
|---|---|
executed | A verified canonical receipt for the exact activity. |
batched | Execution evidence plus an authenticated receipt inclusion proof whose canonical value matches the receipt byte for byte. |
finalised | Batch evidence plus finalised checkpoint evidence whose canonical header exactly equals the proof’s signed batch header. |
A queue acknowledgement, HTTP 202, or activity identifier establishes neither execution nor settlement. A receipt proves its own execution facts; a matching proof binds it to the batch; a matching finalised checkpoint connects that batch to Paxeer. These public commitment names accompany the broader L0–L4 finality ladder.
Independent verification
| Surface | Use |
|---|---|
layerx-proof | Verify signed receipt bytes. |
layerx receipt verify | Perform a local check against caller-supplied batch facts. |
layerx-portable | Export and verify a layerx-receipt-proof-v1 JSON object against independently trusted AuthorizedBatch facts. |
Portable verification runs without a node, gateway, daemon, database, clock, or network. Its trust anchor is the independently trusted authorized batch. Merely packaging a receipt with a claimed signer does not make that signer authoritative.
Verification workflow
- Decode canonical receipt bytes and authenticate the signature against the expected authorized sequencer.
- Match the activity identifier and require the expected success result.
- For payment, compare asset, amount, source, destination, authorization, and context with the intended purchase or transfer.
- Verify state-root binding and the exact receipt inclusion proof when batch assurance is required.
- Require matching finalised checkpoint evidence when settlement assurance is required.
- Persist the verified receipt identifier and evidence so retries and reconciliation refer to the original economic result.
Settlement augmentation
After Paxeer accepts the covering checkpoint, the retrievable receipt can carry inclusion proofs, checkpoint identifier, guarantor certificate, and Paxeer settlement reference. This adds evidence without changing the original pre-checkpoint receipt fields. Guarantor certificates attest independent replay backed by bonds; they are not zero-knowledge validity proofs.
Unknown outcomes and honest UI states
If submission fate cannot be determined, retain the signed activity and its idempotency key and recover the original receipt. Display the operation as still checking until verified evidence supports completion. An agent claims a result only after independently verifying core-produced evidence; a local success string is insufficient.
Native receipt interfaces
The C interface provides lxp_receipt_encode, lxp_receipt_decode, lxp_receipt_sign, lxp_receipt_verify, and lxp_receipt_digest. Program evidence is bound with lxp_receipt_bind_program_outcome and lxp_receipt_bind_program_artifacts. Supply validation is exposed through lxp_receipt_validate_supply.