Receipt Cli

Verify an export on the JVM

The standalone receipt checker lets someone inspect an EdgeORE export outside the Android app. It wraps the existing Kotlin verification logic in a JVM tool, so it is independent of the app's current screen and can be run on another machine. That is useful verification of receipt contents, but it is not an independent blockchain oracle or a substitute for a trusted signing-key anchor.

Build the checker

Use a checkout containing tools/receipt-checker and the wrapper script. Identify its revision and use the project's required Java environment. Run its own tests and distribution task; do not assume the Android qualification script built it. Preserve the checker test XML separately from Android results. The historical recorded checker suite has seven passing tests, not seven extra Android tests.

bash gradlew -p tools/receipt-checker test installDist
bash scripts/verify-receipt.sh receipt.json

The invocation expects a compatible exported JSON file. A successful check should print its verdict and exit successfully. Verification failure should produce a nonzero status, while invalid usage or tool failure may have a different exit code. Inspect the tool's actual contract at the pinned revision and preserve stdout, stderr and exit status. Do not treat any line containing PASS as sufficient if the process later fails.

Interpret the result

The checker evaluates the receipt's protected content according to its format, signature, digest, chain and trust rules. It does not contact devnet to establish live confirmation unless a future explicitly documented feature does so. An offline PASS should therefore be described as receipt integrity verification, not transaction confirmed or payment verified. If the export includes a recorded chain observation, the checker can verify that signed record without making a new chain observation.

A file's included public key needs provenance. If you do not pin an expected key, an internally consistent self-signed export may still be untrusted in identity terms. Read the verifier's provenance and completeness output, not just the integrity line. The right question is which signer and which history this verdict covers. That boundary should remain visible in a second-machine demo.

Preserve an original and a copy

Copy the export to a review directory before running experiments. Keep the original bytes unchanged and calculate a file hash for the evidence bundle. The tampered file gets another name. If a parser error appears, distinguish malformed JSON from a cryptographic integrity failure. A meaningful tamper demonstration changes signed content while leaving the JSON valid and the old digest/signature untouched.

For a real-transfer gate, use the receipt exported from the observed devnet operation. A synthetic fixture is appropriate for checker tests and a labelled tooling demonstration, but cannot close a real-transfer receipt row. Name the operation ID and transaction signature in the session manifest so a reader can connect the export to its chain evidence without relying on similar timestamps.

Run on a second machine

Copy the original and tampered exports, record the checker source revision and run both commands there. Preserve the output and statuses in that machine's run note. This demonstrates portability of the verification tool. It does not automatically establish independent custody of the signing key or independent delivery verification. The strongest wording is specific: the signed receipt contents were checked by the JVM verifier on a second machine, with original acceptance and modified-body rejection.

---

Wiki home · Qualification updates · Sources and credits