ReceiptReceipt
Back to blog

Open Receipt v0.1: Evidence That Travels With the Transaction

By The Receipt Team

Most digital receipts are just screenshots of someone else's database.

They may show what a platform says happened, but the customer, auditor, insurer, accountant, or another software agent still has to trust the platform that produced them.

Was the amount changed later? Was the transaction reversed? What evidence came back? Was the result merely delivered, or was it actually validated?

Usually, the answer is locked inside a private system.

Today, we are releasing Open Receipt v0.1: a small, open format for creating portable, cryptographically signed evidence of software transactions.

Download a signed transaction. Verify it locally. Change the amount by one cent. Watch verification fail.

Verify the sample →

A transaction should carry its own evidence

Software is beginning to make more commercial decisions on its own.

A workflow may purchase a web search, extract data from a document, send a message, publish an artifact, or call an external service. But the result usually arrives without a durable record of the commercial process around it.

Open Receipt represents that lifecycle as a chain of signed events, including:

quote issued
authorization granted
execution attempted
evidence returned
validation completed
settlement completed
reversal issued

Those events can be packaged into a portable Receipt and stored alongside the result itself.

The evidence no longer has to remain trapped inside the platform that executed the transaction.

Verify it without asking Receipt

An Open Receipt can be verified offline using the issuer's published public keys.

The verifier checks:

  • who signed the Receipt;
  • whether any signed field was changed;
  • whether the event hashes still match;
  • whether the links between lifecycle events remain intact;
  • what assurance and evidence support the recorded outcome.

You do not need to call Receipt's API and ask whether the signature is valid.

You do not need access to Receipt's private database.

You do not even need a Receipt account.

A signature proves the issuer and integrity of the claim. The Receipt's assurance fields describe what evidence supports it.

Delivered is not the same as validated

Most systems treat a successful HTTP response as proof that the work succeeded.

Open Receipt allows a transaction to say something more precise.

Delivered means the provider returned the contracted response.

Validated means a defined validator actually ran and passed.

That distinction matters.

A document-extraction result may be checked against a schema and source references. A screenshot may be tied to a URL, viewport, and image hash. Another outcome may only be verifiable as delivered.

Open Receipt does not force every transaction into the same definition of success. It records what was claimed, what was checked, and what evidence came back.

Try changing it

The fastest way to understand Open Receipt is to break one.

  1. Download the valid example.
  2. Verify it locally.
  3. Change the settled amount from $0.05 to $0.06.
  4. Run the verifier again.

The signature will fail.

Change the seller, evidence, status, or parent event hash and the result fails in the same way.

The transaction carries its own tamper evidence.

Why make it open?

Because a receipt only Receipt can verify is a database row.

A receipt anyone can verify is infrastructure.

Open Receipt defines the portable evidence artifact and its verification semantics.

Anyone can:

  • implement a verifier;
  • issue conforming Receipts;
  • store them independently;
  • attach them to accounting or audit records;
  • build additional tools around the format.

Receipt, the company, builds the commercial system around the artifact: runtime procurement, spending policy, approval, execution, validation, settlement, and seller distribution.

The evidence layer should remain portable.

What is available today

Open Receipt v0.1 includes:

  • a public specification;
  • JSON Schemas;
  • valid and tampered test vectors;
  • an Ed25519/JWS verifier;
  • issuer-key discovery;
  • an npm package;
  • public source code;
  • offline verification.

Install the verifier:

npm install @receiptprotocol/open-receipt

Then verify a Receipt inside your own application without contacting Receipt's servers.

Help us break it

Open Receipt is an open, versioned specification. The most useful response is rigorous implementation feedback.

We are especially looking for people to:

  1. Try to break the format. Find ambiguity, unsafe assumptions, missing events, or verification failures.
  2. Implement a verifier in another language. TypeScript is only the first implementation.
  3. Tell us what would block adoption. What would prevent an auditor, platform, workflow system, insurer, or independent issuer from trusting or producing an Open Receipt?

Open Receipt begins with a simple idea:

Evidence should travel with the transaction.
Back to blog