Authenticity verification: where product tracking breaks down
Product authenticity verification does not break down at the stage of printing the code, but at the moment a batch is handed over between participants in the chain.
The manufacturer issues the labeling, logistics accepts it against a paper act, the warehouse enters the data into the accounting system manually — and at every junction a window appears where a counterfeit batch passes as a legitimate supply.
Duplicate serial numbers surface only on the shelf: the distributor's scanner sees two identical codes in different regions, but there is no way to prove which one is the original.
The cost of such a scheme is visible in operations. Returns and quality claims are growing because the support service cannot confirm the origin of a specific unit of goods — there is no linked history from factory to counter, only shipping documents.
Retail blocks the supplier entirely, even though the problem lies in a single substituted batch, not in the channel.
At the same time, the share of manual entry during receiving is growing: the warehouse operator checks SKUs by eye, errors accumulate, and origin tracking diverges from the physical goods within just a few cycles.
A separate point of failure is relabeling. If a code can be reprinted and stuck onto another batch, then any check on the shelf relies on a paper medium rather than on an immutable record.
Counterfeiting a batch in such a model does not require hacking the system: access to a label printer and one trusted account is enough.
Let's break down how this is closed: exactly where in the "manufacturer — logistics — shelf" chain an immutable mark is placed, how it is linked to the serial number, and what the verifier sees when scanning.
How blockchain authenticity verification works
Tag, record, verification: what the system consists of
An NFC tag with a cryptographically protected identifier is applied to the item — it cannot be copied by rewriting and cannot be counterfeited by duplication.
When a batch is released, a record is sent to the blockchain product registry: the hash of the item's digital passport, the batch, the date, the manufacturer.
From then on, the tag and the record are linked one-way — the record can be found by the tag, but the record cannot be altered to "match" a copy of the tag.
Authenticity verification by the buyer takes seconds: reading the tag with a smartphone, querying the registry, comparing the hash.
If the tag has been cloned or the passport has been swapped, the comparison fails — the buyer sees a status, not a "green checkmark." It is precisely the immutability of records that turns verification from trust in a sticker into verification against a record that no one, including the manufacturer, can quietly rewrite.
System architecture options
| Option | When it fits | Limitations |
|---|---|---|
| Public registry | Independent third-party verification is needed, brand protection | Cost of recording, public nature of metadata |
| Closed consortium registry | Multiple manufacturers, a shared supply chain | Requires participants' agreement on the rules |
| Hybrid: hashes in the registry, data off-chain | Large volumes, sensitive data | Separate protection of external storage is needed |
The choice is dictated not by fashion, but by who must verify authenticity and how: the buyer, customs, a supply chain partner. Each scenario has its own access scheme and its own level of data disclosure.
Hyperledger Fabric — one of the reference stacks for closed registries: it provides controlled participant access and predictable throughput when releasing batches.
Stages of verification system implementation
Implementing an authenticity verification system is not about installing equipment, but about restructuring marking and traceability processes.
We start with an audit: we look at where the label appears in the current chain, who reads the data and at which stage, and which events are even worth recording in the registry.
Without this stage, any automation reinforces existing gaps — for example, when a batch goes to a distributor before a record of its release appears in the system.
- Audit of marking processes. We analyze the movement of goods from production to the shelf: label application and reading points, employee roles, bottlenecks where data is lost or duplicated.
- Designing the registry data schema. We determine which events are written to the blockchain (release, shipment, acceptance, sale), which remain in the internal system, and how the identifiers of the label and the digital passport of the product are linked.
- Configuring labels and readers. We select the type of carrier for the packaging material and operating conditions, configure readers on production lines and at acceptance points, and check reading accuracy on real samples.
- Deploying the registry and integrations. We set up nodes, configure access rights for supply chain participants, and link the registry to the customer's accounting system so that records are created automatically rather than manually.
- Testing on a pilot batch. We run a limited volume of goods through the entire chain, reconcile records with actual movement, and test forgery and label reuse scenarios.
- Training and system handover. We prepare instructions for operators and the support service, hand over documentation, regulations, and access credentials, and support the first batches in production mode.
The key readiness criterion is not a launched registry, but reproducibility: the pilot batch passes through the chain without manual adjustments, and the customer's service can independently perform an authenticity check and investigate an incident. Describe your supply chain — we will come back with an assessment and a stage-by-stage plan.
How is a blockchain registry different from an ordinary database?
In an ordinary database, a record is changed by whoever has access to the server and write permissions.
As long as the parties trust the owner of the system, this is enough: transactions are fast, the schema can be modified on the fly, and the change history is kept by the administrator.
The problem begins where verification of authenticity is needed by a third party — a buyer, a regulatory authority, a counterparty — and that party has no trust in the database operator.
A centralized ledger can be edited after the fact, and an external participant cannot tell an edit from the original record.
A distributed registry changes the very model of rights. A record of a product's origin is confirmed by several independent nodes, and to rewrite the history you need the consent of the majority of them, not access to a single server.
Every change leaves a cryptographically linked trace: the previous state cannot be substituted without recalculating the entire chain.
This is precisely the proof of origin — not because it is "blockchain," but because the verifier can recalculate the hashes themselves and confirm that the data has not been touched.
For auditing changes, this provides an important property: the ledger is immutable and identical for all participants. The regulatory authority, the manufacturer, and the seller see the same picture, and a discrepancy between their copies immediately signals an attempted forgery.
In disputes with a counterparty, there is no need to dig up correspondence and internal logs — it is enough to present the record and its verification.
But a distributed record is more expensive to operate: writing is slower, the volume grows, and erroneously entered data cannot be corrected — only a corrective record can be added.
That is why it is adopted not "instead of a database," but selectively: only what must be provable and immutable goes into the registry — the batch identifier, the transfer event, the NFC tag, the link to digital proof of ownership.
Everything else — the catalog, stock levels, logistics — remains in an ordinary database, where edits are cheap and fast.
The practical rule is simple: if the data is changed by a single operator and no disputes arise over it, a central database is enough. If the record must be evidence for external parties and survive a change of the system's owner, its place is in a distributed registry.
Case: Batch labeling and return reduction
A clothing manufacturer came forward with a typical pain point: up to a third of returns in retail were due to "item didn't fit," but in half of those cases a counterfeit was found in the returns warehouse — the same model, but not their production.
It was impossible to distinguish it from the original by tag and packaging during receiving, and disputed claims from marketplaces took weeks to resolve: neither party had an evidence base.
What we did
On a pilot category — three outerwear models — each unit received an NFC tag linked to a record in a blockchain-based registry.
The tag stores the batch identifier and a unique instance number; the registry stores the history: who released it, when it was shipped, which warehouses the unit passed through.
Counterfeiting the tag is pointless: verification is not based on the sticker, but on matching its identifier with a record in the registry that cannot be rewritten retroactively.
Receiving at the warehouse stopped being an expert examination. A warehouse worker taps a phone — the system responds within seconds whether it is an original or not, and shows the item's path.
A disputed unit goes to a separate zone with an automatically generated report: it records the identifier, the verification time, and the discrepancy with the registry.
Metrics before and after
| Indicator | Before the pilot | After the pilot |
|---|---|---|
| Return rate for the category | baseline | decreased by roughly three times |
| Unit verification time at the warehouse | 3-5 minutes manually | 5-10 seconds |
| Disputed claims from marketplaces | dozens per month, resolution took weeks | a few, closed within a day |
| Confirmed counterfeits in the return flow | not identified | recorded at receiving |
What produced the effect
The key was not the blockchain itself, but the combination of "tag + registry + receiving procedure." The registry provided an immutable history — a claim became impossible to dispute.
The tag eliminated manual examination — verification no longer depended on the shift's qualifications. The procedure closed the process: every mismatched unit automatically goes into a report instead of being set aside "at discretion."
NFC Forum describes the tag standards that we rely on when selecting a carrier for a specific product category.
Doubts before implementation: compatibility, migration, rollback
Authenticity verification almost never starts from a clean slate: the customer already has an accounting system, a warehouse loop, and its own rules for data access.
Therefore, the first question at the start is not "which blockchain," but how the new loop fits into what is already working, and what will happen if the solution has to be stopped. Below are answers to the technical doubts that most often come up before signing.
What if the accounting system is incompatible? Integration goes through an exchange layer: issuance and shipment events leave the accounting system, and verification statuses come back.
If the system has a software interface, we connect directly; if not, through an intermediate scheduled export. The accounting system remains the source of truth for goods movement, and the blockchain for label history.
How is the accumulated database transferred? Migration proceeds in batches: first reference data and nomenclature, then balances, then transaction history.
Each batch is reconciled by checksums before and after loading, and discrepancies are resolved before moving on to the next one. Historical records are marked as restored — they cannot be confused with events recorded in the new loop.
Is rollback possible? Yes, the rollback plan is laid out before launch: labels at this stage remain readable, and verification continues to work in autonomous mode.
Returning to the previous process does not block shipments and does not require re-labeling of already released goods.
Who gets which access rights?
Roles are separated on the principle of least privilege: the operator issues labels, the storekeeper confirms acceptance, the inspector sees the history but cannot change it, the auditor gets read-only access. Every action is signed and remains in the log — a record cannot be substituted after the fact.
What the customer receives:
- integration layer configurations and field mapping rules;
- data flow diagrams between the accounting system, labels, and the registry;
- a role matrix and access policies with a description of permissions;
- an authenticity verification regulation for the warehouse, retail, and control service;
- instructions for issuing and reissuing labels in case of defects and returns;
- a rollback plan with decision points and a procedure for actions;
- documentation for maintenance and incident handling.
Describe your accounting system and current acceptance process — we will come back with an assessment, an integration scheme, and a migration plan for your loop.
Implementation timelines by stage
Timelines depend not on the volume of code, but on how quickly the marking model can be agreed upon and access to the accounting systems obtained.
Below is an approximate sequence through which the implementation of an authenticity verification system proceeds: from assessment to handover into operation.
The duration of each stage is given for a typical project with one production line and one warehouse; with multiple sites, the stages run in parallel and the overall timeline stretches non-linearly.
The pilot launch deliberately comes before scaling: on a limited batch it is cheaper to catch a desync between label issuance and shipment than to stop the line at all sites.
If the accounting systems are closed to integration, the setup stage gets longer — some of the checks are then built on scheduled exports rather than direct exchange.
What if we have several production sites? The design and setup stages run in parallel across sites, but we launch the pilot at one — this way scaling relies on an already proven scheme rather than assumptions.
What if a fast launch is needed? We shorten not the stages but their depth: we start with one product category and a minimal set of checks, and add the rest after the environment has completed a full cycle.
Describe your task — we will come back with an estimate and a plan for your sites.