Receipt Format

Read a receipt without overclaiming it

A receipt is a structured record with several possible evidence dimensions. EdgeORE's app-signed body can be checked for integrity and signing-key provenance. Wallet evidence can identify what the wallet signed. A chain observation can report an operation's status. A provider acknowledgement can report what a service says it delivered. Payment remains another fact. None of those dimensions should be collapsed into one universal Verified badge.

Identify the signed body

The export stores receipt bodies as exact strings with associated digests and signatures. Integrity checks apply to those signed contents. Descriptive export fields outside the signature are not protected by the same claim. Examples include contextual notes, labels or export metadata, depending on the format. The public wording is therefore verifies the integrity of signed receipt contents, not detects every possible change to the export.

The distinction matters even when a file looks like one JSON document. JSON structure alone does not tell you which bytes are signed. A signature over one body's bytes does not cover neighboring fields unless the protocol explicitly binds them. Read the format and verifier together. Do not reserialize an original body before verification because whitespace or key-order changes can alter the exact bytes being checked.

Follow key provenance

Receipt v2 records identify the signing key and retain key epochs. A registry lets an export describe which key signed which record. A valid signature under a key included in the same untrusted file proves internal consistency, but it does not automatically prove that the key belongs to the expected app installation or provider. A pinned key supplies an external trust anchor; an unpinned key must be labelled accordingly.

Android Keystore signing and JVM software-key tests are different environments. The checker can validate compatible signatures offline, but a fixture generated with a software key is not evidence that an Android hardware-backed key was used. Key rotation also changes the provenance question. Historical receipts should remain verifiable without pretending every record was signed by the current epoch.

Read chain and completeness separately

Hash-chain links help detect certain changes to the ordered record history. A full-chain export can include a signed checkpoint, while a selected export is a subset. A subset can contain valid individual receipts without proving completeness of the entire installation history. The verifier should explain that scope rather than call every valid selection complete. Missing records and altered records are related but different problems.

An app signature says the app's key signed a body. It does not prove that an external node performed useful work or that a customer paid. A transaction status observation must identify cluster, signature, time and error. Even a successful payment only proves the chain transfer; it does not independently establish storage durability, AI quality or bandwidth delivery. Those claims need task-specific acceptance evidence.

Inspect one receipt

Open the export as data, find a record's body, operation ID, digest, key ID and evidence dimensions. Identify which fields are signed and which are descriptive. Check whether the export is full or selected. Run the verifier without editing the original. Then write a two-sentence interpretation: what integrity passed and what remains unknown. This is a more useful exercise than repeating the word tamper-evident without explaining its boundary.

---

Wiki home · Qualification updates · Sources and credits