A product-authentication architecture needs to explain what is checked, which records are stored and who can inspect them. The choice of ledger is only one part of that design.
Separate a tag check from a product record
Hashentic checks chip-specific authentication data for supported secure NFC tags. Its verification handlers record successful reads in the application database; invalid reads have their own logging path. This is different from claiming that every customer scan is written to a blockchain.
The platform also signs and submits product transactions to its configured Xordex service and retrieves those transaction records. Product pages can link to a configured blockchain explorer. The information visible there depends on the transaction and deployment.
A valid cryptographic response supports a conclusion about the registered tag. A transaction record supports a conclusion about recorded data. Neither independently establishes that a supplier's material or origin claim is true.
Compare the operating models
NIST distinguishes permissioned networks, where participation is controlled, from permissionless networks. These models place different responsibilities on participants and operators. Neither label removes the need to understand governance and trust assumptions. NIST's Blockchain Technology Overview explains these distinctions.
For a procurement review, ask each provider the same questions:
| Question | Evidence to request |
|---|---|
| What goes into the ledger? | An example product transaction and the fields it contains |
| What stays in the application? | Product fields, scan history and their retention configuration |
| Who can read and write? | Access rules for operators, customers and external reviewers |
| How are changes handled? | A correction example with the earlier record still identifiable |
| What does it cost to operate? | A proposal based on your transaction volume and hosting model |
| What happens when the service changes? | An export, recovery and domain-continuity plan |
Avoid comparing public-network fees with an assumed zero operating cost for a private deployment. Obtain a proposal covering hosting, support, backups and integrations as well as any transaction charges.
DPP requirements are a separate decision
Do not treat blockchain as a universal legal requirement for digital product passports. The ESPR framework introduces requirements through product-specific rules; choosing a database or ledger does not by itself establish compliance. Review the European Commission's ESPR overview and the rules applicable to your product.
Hashentic provides configurable product data and public passport output in JSON-LD. Your team still needs to define required fields, verify source evidence and test access. See the passport data-model guide.
Test the architecture with a real record
Create a product, attach a supported identifier, make a data correction and perform a scan. Inspect the product transaction and verification history separately. Then check which information appears on the public page and which information is restricted.
Repeat the exercise with a blocked identifier and a repeated cryptographic response. Agree what staff should see and which evidence they need to resolve an exception.
Explore the technology, compare the supported chips, or request a technical walkthrough using your own product data.
