The data-integrity layer for the Digital Product Passport
LKS Trace does not replace your ERP or MES. It adds the one thing they cannot provide on their own: cryptographic evidence that the declared data has not been altered after the fact, and that a specific organisation attested it on a specific date.
Not “blockchain for the supply chain”
That formula has already been rejected by the market, and rightly so. The commercial driver for traceability over the coming years is regulatory, not technological.
Regulation (EU) 2024/1781 (ESPR) reached full application in July 2026, with the launch of the European Digital Product Passport registry. Obligations enter into force progressively by product group through delegated acts — batteries first, on a fixed date in February 2027, with the remaining categories staggered through 2030.
Being honest about the boundary
The DPP specifications do not require the use of a blockchain. Claiming otherwise would be a sales tactic, not an argument.
The value LKS adds is not being the registry of the data. It is making it demonstrable that the data was not altered after it was declared, and that a specific party attested it at a specific time.
That distinction is what allows LKS Trace to sit alongside a DPP platform instead of competing with it.
The lot history is the product
The distinctive value is the reconstruction of a lot's history, not the recording of a code. That is what allows tracing a finished unit back to its raw materials — and supporting targeted recalls instead of blanket ones.
raw material
│
LOT A
│ transformation
LOT B
├─ split → LOT B1
└─ split → LOT B2
│
packaging
│
LOT C
│
shipment / receipt
│
customer
Events
Every significant event produces a verifiable proof. Complete industrial data can remain inside your systems; LKS records the cryptographic proof of the event.
CREATE UPDATE TRANSFORM SPLIT MERGE QUALITY_CHECK CERTIFY SHIP RECEIVE RECALL VERIFY
Targeted recall
When a defect is found, the genealogy identifies exactly which downstream lots are affected — and, just as importantly, which ones are not.
Standards-first lot identification
The market standard for product identification and QR resolution is GS1 Digital Link, with GTIN as the identifier — recognised as a valid pattern within the European Digital Product Passport framework. A proprietary identifier would exclude LKS Trace from any structured supply chain and from every tender where standards compliance is a requirement.
| Field | Description |
|---|---|
lot_id | Unique identifier, aligned to GS1 (GTIN + batch/serial) |
product_code | Product code |
production_date | Date and time of the production event |
quantity / unit | Quantity and unit of measure |
facility | Plant or site |
organization | Party recording the event (DID or verifiable identifier) |
parent_lots | Source lots, where applicable |
child_lots | Derived lots, where applicable |
metadata_hash | Canonicalised hash (JCS, RFC 8785) of the extended data held off-chain |
certificate / txid / block | Ledger references |
anchor_ref | Reference to the Bitcoin anchor (.ots file) |
One QR code, one verifiable answer
Every lot and every certificate is bound to a QR code following the GS1 Digital Link scheme, so it stays compatible with the resolution systems already deployed across retail and distribution.
Scanning opens a verification page that shows only the information the company chose to publish, together with the ledger proof.
QR (GS1 Digital Link) → LKS Verify ├─ lot / product ├─ status ├─ publishable events ├─ certificates ├─ ledger proof (TXID + ChainLock) └─ Bitcoin anchor (.ots)
API-first, designed to sit behind your systems
LKS Trace is built to integrate with existing industrial software rather than to be operated as yet another interface for shop-floor staff.
ERP / MES / WMS
│
LKS API
├─ createLot() ├─ mergeLots()
├─ updateLot() ├─ qualityCheck()
├─ transformLot() ├─ shipLot()
├─ splitLot() ├─ receiveLot()
└─ verifyLot()
│
LKS blockchain
What goes on the ledger, and what never does
Storing industrial files, documents or large volumes of data directly on a public ledger is the wrong architecture — technically, commercially and under data protection law.
On-chain
Hashes, timestamps, identifiers, references, status and the minimum necessary metadata.
Off-chain
Documents, sensitive data, images, files and datasets — held at the company or at the service.
Verification compares the available content against the recorded hash. Decentralised storage can be evaluated at a later stage, but it is deliberately not a prerequisite of the first release.
The client we are looking for
- A manufacturing or agri-food SME with a short supply chain and traceability obligations that already exist.
- An ERP or MES exposing an API, so the pilot does not turn into an integration project.
- A problem already felt internally: lot recalls, quality disputes, documentation requests from end customers.
- A motivated internal sponsor. Without one, a pilot dies regardless of its technical quality.
On the competitive landscape
Alternatives exist and it would be dishonest to pretend otherwise: established notarisation services, qualified trust service providers offering low-cost timestamping, and vertical traceability platforms. A detailed competitive analysis is work to be completed before commercial activity begins.
The defensible differentiator of LKSCOIN is the combination of public verifiability, external anchoring and low marginal cost at high event volumes — not a claim of being the only option.
A working beta you can try right now
Record events, follow a lot through a split, and see which downstream lots a recall would touch. The sample supply chain is built with one click and writes real proofs to the chain — nothing here is a simulation. What follows next is an industrial pilot, alongside a real production line rather than after one.