VRX-1 · Receipt Type 1 of 10 · d19.69 Reference

Prove what was submitted, when, and to whom.

A Submission Receipt records that a person handed something to an institution — a form, a document, a request, an application — at a specific moment, in a specific form. The receipt is self-attested by its creator; its content is tamper-evident via SHA-256.

What a Submission Receipt is

A structured record that someone submitted something to a named institution at a recorded moment. It captures the submitter (pseudonymous where appropriate), the receiving institution, the service or process being submitted to, the date, the items handed over, and any reference number the institution returned.

It is the entry-point receipt for most other VRX-1 receipt types: a missing-item receipt, a correction trail, an escalation packet, or a verification-readiness review usually chains back to an original submission.

What this receipt proves

  • The receipt content has not been altered since the hash was computed — anyone holding the JSON can recompute the SHA-256 and confirm a match.
  • A creation timestamp recorded by the device that built the receipt.
  • A self-attestation by the creator about the submission event.

What this receipt does not prove

  • That the institution actually received the submission. PlenaProof does not access the institution's records.
  • That the facts inside the receipt are true. The receipt is self-attested.
  • That the receipt is signed by an authority. The current reference implementation uses no signing key.
  • That the timestamp is anchored to an external clock or registry. The timestamp is taken from the device that built the receipt.
  • That any institution, regulator, court, or platform must accept the receipt as evidence. Acceptance is decided by the receiving party.

Truth-boundary preserved

PlenaProof does not replace authorities. PlenaProof records the accountable path around them. A Submission Receipt is an organised record of a service event, formatted for review. It is not a certificate, not a court filing, not a registered communication, and not an official acknowledgement of receipt by the institution.

Future production releases may add issuer signing keys, external timestamp anchoring (for example, OpenTimestamps or content-addressed deposit), a public revocation registry, and certified-issuer status. These remain roadmap items.

Show schema preview (technical)

Submission Receipt v1 inherits the established VRX-1 schema conventions. All keys are alphabetised before hashing; the hash field is computed over the canonical JSON with the hash field itself removed.


Build a Submission Receipt on this device

All processing happens in your browser. Nothing is sent to a server. The receipt JSON, hash, and verification URL are produced locally and can be exported, printed, or saved to the local Wallet preview.

Use a pseudonym if the public receipt should not name you directly.
If this receipt corrects or replaces an earlier one, name it here.
Privacy reminder. This page runs only in your browser. Nothing is uploaded. If you save the receipt to the Wallet preview, it is stored on this device only. Anyone with the JSON file can read its contents — redact private items before sharing.

Verify a Submission Receipt

Paste a receipt JSON or upload a .json file. The page recomputes the SHA-256 over the canonical JSON (with the hash field removed) and compares it to the hash stored inside the receipt. A match means the receipt content has not been modified since the hash was computed; it does not mean the facts in the receipt are true.

Saved on this device

Receipts you save to the local Wallet preview are stored only on this browser. They are not synced and not uploaded. Clearing browser data on this device removes them.

No saved receipts yet on this device.