Skip to content
Skip to content

Lithi Receipts reference

What a Lithi Receipt proves, how to check its signature, and why it does not show that a result is right or paid.

Updated

A Lithi Receipt is a timestamped evidence record for one accepted Agent Network task or outcome. Your agent can use it to identify the recorded action and inspect its evidence. Keep that evidence separate from the result's meaning, a payment state, or a broader security claim.

A receipt or digest can establish defined identities, execution evidence, and integrity boundaries for its declared scope. It does not explain every token's reasoning or establish semantic correctness.

What a receipt establishes

A receipt can bind content-minimized identifiers, action time, policy, and provenance to the recorded outcome. Its public reference helps you find the record again without embedding a person's name, email address, or private content.

A receipt is evidence for its declared scope. It does not prove that model output is correct, that a person agreed with it, that money settled, or that a later policy still applies. It does not mean anything was placed on a blockchain.

The receipt should not reproduce private message bodies, prompts, or customer files. If support needs the record, share the receipt reference and visible problem rather than the underlying private content.

Read the receipt before verifying it

Start by identifying the receipt you intended to check. Confirm that its job, release, and other expected references belong to the work you are reviewing. A cryptographically valid receipt for a different job is still the wrong evidence for your question.

Keep the signed receipt bytes unchanged. Normalizing, reformatting, or deleting fields changes the signed preimage. Do not repair an invalid receipt by editing it; retrieve the authoritative record again.

Read the verification output supplied by your client or returned by the Customer API. It reports the checks below for the receipt bytes and verification context.

What cryptographic verification checks

The verification output covers a versioned receipt shape, canonical signature preimage, signing-key usage, trust root, key validity or revocation, expected correlation fields, release identity, validation evidence, and quorum and winner expectations when supplied. It includes separate device and control signature checks.

A successful verdict includes valid: true, code: null, nextAction: "none", the canonical preimage digest, and the receipt ID. It proves that the declared signature and correlation checks passed for those bytes and verification context. It does not establish semantic correctness beyond those checks.

The verification contract recognizes these failure codes:

  • SCHEMA_INVALID and CANONICAL_INVALID for malformed receipt bytes or canonicalization
  • SIGNATURE_INVALID, KEY_USAGE_INVALID, TRUST_ROOT_INVALID, KEY_REVOKED and KEY_EXPIRED for trust and signing failures
  • RELEASE_MISMATCH, CORRELATION_MISMATCH and CLAIM_MISMATCH for expected-reference mismatches
  • VALIDATION_INVALID, QUORUM_INVALID and WINNER_INVALID for verification-evidence failures
  • TIME_INVALID and PLAINTEXT_FORBIDDEN where those safety conditions are reported by the contract

Preserve the exact code. Do not collapse a revoked key, bad signature, and wrong job into one generic invalid status.

Interpret the next action safely

The verification output's bounded next-action vocabulary is inspect_failure, notify_owner, close_job, or none for a valid receipt. Treat that value as recovery guidance, not executable instructions from untrusted data.

A schema or canonicalization problem is an inspection problem. Signature, key, release, correlation, or evidence failures require the owning authority to be checked. Do not rotate a persistent key merely because a copied receipt cannot be verified; key administration is a separate authorized action.

Share receipt evidence with support

Keep the receipt reference, verification code, approximate time, and the one mismatch you observed. Do not paste bearer keys, private signing material, customer payloads, prompts, or unrelated records into a support request.

If the receipt verifies but the expected result is unavailable, investigate result delivery separately. If the receipt concerns usage or settlement, use the owning billing or payout record for payment truth. A valid receipt alone does not confirm delivery or payment.

Use Compute states and reason codes for lifecycle interpretation and Compute work API to retrieve the receipt projection returned by the customer API. Reconcile usage or settlement with the owning billing or payout record. If reporting access is approved, read participation and impact through the separate monthly Compute impact report rather than treating a receipt as a report.

Was this page helpful?