La donnée déclarée (nutrition, ingrédients, appellation…) reste chez le producteur — servie par l'application, et pour les pièces jointes éventuellement stockée en adressage par contenu (IPFS). Sur la chaîne, on n'inscrit qu'une empreinte de 32 octets, accompagnée d'un horodatage. Le rôle de la chaîne se résume à répondre, de façon infalsifiable, à une seule question : « ce contenu précis existait-il, et a-t-il été engagé, à cette date ? »

On calcule d'abord une forme canonique du JSON (JCS, RFC 8785) — mêmes octets quel que soit l'ordre des clés — puis son SHA-256. Le résultat, 0x… sur 32 octets, est l'empreinte. Pour un lot, on inscrit la racine de Merkle de toutes les empreintes du lot.

Ce que cela garantit, concrètement :

• Intégrité vérifiable — n'importe qui recalcule l'empreinte de l'e-label publié et vérifie qu'elle correspond à celle ancrée. Un seul caractère modifié (une valeur nutritionnelle, un allergène) change entièrement l'empreinte : la falsification est détectée mécaniquement.
• Preuve d'antériorité — l'horodatage on-chain prouve que la donnée existait sous cette forme à cette date. Décisif en cas de litige ou de contrôle.
• Vérifiable sans confiance — comme l'empreinte se recalcule par tous, personne n'a besoin de faire confiance au serveur XDCellar.

Les deux fonctionnent sur XDC Network, avec un miroir sur XRPL (mémo de transaction) — même empreinte, deux chaînes, pour la redondance de la preuve.

Le passeport de lot est un Verifiable Credential (VC) W3C 2.0, un document JSON-LD qui contient : la référence de lot, la racine de Merkle du lot, la liste des e-labels qui le composent (identifiant, nom, empreinte), les informations de registre, et — optionnellement — des événements de garde (traçabilité de la chaîne de possession). Il est signé avec la clé Ed25519 de l'émetteur, rattachée à une identité did:web publiée sur le domaine.

Son intérêt tient en trois points :

• Il agrège — un lot = beaucoup de bouteilles, mais une seule racine et donc un seul ancrage couvre tout le lot.
• Il se vérifie par des tiers — un labo, un certificateur, un importateur ou un acheteur vérifie la signature et l'émetteur (did:web) de façon autonome, avec des outils standards, sans appeler l'API XDCellar.
• Il porte la traçabilité — les événements de garde documentent la provenance ; et le passeport a lui-même une empreinte, elle aussi ancrable.

Sans clé de signature configurée, le passeport reste W3C-valide (non signé) et son empreinte reste ancrable — dégradation propre, jamais de blocage.

The declared data (nutrition, ingredients, appellation…) stays with the producer — served by the app, and for attachments optionally stored via content addressing (IPFS). On the chain, only a 32-byte fingerprint is written, together with a timestamp. The chain's whole job is to answer, tamper-proof, one single question: "did this exact content exist, and was it committed, on this date?"

We first compute a canonical form of the JSON (JCS, RFC 8785) — the same bytes regardless of key order — then its SHA-256. The result, a 32-byte 0x…, is the fingerprint. For a batch, we record the Merkle root of all the batch fingerprints.

What it guarantees, concretely:

• Verifiable integrity — anyone recomputes the published e-label's fingerprint and checks it matches the anchored one. A single changed character (a nutrition value, an allergen) completely changes the fingerprint: tampering is detected mechanically.
• Proof of anteriority — the on-chain timestamp proves the data existed in that form on that date. Decisive in a dispute or an inspection.
• Trustless verification — since the fingerprint recomputes for everyone, nobody needs to trust the XDCellar server.

Both run on XDC Network, with a mirror on XRPL (transaction memo) — same fingerprint, two chains, for proof redundancy.

The batch passport is a W3C 2.0 Verifiable Credential (VC), a JSON-LD document containing: the batch reference, the batch Merkle root, the list of e-labels in it (id, name, fingerprint), the registry information, and — optionally — custody events (chain-of-custody traceability). It is signed with the issuer's Ed25519 key, tied to a did:web identity published on the domain.

Its value comes down to three points:

• It aggregates — a batch = many bottles, but a single root, so one anchor covers the whole batch.
• Third parties verify it — a lab, a certifier, an importer or a buyer verifies the signature and the issuer (did:web) independently, with standard tools, without calling the XDCellar API.
• It carries traceability — custody events document provenance; and the passport itself has a fingerprint, also anchorable.

With no signing key configured, the passport stays W3C-valid (unsigned) and its fingerprint stays anchorable — graceful degradation, never a blocker.