A tamper-evident passport without a blockchain

On the jewellery platform, every piece carries a Digital Passport: origin, who made it, when it was certified, when it was hallmarked, when it sold. A customer opens it with a QR scan or an NFC tap and reads the whole history. The obvious question from anyone who has been near a pitch deck in the last few years is "so, blockchain?"

No. And I want to explain why not, because the reasoning matters more than the answer.

What we actually needed to prove

The real requirement was narrow: if someone edits a lifecycle event after the fact, that edit should be detectable. That is not the same as decentralised trust. There is one issuer here, the retailer, and the customer already trusts them enough to buy a gold necklace from them. Nobody needs a distributed ledger to remove a party that everyone already agrees is in charge.

What they need is a way to catch quiet tampering with the record.

Hash each event over its own fields

Every event stores a SHA-256 hash of its own contents. When the event is written, I hash the fields. When the passport is read, I recompute and compare. If a single character of a certification date was changed in the database later, the recomputed hash no longer matches the stored one, and the passport surfaces a tamper warning instead of pretending everything is fine.

function eventHash(e: PassportEvent) {
  const canonical = JSON.stringify({
    type: e.type, itemId: e.itemId, at: e.at, data: e.data,
  });
  return sha256(canonical); // stored with the event, checked on read
}

There are 23 event types across a piece's life, from sourced to manufactured to hallmarked to resold, and each one carries its own hash. An edit to any of them stands out.

The honest limits

This catches tampering, it does not prevent it. Someone with write access to the database could recompute the hash after editing the row, and then it would verify clean. If I needed to defend against a malicious insider with database access, I would chain each hash into the next so rewriting one means rewriting all of them, and sign the chain head with a key that never touches the app server. For a retailer proving provenance to a customer, plain per-event hashes were the right amount of engineering: verifiable, cheap, no tokens, no gas, no forty-second confirmation while someone waits at a counter.

The instinct to reach for the heaviest tool is strong. The better question is always what, exactly, are you trying to prove, and to whom. Answer that and the design usually gets smaller.