Signed unit-level identity
Each unit receives a unique identifier, signed by the manufacturer or importer that places it on the market.
Unit-level identity and public verification for a regulated spirits market
Traza’s first use case proposes giving each bottle a signed identity, recording its lifecycle from issuance through every lookup, and letting anyone verify it from the browser.
This case is presented as a pilot proposal addressed to a spirits regulator. It does not describe an official implementation, does not imply a contractual relationship and does not claim the participation of any agency.
The problem it sets out to solve
In a regulated spirits market, units circulate whose identity cannot be checked. Control usually relies on documents, seals and lots; a carefully copied label passes as legitimate and a diverted unit leaves no trace.
Field inspection faces a volume it cannot cover without signals to guide it. Teams go where they can, not necessarily where they are needed, and what they observe is rarely linked to the unit’s registry record.
The public, for its part, has no simple way to verify what it buys. Tools that require installing something or creating an account are not used at the moment of purchase. The proposal starts from that reality: web-based verification, with no installation or account, at the point of sale.
Proposed scope of the pilot
The pilot is proposed with a narrow scope: a set of products, a small group of chain actors and a defined period, with field inspection included from the start.
-
-
Labeling with a verifiable code
The identifier is added to the label or seal as a code readable by the camera of any phone.
-
Chain event recording
Issuance, labelling, activation of the lot record and every public lookup are recorded in order.
-
Web-based public verification
Anyone verifies from the browser and receives a result explained by signals, with the regulator’s context.
-
Field inspection
Inspectors verify on site, check against the registry and record what they observe within the pilot itself.
-
Discrepancy reporting
Whoever detects a difference between the unit and the registry can report it with minimal, optional data.
Who takes part
The proposal describes six roles. Each one sees the registry with the level of detail that corresponds to it.
-
Spirits regulator
Defines the framework, governs the registry, follows anomalies and reports, and directs field inspection. In the proposal, this role corresponds to the recipient of the pilot.
-
Manufacturers and importers
Issue and sign the identities of their units and report factory dispatch or entry through customs.
-
Carriers and distributors
Request issuances, apply the labels and close the lot record, which is what activates the codes.
-
Points of sale
Record the arrival of units and make the code available to the public.
-
Field inspectors
Verify on site, check the physical unit against the registry and document what they observe.
-
The public
Verifies at the point of sale, reads a clear result and reports if something does not match.
Target architecture
The proposal describes the architecture the pilot would be designed toward. It is presented as a target, not as a built system.
-
Unit-level identity signed with ECDSA P-256
Each identifier is signed with elliptic-curve cryptography (ECDSA P-256) using keys managed by the issuer. It is proposed as the standard for the use case.
-
Web-based public verification, with no installation or account
A web service evaluates signature, registry status, data match and anomalies, and returns an explained result.
-
Chain event registry
An ordered, auditable registry of each unit’s events, with responsible party and date, exportable for audit.
-
Field inspection within the pilot
Tools for inspectors to verify on site and record observations linked to each unit.
-
Discrepancy reporting
A public channel to report differences between the unit and the registry, with minimal, optional data.
Target architecture for the proposal: not implemented yet. Its development and audit form part of the scope that would be agreed with the institution.
Field inspection is part of the pilot
The proposal does not defer field inspection to a later phase: it includes it from the start. Signals from the registry guide the teams, and what they observe on site flows back into the registry. What arrives later is the dedicated inspector application; at first the work is done with the same web pages and the institutional views.
- On-site verification with the same web page the public uses, with additional views for the inspector
- A record of each inspection linked to the unit and the point of sale
- Prioritization based on anomalies and discrepancy reports
- Feedback into the registry: what is observed in the field updates the status of the unit
Conditional co-brand
The proposal envisions public verification showing the regulator’s brand alongside Traza’s. That lockup appears only within this use case and its sample tenant, as an illustration of how a co-brand deployment would look.
The “SENIAT | TRAZA” lockup is an example of a conditional co-brand included in the pilot proposal. It is shown in typographic form, without any official emblem, and its use depends on the institution’s approval. It does not imply an official relationship, endorsement or approval.
Alcoholic beverages
Example co-brand for a pilot proposal. It does not imply an official relationship, approval or implementation.
The tenant lockup shown is a co-brand example included in a pilot proposal. Its use is subject to approval by the corresponding institution and does not imply an official relationship, endorsement or approval.
What this proposal does not claim
To avoid confusion, we put in writing what this page does not say.
- It does not claim that an official implementation or a working system exists.
- It does not claim a contractual, commercial or institutional relationship with SENIAT or any other agency; SENIAT is mentioned only as the recipient of a pilot proposal.
- It does not present pilot figures: quantities, timelines, costs or results.
- It does not claim production-grade security: the architecture described is a target whose implementation is audited in each deployment.
- It does not offer legal or regulatory conclusions; the proposal does not replace the regulatory analysis that may be required.
- It does not authorize the use of any institution’s brand or emblem; the lockup shown is a conditional example.
See the use case in the platform
Public verification with the sample tenant, the journey of a bottle and the institutional view show how the pilot would look.