Technical reference

A short code, signed and checkable at a glance

This page distinguishes the working website lookup code from the target production format. The twenty-byte scheme requires implementation and cryptographic audit; the example lookup does not validate real signatures.

Visible identity. Connected traceability.

Twelve features of the stamp.

The proposed stamp brings together each unit’s identity and medicine details. The QR opens its lookup; the barcode represents the example print sequence.

Illustrative Traza 120 ml oral solution label designed as one complete piece.
Label design concept. The functional QR and twelve fields are shown below.

The unit data, field by field

PUBLIC AND/OR PRIVATE COMPANY EXAMPLE
Unique identifier TRZ-7F2K-4K7Q-92FA
Destination territory Defined for each implementation
Medicine name Solución oral Traza
Net contents 120 ml
Dosage form and strength Oral solution
Not stated
Manufacturer or importer · health registration Laboratorio Cerro Alto
RS-EJEMPLO
Lookup website traza.technology
Print sequence 000001 Example print sequence
BarcodeCode 128
Issue date
Production batch LOTE-VS-26-012
Example data does not identify a commercial medicine or an existing institutional relationship. Territory and printing conditions are defined for each implementation. The label image is an illustrative concept, not a print-ready label or proof of physical security or fiscal validity. Looking up the QR does not certify the package contents.
  1. QR code

    Opens this unit’s public URL. A copy of the graphic retains the same identifier.

  2. Unique identifier

    The readable ID matches the QR and can be entered manually to look up the unit.

  3. Destination territory

    Defined for each implementation. This example declares no jurisdiction or actual territorial operation.

  4. Lookup website

    The visible domain shows where to look up the identity, including outside this page.

  5. Print sequence

    An example number for the printed piece. It is separate from the unit identifier.

  6. Barcode

    A readable Code 128 symbol encoding the example print sequence. It represents neither GS1 identification nor fiscal validation.

  1. Net contents

    Volume comes from the registered presentation: 120 ml for this unit.

  2. Medicine name

    The name lets people compare the package with the record of the unit being checked.

  3. Dosage form and strength

    Dosage form and strength matching the example medicine.

  4. Responsible party and health registration

    Manufacturer or importer and declared health reference. RS-EJEMPLO does not represent official approval.

  5. Issue date

    When the identity was issued. It is separate from production, activation or expiry.

  6. Production batch

    A separate field matching the batch of the unit being looked up.

Five requirements that settle the design

The working example uses the TRZ-XXXX-XXXX-XXXX format and a local record. The requirements below belong to the target design; they do not describe cryptographic checks performed by this website.

  • Unique at scale, with no central coordination

    Several processes must be able to generate identifiers in parallel without consulting each other and without risking a collision.

  • Not guessable

    Knowing one code must not let you derive others. A simple sequence would be enumerable: someone would print valid “future” codes.

  • Checkable without consulting the database

    The goal is to validate the signature before querying the registry. The scheme, keys, security and performance must be checked during implementation; this website does not perform that validation.

  • Short

    It has to fit in a small QR with enough error correction to tolerate scuffs, humidity and a curved label.

  • Readable by a person

    If the camera fails, the code is typed by hand on the lookup page. That forces grouped characters and a check digit.

Working lookup code on this website · example data
TRZ-7F2K-4K7Q-92FA
https://traza.technology/en/verify/?c=TRZ-7F2K-4K7Q-92FA&t=medicamentos

Anatomy of the identifier

The target format reserves twenty bytes in four parts. It is a design proposal awaiting validation, not the twelve-character format of codes that can be queried on this website.

  1. 1 byte Version
  2. 1 byte Key epoch
  3. 10 bytes Unique id
  4. 8 bytes Truncated signature
Version. Lets the format change later without invalidating what is already printed. Key epoch. Addresses the key it was signed with. Rotating keys does not invalidate history. Unique id. The issuance and the position within it, enciphered so they reveal neither order nor volume. Truncated signature. Field intended for an authenticator. The cryptographic scheme and its security require independent validation.
The byte layout does not establish security or constitute a verified ECDSA signature. A copy preserves the same identifier and does not create another unit. The final format and anti-copy measures require validation in each deployment.

From twenty bytes to something you can read and type

The target representation proposes Base32 Crockford with a typing-error check. The following block is illustrative: it is not a cryptographic test vector or a code recognised by this website’s registry.

In the target format, the check digit would be checked before a service lookup. This website’s reader checks the example identifier format; it does not implement that algorithm or validate a cryptographic signature.

The URL is uppercase on purpose. A QR’s alphanumeric mode encodes more information per module than byte mode, so the same content fits in a QR one or two versions smaller: it scans sooner and tolerates more damage. Scheme and domain are case-insensitive, and the server accepts the path in uppercase.

A short domain matters too: fewer characters mean fewer modules, and fewer modules let you print smaller at the same level of error correction.

Illustrative target format · not queryable on this website
TRZ-9FXK-2M4Q-J8TV-QH3N-7WPD-BL5R-XCK

URL inside the QR (uppercase, alphanumeric mode):
HTTPS://T.EXAMPLE/V/9FXK2M4QJ8TVQH3N7WPDBL5RXCK

The code is its own index

The target architecture proposes addressing the record from the identifier. The described benefits require implementation and measurement; they are not results established by this website.

The epoch addresses the key, so no keys have to be tried. The signature discards junk without touching storage. The embedded issuance points straight at the single record holding the passport. And the position within the issuance is the exact key of the row.

Nothing searches; everything addresses. That is the difference between a random identifier — which forces a database lookup even to discard junk — and a signed one, which decides valid or invented before asking anything.

A code’s validity is proved by derivation, not by a stored row. Issuing an order writes one record with its size and its state; the labels exist mathematically from that moment. The row for a specific label is born on its first lookup, so only the units somebody actually looks at take up space.

A practical consequence: reprinting a range years later produces exactly the same bytes. There are no lost codes, and an archived range that somebody looks up comes back to life without breaking the lookup.

Print specifications

There is no proprietary hardware: each issuer prints with its own infrastructure. What is fixed is the minimum that makes the code readable in a shop with bad light.

Symbology
QR model 2
The most widely supported standard in phone cameras.
Error correction
Level M minimum, Q recommended
Tolerates scuffs and dirt and still decodes.
Module size
≥ 0.33 mm
Below that, lower-end cameras start to fail.
Quiet zone
4 modules
The white margin is part of the code, not decoration.
Printed size
≥ 22 × 22 mm
A reference for a medicine bottle; validate it on the selected package and substrate.
Contrast
≥ 40 %
Measured on the real substrate, not on the designer’s screen.
Next to the code
Last characters in plain text
The fallback for when the camera will not cooperate.
Before the run, the issuer uploads a printed sample and the system checks it: it decodes the QR, measures quiet zone and contrast, and confirms the human-readable code matches. The approved sample stays linked to that issuance.

Templates and print outputs

The issuer picks a system template and does not edit the layout: the system injects the data. That way a label printed today and one printed next year are comparable.

  • Deterministic rendering

    The same code with the same template version produces a byte-for-byte identical file. Artwork need not be stored: it is regenerated.

  • For the print shop

    A vector imposition PDF, with cut and registration marks and bleed, to run full sheets.

  • For the production line

    Native thermal-printer language, to label in line at the machine’s own speed.

  • For overprinting

    A variable-layer-only output, when the security background is already pre-printed in offset.

Printing does not depend on the connection: the range is downloaded once and a local process feeds the printer, with its own queue and deferred reporting when it reconnects.

What comes next

The integration reference describes the target API. Public lookup lets you explore this website’s available example codes, with their results and limits explained.