Internal verification surface

Attestation anchor proof

Every record below is an attestation this resolver received about one product. Where a record is anchored, its secured-byte digest and discovery metadata are committed to a BSV transaction. Verification compares the stored representation with that transaction from a public source. The commitment check does not establish credential authority, current status or confirmed chain inclusion.

Resolver

Reading mainnet

How the check works

  1. 01

    Received

    The registry verifies the submitted representation before storing it. Native claims use complete canonical signed bytes; VSC credentials retain their exact issued JSON bytes.

  2. 02

    Anchored

    The registry commits a digest and public discovery metadata to a transaction. The secured document stays off-chain. Issuer and product identifiers in the metadata are public.

  3. 03

    Commitment checked

    The digest is recomputed from the stored document, the raw transaction is fetched from a public explorer, and the two are compared. Credential proof, status, authority and inclusion require their own evidence checks.

How to read a Passport ID

The identifier heading each item below is a GS1 Digital Link: an identifier and a web address at the same time. The path segments are application identifiers, so any system that speaks GS1 reads the product model and the individual unit straight out of the string, with no documentation from us and no call to our API.

https://id.gs1.orgHost /01/ 09506000134352AI 01, GTIN, the model /21/ A01FD0168CDBAI 21, Serial, this unit

That GTIN is one of the numbers GS1 publishes for use in examples, and this demonstration mints every passport under it, so only the serial changes from one item to the next. Neither of those is a fault in the identifier.

The same path, under three hosts

https://id.gs1.org As printed /01/09506000134352/21/A01FD0168CDB

GS1's own resolver. It redirects only for links a brand has registered, and nobody has registered this one, so following it lands on GS1's own example product page rather than on this item. That is the identifier behaving correctly, not a fault. See what it does ↗

https://dpp.example-brand.com Example, not live /01/09506000134352/21/A01FD0168CDB

In production the code printed on the item carries the brand’s own host with the same path, and that host answers with the passport. The path does not change; only who answers for it does.

… This resolver /01/09506000134352/21/A01FD0168CDB

Since 29 July 2026 this resolver answers that address. A program following it gets each event's digest, the outpoint holding it and an explorer link; a browser following it lands on this page, narrowed to the one item. The identifier is still the storage key, so here the path and the key are the same string. Look it up

Two things are true at once. At the GS1 level the path is the identity, and the host is a resolver choice, which is why the same path reads the same under all three. Inside this resolver the stored key is the whole address, so a passport minted under a different host would be a separate record here.

Records