Sealed receipts

A redemption is not a row we could quietly edit. It is an event on an append-only chain: each event’s hash covers the payload, the previous hash and its position, so changing anything breaks every event after it — and the chain is anchored outside the database that stores it.

What your receipt carries

{
  "redeemed": true,
  "alreadyConfirmed": false,
  "voucherInstanceId": "…",
  "verifyUrl": "https://api.bullmark.net/integrity/events/VoucherInstance/…"
}

verifyUrl needs no key and returns hashes and verdicts only — no payloads, no redeem codes. Anyone you show it to can check that the chain holds. Store it against your order if you want a customer-facing proof.

What is in the sealed payload of a redemption

Your own externalRef, the reservation ticket, and which key or person confirmed. That is deliberate: it ties your order record to our burned voucher inside the thing that is sealed, so an auditor reading the chain can land on your invoice without either side being asked to be believed.

What is not sealed

The reservation itself. A ticket that lapses asserts nothing — it is a lock, not a claim — and anchoring one per checkout attempt would fill the chain with events that prove nobody anything. The reservation window shows up as VCH040/VCH041/VCH042 on the voucher’s own chain, which is where you would look to answer “why was this locked on Tuesday”.

Verifying it yourself

See Verify the seal yourself. The SDK recomputes the hashes on your machine; the algorithm and its conformance vectors are published so you can do it in any language.