Product-record mechanism
Understand the identifier, the public record and the limits of a match.
Local format demonstration
A record match would prove only that a serial exists in the register—not that the physical item is genuine. Serials and QR codes can be copied.
No register is queried. Do not use a generated example on a product.01
Identifier format
Proposed production format: ARV-{26 random Base32 characters}-{check character}. The example generator uses 128 random bits from Web Crypto, never a counter. Production issuance must use a server-side cryptographic generator and a uniqueness check. The current artwork serials are display references and will not pass this format.
A mod-37 check character is calculated over the random payload. It catches single-character substitutions and adjacent transpositions in that payload. It is error detection, not a secret or a digital signature.
02
The planned public response
Product, weight, fineness, issuance date, manufacturing date, public batch reference, certificate reference and status. Only approved public references belong in the response.
Never owner, purchaser, shipment, internal melt records or other internal production data. Do not embed these in QR payloads. Before launch, implement access controls, rate limits, audit logging and record lifecycle rules. Random serials reduce guessing; they do not replace these controls.
03
The physical-item limit
A record match establishes that a serial exists in the register. It does not establish that the physical item is genuine: the serial and QR can be copied. This limit must appear beside every future matching result.
Verification limitations ↗