0016 Product provenance: one fingerprint per event record on the public ledger

This record answers five requests that provenance (Nodeone’s provenance service for physical products; the first pilot recreates a traditional liquor, 2026-10 to 2027-01) sent to hgp. The goal: anyone who scans the QR code on a bottle can check each event, from the rice harvest to bottling.

What

1. Only one fingerprint per event record on the public ledger

• Event records in product provenance may be put on a public ledger (a record book anyone can read, such as a blockchain) one by one. This is not anchoring (02-Fingerprint section 6, one daily root). It is a registry entry: the “registry on a public ledger” of sections 9 and 10 of HGP-0005 in the September specification, and the “registry” of 03-manifest section 9.

• Only three fields go on the chain.

  uint16  schemaVersion   version of the record's shape
  bytes32 recordHash      fingerprint of the whole event record
  refUID                  registry entry number of the previous record (a built-in EAS field)

• recordHash = the SHA-256 of the event record (public version), written as bytes by RFC 8785 (a way to always write JSON as the same bytes).

• The producer, the subject, the kind of event, when it happened, the fingerprints of the source photos and the fingerprints of private values all stay inside the record. They are not put out as separate fields on the chain. Field names inside the record follow 03-manifest and 06-Relation network: hgp, id, subject, event_kind, when, at, prev, parent, replaces, source (list of fingerprints of source originals, in order), source_root (the root of that list, 02-Fingerprint section 5), sealed (fingerprints of private values), scope, made_by.

• Fingerprints of private values are mixed with salt: SHA-256(32 random bytes ‖ value). Values with few possibilities, such as a temperature or a time, can be guessed one by one if only an unsalted fingerprint is published. The salt stays private together with the value. When the value is shown later, showing the salt with it lets anyone check.

• If a record points to two earlier records (the previous event of the same subject, prev, and the event of the parent subject, parent), refUID holds prev, or parent if there is no prev, and both are written inside the record. EAS has only one refUID.

• Only records whose scope is “public” go on the ledger one by one. A record that is not public must not even reveal that it exists (06-Relation network section 1, item 5). Such records go only into the daily bundle fingerprint (02-Fingerprint section 6). An “event with private values” (shown on screen as “recorded, private”) is a public event with only its values sealed, so it may go on the ledger. If even the fact that the event happened is to be hidden, the record is not public.

• The recipient (recipient) field is left empty (the zero address). No wallet address of a person or of the brewery is written.

• On withdrawal: when the depositor narrows the scope or withdraws (07-Deposit section 7), the record is closed on screen and in the store. The entry on the public ledger cannot be deleted, but it is a single fingerprint, so nothing can be learned from it alone. The schema is registered as revocable (revocable: true), and a withdrawn record gets an EAS revocation mark (the entry stays, with “revoked” and the time attached). The deposit agreement says in advance that “one fingerprint line cannot be deleted”.

• What we say in public: the public ledger proves that “this record existed at that time and has not changed since”. It does not prove that the liquor is genuine or that the record’s content is true (02-Fingerprint section 7). We do not say “tamper-proof” or “blockchain prevents forgery” (the “words not to use” of the September mapping to external standards).

2. Words

Word provenance used for now	hgp word	Field, basis
Product provenance (provenance)	Product provenance. Same meaning as provenance in W3C PROV-O, so there is no clash	PROV-O referenced
Event	Event. An event node in 06-Relation network (kind: "event"); its kind is event_kind: harvest, milling, intake, soaking, mash, second_mash, ferment_check, press, aging, discard, bottling, seal, label, open, transfer	Do not name the field event or eventType. event is the ledger action of 03-manifest (received, derived and so on)
Correction (supersedes)	Not an event. A new record points to the old one with replaces	06-Relation network section 4.1
Evidence	Source original. Photos and videos are deposited as originals (the authentic layer), and the event record points to them with source. The screen may still say “evidence”	06-Relation network section 4.2
Raw material unit, mash, bottle (lot, batch, bottle)	Lot, batch, bottle. Thing nodes in 06-Relation network (kind: "thing"). Bottles have serial numbers	September specification HGP-0004 section 8, “lot”, “serial number”
Producer	Not a new role. Owner and depositor (item 3). On screen, “producer”	07-Deposit section 2
Chain record (attestation)	Registry entry. Different from an anchor: an anchor is one daily root, a registry entry is one record	HGP-0005 section 10, 03-manifest section 9

3. Who is the depositor

• The brewery is the owner (owner) and the depositor. It owns the product and its process records, and it decides what to make public. The brewery is a group, so permissions attach to the representative’s position (07-Deposit section 6).
• The person who took a photo is its maker (made_by). Photos the brewery’s representative took and sent belong to the brewery. For photos taken by Nodeone staff, the copyright is on Nodeone’s side, so the agreement says “used as the brewery’s records” (rights.basis: "contract", 07-Deposit section 3).
• Nodeone is the store (administrator). Registering is work the brewery entrusted to it.
• Before the agreement, nothing goes on the ledger one by one as public. If the operator registers without an agreement, that is a stand-in depositor, and a stand-in cannot widen a scope to public (decision 0011). Before the first event record goes on the public ledger, there must be one deposit agreement from the brewery’s representative. It covers: the scope to make public, the values to keep private, that one fingerprint line on the public ledger cannot be deleted, and that permissions follow the representative’s position if the person changes. The agreement document is deposited as an original with a fingerprint (07-Deposit section 4).
• Form of the agreement: one sheet of paper signed or stamped by the brewery’s representative; its photo or scan is deposited as an original with a fingerprint. This meets 07-Deposit section 4. An “I agree” received by messenger can also be deposited as an original, but it is weaker proof of who sent it.
• The university is not a depositor. It takes part in events and checks sources.
• Other people who appear in photos or are named (farmers, workers and so on) are not depositors. Still, their consent is needed before publishing. This is the same rule as for other people’s voices (00-Principles section 4, 01-Permissions section 5). Consent is needed when a recognizable face or a name (including a farm’s name) appears on a public screen. Consent can be short (a one-line signature on paper, or a video taken on the spot saying “it’s fine for me to appear”) and is deposited as an original. Without consent, the photo is not made public, or only a copy in which the person cannot be recognized is public, and the person is written without a name, as “a farm”. The original stays as it is. The ledger records who consented, to what and when, like voices.
• Location data in photos (EXIF GPS) is removed from public copies. It reveals where a field or a house is. The original is not changed.

4. Signatures

• The operator wallet’s signature (secp256k1, the signature on a transaction sent to the chain) is the store’s signature: “Nodeone put this record in the registry at this time”. A person looks at a preview and approves each one, so this does not break 01-Permissions section 1, item 3 (machines do not sign).
• It is not the brewery’s signature. It does not prove “who made it” (02-Fingerprint section 7). The screen says “Recorded by: Nodeone”, and the will of the brewery and the university is shown by signed letters of delegation (deposited as originals with fingerprints). At the sales stage, when each party signs with its own key, that becomes “the maker’s signature”.
• “It goes up only when someone approves” is a promise, not a lock. The key is on the server, so the program could sign on its own. Following 01-Permissions section 1, item 4, we state this openly.
• The depositor signature of 02-Fingerprint section 8 (Ed25519, C2PA) stays open. secp256k1 is added as the signature method for registry entries.

5. Not a second layer 1, but a staging store

• The provenance ledger is the staging store of decision 0004 (store: "staging"). When it moves to arkive (2027-02), store: "arkive". This does not break 0004, so no exception record is needed.
• Four conditions:
  1. Ledger field names follow 03-manifest. The ledger must be exportable as JSONL lines in the 03-manifest shape (so they can be moved in as they are).
  2. Fingerprints are bundled as in 02-Fingerprint section 5: RFC 6962, leaves in their order, the last one is not duplicated when the count is odd. Sorting before bundling, or duplicating the last leaf, is not used.
  3. Originals are kept in two places (decision 0010).
  4. Originals (photo files) keep their names and EXIF unchanged. Reduced copies for the screen are kept separately.

Why

• The September specification already has a place for this. HGP-0004 section 8 “lot” (a record at each process step, serial numbers, a mark that is damaged when torn off, products point to the lot and the lot points to process records), HGP-0005 section 9 (“bundle a day’s or a session’s worth into one root”), section 10 registry (“anyone can read it, and no one can learn the content”). We aligned with these instead of inventing.
• Why we cut the fields to three:
  • A schema cannot be changed once registered. Fields inside the record can change by raising the version.
  • If the kind of event and the time it happened go out as fields, how many days passed from mashing to pressing stays on the public ledger forever. That is the “time” know-how that the provenance design wants to keep private.
  • If a producer number goes out as a field, all of that brewery’s products stay linked on the chain forever. Even if the brewery leaves later, the link cannot be cut.
  • An unsalted private fingerprint can be guessed.
  • The power to check is the same. The screen shows the record, and anyone can take its fingerprint again and compare it with the entry on the chain.
• The difference between personal records and product provenance is captured by “only records whose scope is public go up one by one”. Personal records are closed by default, so most go only into the daily root; product provenance is deposited as public from the start, so it goes up one by one. This is not a new principle; it applies the scope rule as it is.

Other options

Option	Why not chosen
The nine wide fields of the provenance design (producer, subject, kind, time, source root, private fingerprint, public or not and so on)	The timing of know-how, the producer link and unsalted private fingerprints would stay forever and cannot be deleted. The schema cannot be changed
Only the daily root (02-Fingerprint section 6 as it is)	Scanning one bottle could not check each event. The work’s purpose would fail
Write a new “physical product provenance” chapter (09) now	Writing the chapter before running the pilot means inventing. We start with this decision and write the chapter from experience when the pilot ends (2027-01)
Make provenance an exception as a second layer 1	The staging store of 0004 is enough. More exceptions would blur “one store”

What it affects

• provenance:
  • EAS schema uint16 schemaVersion, bytes32 recordHash, revocable: true, recipient the zero address. The record fingerprint is taken from bytes written by RFC 8785.
  • Salt in fingerprints of private values.
  • Merkle by RFC 6962 (with no sorting and no last-leaf duplication).
  • A deposit agreement from the brewery’s representative before the first public registration.
  • If the agreement is not yet in place, use the manual method of the design document: put up only one root that bundles the fingerprints of that day’s photos. Only the root and the time go out, which is exactly the anchor of 02-Fingerprint section 6 and is allowed under the current specification. After the agreement, event records are created and that root is linked as the source for “when first anchored”.
• hgp: applied (2026-10-13): 02-Fingerprint sections 6 and 8 (v0.4), 03-manifest section 9 (v0.6), 05-Glossary section 11 (v0.2), 06-Relation network section 5 event_kind (v0.4), 07-Deposit section 7 (v0.2). The rule table and the name file are not changed in v1; these go into v2. When the pilot ends, chapter 09.
• arkive: receives the provenance ledger in 2027-02, keeping record fingerprints and registry entry numbers as they are.
• secretary: nothing. Recordings that are not public go only into the daily root.

Cost

Only chain fees (gas). By the provenance design’s estimate, a few thousand won for the whole pilot (100 to 200 events). Fewer fields make it a little cheaper.

Corrections (2026-10-13)

• “Merkle by RFC 6962 (sorting, removing last-leaf duplication)” was corrected to “(with no sorting and no last-leaf duplication)”. The meaning was always the same as condition 2 of item 5.
• rights.basis: "agreement" in item 3 was corrected to "contract", to match the value labels of 03-manifest.
• The parent field and the salt sentence are replaced by decision 0017 (parents, sealed root per item).
• The number of “chapter 09 when the pilot ends”: 09 was taken first by the keys document (decision 0018). The product provenance chapter gets its number when it is written.