Receipts & Proofs

Choose the evidence for your decision

Paxeer X gives each activity a canonical receipt and builds stronger evidence around that receipt as its batch progresses. A merchant verifies payment facts before releasing a resource; an auditor preserves the exact signed outcome; an account owner proves committed balances and withdrawal requests to settlement contracts. Each workflow uses a different evidence boundary.

Portable receipt format

The layerx-receipt-proof-v1 JSON format carries the canonical receipt and its verification context. The wire identifiers retain the LayerX name for interoperability. Verification runs without a gateway, daemon, database, clock or network connection once you supply independently trusted batch authorization.

All byte fields use canonical unpadded base64url. Unknown JSON members, incorrect lengths and padded encodings are refused. The JSON input limit is 1,500,000 bytes; canonical receipt bytes must contain between 1 and 1,048,576 bytes. JSON member order is insignificant.

Establish the trust root first

An AuthorizedBatch contains the batch ID, asset, predecessor root, successor root and sequencer key. Obtain these facts from your trusted snapshot, certificate or vector manifest. Copying the same fields out of the incoming JSON does not authorize them.

// Rust: json_bytes and trusted_batch are supplied by your application.
let verified = layerx_portable::PortableReceipt::verify_json(
    &json_bytes,
    &trusted_batch,
)?;

from_json parses the bounded representation; verify_json parses and verifies it against your authorization. Export uses PortableReceipt::export and verifies the canonical receipt before producing its JSON representation.

What verification checks

1. Decode the receipt and require byte-identical canonical re-encoding.
2. Bind the receipt and all claimed authorization fields to the trusted batch.
3. Validate the supported protocol and the operation-specific receipt semantics. Native credit, withdrawal effects, program state and program CALL outcomes use their corresponding verification paths.
4. For successful ordinary transfers, check the exact debit and credit changes using checked integer arithmetic.
5. Recompute the unsigned canonical receipt digest and strictly verify the Ed25519 signature.
6. Require the recomputed digest to equal the portable object's receiptDigest.

receipt_digest = SHA256("LXP/v1/receipt\0" || unsigned_canonical_receipt)

A cryptographically verified rejected outcome remains rejected. Portable export uses outcome verification and preserves the protocol result. The portable proof establishes sequencer authentication; batch inclusion and checkpoint settlement require their own evidence.

Native state witnesses

Native witness version 2 proves a canonical key/value leaf through its module subtree into the composite state root. Account leaves include a separate positional account-registry path, followed by the module-zero account-tree binding and module wrapper. The C, Rust and Solidity verifiers share this encoding.

Lengths, indices, leaf counts, path depths and trailing bytes are checked. Odd-width Merkle levels duplicate the final node and require that exact sibling. The native leaf hash places both lengths before the key and value:

SHA256("LXP/v1/state-leaf\0" || key_len:u32be || value_len:u32be || key || value)
SHA256("LXP/v1/state-node\0" || left[32] || right[32])

Settlement publication and custody

Version-2 publication binds native witnesses to the recorded checkpoint certificate and the recipient's authority. Only the recorded checkpoint proposer publishes its withdrawal and balance vectors. Account owners sign recipient bindings; an independently configured deposit-root authority signs deposit registration. A guarantor signature cannot replace either authorization.

1. Replay native state and construct account, withdrawal and custody-credit witnesses.
2. Collect account-owner recipient bindings and the deposit authority's registration signature when deposits exist.
3. Register the inclusion checkpoint and verify the request anchor is a canonical recorded ancestor or equal.
4. Publish version-2 witness vectors and the signed deposit root with its exact leaf ordering.
5. Fetch and verify publication transactions, receipts, blocks, confirmation depth, proposer, ABI, version, digest and native proofs.
6. Apply custody, committed debit, certificate, nullifier, recipient and exit eligibility checks before payout.

The request_anchor identifies the withdrawal request's checkpoint and remains in its nullifier domain. The separate inclusion_checkpoint identifies the root proving that request. Unknown, future or invalidated anchors are refused. Exit paths consume the proven account/asset/inclusion balance once, preventing reuse through a different signed anchor.

Archive and mirror verification

Ethereum and Solana mirrors publish batch archives for independent receipt verification. layerx-mirror-verify validates an untrusted archive, authenticates its batch header against configured trust, verifies receipt inclusion and reports freshness. Preserve trust configuration alongside the archive: a valid historical receipt does not alone establish that it is current.

For long-term evidence, retain canonical receipts, the authorized batch context, signed headers, inclusion proofs, checkpoint certificates and publication references. Preserve exact bytes rather than reconstructed display JSON. See Data Availability for replay bundles and Finality for commitment policies.

Verification failures

Handle typed refusals explicitly: malformed JSON, unsupported format or level, invalid base64url, authorization mismatch, canonical encoding failure, invalid balance effects, missing signature and digest mismatch are distinct failures. Preserve the original activity ID for recovery and never upgrade a weaker evidence level to a stronger success.