Receipt Trust

Separate integrity, provenance and completeness

Receipt verification is easier to reason about when it answers three questions separately. Integrity asks whether protected bytes still match their digests and signatures. Provenance asks whether the signer is the expected party under a trusted key. Completeness asks what scope of history the export represents. A fourth question, external truth, asks whether the recorded claim corresponds to an actual event. Cryptography helps with some of these questions but does not collapse them.

Integrity is necessary but limited

A receipt body can pass a signature check while describing an event the signer never independently measured. The signature binds the signer to the bytes, not the universe to the statement. This is why an app-written Inference completed field needs a real runtime observation behind it. Similarly, a provider-signed storage record is a provider claim, not automatically an independent durability proof.

A digest alone is weaker than a signature tied to a trusted identity. Anyone who changes a body can calculate a new digest. Signature tests should therefore include a body change with a recomputed digest and an unchanged signature. The verifier should reject that case at the appropriate layer. Do not describe a hash mismatch demonstration as the entirety of the protocol's security review.

Establish a trust anchor

An included public key is data supplied by the export. A pinned key is a separately established expectation. If a verifier accepts a newly generated key without warning, it can prove consistency of a forged collection while leaving identity unresolved. Key epochs, device installation identity and provider registration policies must be considered when interpreting provenance. Losing the original device does not retroactively make every historical signer untrusted, but recovery needs an explicit policy.

Android Keystore can make key extraction harder and constrain key use. It does not guarantee the app made a truthful observation before requesting a signature. A compromised app may still ask a protected key to sign an incorrect record if its permissions allow that operation. Hardware backing therefore belongs in the key-protection story, not as a universal proof of computation or service delivery.

Describe completeness honestly

A selected export may contain a handful of valid records. It should be labelled a subset, even when those records link into a valid history. A full export with a signed checkpoint can support a stronger scope claim under the implementation's rules. Deletions, reordering and local-copy comparisons require careful interpretation: a verifier cannot compare against local history it does not have.

Cross-machine verification is useful because it removes dependence on the app UI and local parser display. It does not automatically give the second machine an authoritative checkpoint. If that machine trusts only what the export supplies, say so. If it receives an expected public key through another authenticated channel, record that channel without publishing credentials.

Apply the model to a contribution job

A future customer-funded job might include an app receipt, node acknowledgement, task evaluator result and Solana settlement signature. Treat each as one layer. The evaluator can still be wrong, the node can still lie and the chain can faithfully settle a disputed decision. A strong product exposes those authorities and dispute paths rather than calling the collection trustless. The exercise is to annotate one receipt with what each layer proves, what it depends on and what would be needed to strengthen the next claim.

---

Wiki home · Qualification updates · Sources and credits