CHECKING

Cold-chain log integrity · NPRA GDP

Prove the log wasn't edited after the fact.

Immutal seals each day of temperature and handling records into one fixed-size commitment on Ethereum. Once that anchor is final, an auditor can detect any later change to those records with a static verifier and an RPC provider of their own choosing, without trusting the operator.

It shows records are unchanged since anchoring. It cannot show that a sensor read correctly, or that the data was honest when it was captured.

Request a pilot See how it works

Salted hashes, digests only on-chain
Verify with your own RPC provider
Built for Malaysia

SHP-KUL-PEN-0419 · REEFER-07

Vaccine vials, Kuala Lumpur → Penang

Live demo

Hashing…

on-chain: …
recomputed: …

Demo records are sealed in your browser with the real protocol. Demo salts are fixed so the page is reproducible; the service uses random 128-bit salts.

5,000of 5,000 edits caught

Five tampering classes, 1,000 mutations each. No misses, so the miss rate is under 0.3% at 95% confidence.

79,432verdicts, 0 mismatches

Python, a browser verifier and the transparency-dev reference library agree on every proof verdict.

≈71kgas per daily anchor

A fixed-size commitment per period, however many records it covers. Local chain; Sepolia figures follow.

0 of 10,000size forgeries accepted

A bare RFC 9162 proof check accepted 8,121 of them. Binding the size into the commitment rejects every one.

FYP1 reference run, 26 October 2026, on a local chain. Pass criteria and method are fixed in the threat model and evaluation matrix. Sepolia and pilot results follow in FYP2.

01 · The problem

A temperature log is only as trustworthy as whoever can edit it.

Distributors keep these records to show medicines stayed in range. Systems may keep an audit trail, but an outsider has to take the operator's word that it is complete.

The cards list scenarios Immutal is tested against, not statistics about any operator.

Excursions overwritten
A reading above range could be replaced with an in-range value after the fact, in a system the auditor cannot inspect independently.
EXCURSION_OVERWRITTEN
Gaps backfilled
Hours missing after a sensor drops offline could be filled in later with plausible readings.
GAP_BACKFILLED
Handling records rewritten
Receipt, dispatch or cleaning entries could be edited after an incident.
HANDLING_REWRITTEN
Audit trails held by the editor
An audit trail controlled by the administrator who can edit the data proves little to an outsider.
TRAIL_ADMIN_CONTROLLED

02 · How it works

Records stay with the operator. Only a commitment goes public.

Four steps, running in the background beside the systems you already use.

01
Capture
Readings and handling events arrive through an authenticated REST API. Each is checked and written in one canonical form (RFC 8785), so a reading always has the same bytes.
POST /records → canonical JSON
02
Salt and hash
Every record gets a random 128-bit salt and a SHA-256 leaf hash on the operator’s server. The salt keeps a proof for one record from revealing its neighbours.
sha256(0x00 ‖ salt ‖ entry)
03
Batch and anchor
A period’s leaves fold into an RFC 9162 Merkle tree. One transaction writes a 32-byte commitment to the root, the record count and a batch salt.
N records → 1 commitment
04
Verify
An auditor opens a static verifier page, supplies a bundle and a pinned dossier, and checks the commitment on-chain through an RPC provider of their choice.
bundle + dossier + own RPC

Why batch?

Anchoring each record on its own means one transaction per record. A Merkle tree folds a period's records into one root, so a single fixed-size commitment covers them all.

Each record can still be proven alone: its short path to the root is all an auditor needs. The cost comparison with per-record anchoring is part of the FYP2 evaluation.

Hover a reading to trace its proof. Click it to edit the value.

8 salted leaves → 1 root → 1 commitment

Hashing…

Each reading is salted and hashed into a leaf, and the leaves fold into one root. Only a 32-byte commitment to that root goes on-chain.

03 · What the auditor receives

One bundle, checked against settings the operator can't change.

The bundle carries the record, its salt, its path to the root and the settings the operator claims. The auditor checks it against a dossier received separately, which pins the chain, the contract and the anchoring address.

Every reading, excursions included
The record shows what was logged, not what anyone wished had been logged.
A commitment the chain can confirm
The auditor rebuilds the commitment from the bundle and finds it on-chain at the finalised block.
Verifiable without Immutal
A static page and an RPC provider of the auditor’s choice. No login, no database access, no wallet.

Design preview. The commitment and proof are real but not anchored. The report format is finalised with each pilot.

IMMUTAL

Certificate of data integrity

No. IMM-CERT-20260802-0419

Sample

Shipment: SHP-KUL-PEN-0419
Cargo: Vaccine vials
Route: Kuala Lumpur → Penang
Date: 2026-08-02
Sensor: REEFER-07
Required range: 2.0–8.0 °C

Temperature record · 8 readings
Time	°C	Status
09:30	4.2	in range
09:45	4.5	in range
10:00	5.1	in range
10:15	6.8	in range
10:30	9.8	EXCURSION
10:45	7.4	in range
11:00	5.2	in range
11:15	4.6	in range

1 excursion recorded and kept as logged. Once its period is anchored and final, any edit to this reading fails verification.

Commitment (the 32 bytes written on-chain): 0x99daa656c5385834b8816544faf9a45e369a500f73fdd5490c462a8d9b196051
Period · batch size · record · proof: 213 · 8 records · #4 · 3 hashes (96 bytes)
Chain, contract and anchoring address: Pinned in the audit dossier the auditor receives separately.
Verdicts a real certificate can show: VALID · PENDING · INVALID · CONSISTENT_OFFLINE · ERROR

SAMPLE

NOT ANCHORED

04 · Limits

What Immutal detects, and what it cannot.

The security claim is narrow: once a period's anchor is final, a later change to its records is detectable without trusting the operator. The threat model names eighteen attack classes (T1 to T18) and says which fall inside that claim.

Detected once the anchor is final

Edited, deleted, inserted, duplicated or reordered records (T1 to T3)
Forged inclusion proofs (T4)
Roots shown from another contract, chain or key (T7)
A lying RPC provider or altered verifier, through a second provider and a published verifier hash (T8)

Bounded, not prevented

Edits made before a period is anchored stay hidden until that anchor. The window is one period plus anchoring and finality time (T9).
A wound-back server clock: the anchor’s block time caps every receipt claim (T10).
Anchors lost to reorgs, fee spikes or outages: finality checks, capped retries, resends and alerts (T15).

Not detected, by design

Fabricated data at capture, or two sets of books (T11)
Collusion between operator and auditor (T18)
Sensor accuracy and calibration
Availability of off-chain records. An operator who refuses to produce one creates evidence of its own.

Prototype limits

The hot anchoring key sits in an environment variable. Production needs an encrypted keystore, a hardware module or a cloud key service.
Sepolia anchors carry no economic security, and the network itself faces replacement. Production use means mainnet or a layer 2.
The demo server and plain HTTP suit a demonstration only. Production needs a WSGI server behind TLS with rotated API keys.
The same contract cannot repair a period that a stolen key pre-empted. The service raises a critical alert and the admin revokes the key.

05 · Built for Malaysia

Evidence for the inspections Malaysian pharmaceutical distribution faces.

NPRA · GDP

Pharmaceutical distribution (pilot focus)

Distributors keep temperature and handling records under NPRA’s Good Distribution Practice guideline. Immutal gives inspectors and clients a way to check those records have not changed since anchoring.

PDPA 2010

Data-minimising by design

Only fixed-size digests go on a public chain. Records and salts stay on the operator’s servers, and a bundle shows only the record it proves, including any handler ID inside it.

Halal · extension

Halal handling logs

Segregation and cleaning logs use the same mechanism. They sit outside the current evaluation and follow the pharmaceutical pilot.

NPRA inspects. Immutal does not certify and does not replace inspection or certification. It strengthens the records an inspection relies on.

06 · Why it holds up

Proof that doesn't depend on trusting the operator.

Database log today

Whoever administers the database can edit a record, and an audit trail they control proves little to an outsider.
Evidence lives inside the system being audited.
Auditors have to trust the operator’s IT team.
Proving integrity can mean opening the whole database.

Immutal-anchored log

After the anchor is final, any edit to a record fails verification.
A fixed-size commitment lives on a public ledger the operator cannot rewrite.
Auditors run a static verifier against an RPC provider they choose.
A bundle proves one record and reveals nothing practical about the others.

What Immutal doesn't ask of you

No readable data on-chain

One 32-byte commitment per period. A random batch salt hides record volumes, empty periods included.

No wallets for your staff

The service holds a hot anchoring key and a cold admin key. Staff never handle tokens or gas.

No new software for staff

A background API beside the WMS, ERP or spreadsheets you already run.

07 · Integrations

Sits beside the systems your warehouse already runs.

Built in the prototype

REST ingestion API with API keys
Evidence bundle export per record
Batch and alert status API

Not built yet, ordered by pilot demand

FYP2Google Sheets sync and CSV / Excel import, tested against round-trip conversions
After the pilotTemperature logger gateways (HTTP / MQTT), Odoo Inventory
Out of FYP scopeCommercial ERP connectors such as SAP Business One, Dynamics 365 Business Central, AutoCount and SQL Account

Build WMS or ERP software?

Talk to us about embedding Immutal's integrity layer in your own product.

Partner with us

08 · Project status

Where Immutal is today.

BUILT
Anchoring contract
Append-only, role-split, no upgrade path. 24 Foundry tests, 100% line and branch coverage on a local chain.
BUILT
Service and verifier
Canonical entries, salted leaves, RFC 9162 batching, anchoring with retries and alerts, and a static browser verifier.
NEXT · FYP2
Sepolia soak test
Scripted deployment of the new contract, then a 30-day hourly run with injected faults.
OPEN
Pilot
Seeking one Malaysian pharma distributor or 3PL. Synthetic and public data are the fallback.

Check an anchor from the v0 prototype on Sepolia, which wrote one hash per record: 0xf5e4e4ca7ff05df7…7974fb37 ↗

09 · Run a pilot

Test it on one cold‑chain lane.

We're looking for a Malaysian pharmaceutical distributor or 3PL willing to share an anonymised export of temperature and handling logs under a data-sharing agreement. We seal it, try to tamper with it, and report detection per scenario and the false-alarm rate. Without a partner, we run the same tests on synthetic and public data.

Request a pilot Partner with us

azizi.sahari@unipact.com.my

Prove the log wasn't edited after the fact.

A temperature log is only as trustworthy as whoever can edit it.

Excursions overwritten

Gaps backfilled

Handling records rewritten

Audit trails held by the editor

Records stay with the operator. Only a commitment goes public.

Capture

Salt and hash

Batch and anchor

Verify