Enterprise

A digital product passport is useful only if its history can survive beyond the application that originally created it.

That is the problem being addressed by the BSV Blockchain Digital Product Passport standard, a public BSV Association project defining how product records can be created, updated, transferred, indexed and independently verified across applications and service providers.

The project remains a pre-1.0 working draft, but it has now moved beyond specification documents alone.

Its beta.7 reference packages were published on October 2, followed by updated overlay packages on October 2 and 3. Developers can use the current packages to build passport readers and writers, run an index, verify signed claims and work with product-data profiles for general products, batteries and textiles.

The distinction is important: this is not yet a finished industry standard, but there is now working infrastructure against which the proposed standard can be implemented and tested.

A Product History Built From Verifiable States

A digital product passport can contain information about a product across its lifetime: manufacture, ownership changes, repair, inspection, recycling and other events.

The BSV Blockchain DPP model separates that information into two main forms.

A passport state records product data and lifecycle changes. Each new state spends the blockchain output representing the previous state, creating a linked history in which conflicting updates can be detected.

An attestation handles a different situation.

A repair shop, inspector or other party may need to make a signed claim about a product without becoming the party that updates the passport itself. The signed claim can remain separate while a digest and identifying information are anchored to the blockchain.

That allows the passport history and externally issued claims to remain related without treating every inspection or repair as a new passport state.

Verification Is Intended to Travel With the Record

The more interesting architectural goal is portability.

A writer retains the transaction and its proof. An index makes passport records discoverable and can serve the transaction bytes and available evidence. A verifier can then check signatures, history links and blockchain inclusion against a block-header source.

The repository explicitly distinguishes this from simply trusting the application displaying the passport.

If the necessary transactions, proofs and off-chain material have been retained, the evidence can remain verifiable even if the original service provider later disappears.

That creates a different model from a conventional product database.

The database may help find and present the record, but it is not supposed to become the only place from which the record’s history can be established.

Readers, Writers and Indexes Are Now Available

The project currently publishes several reference packages.

@bsv/dpp-core provides the main reading, writing and verification functions for passport records, signatures, history, attestations and portable evidence.

@bsv/dpp-overlay-topics provides the indexing side, including passport lookup, evidence export and synchronization with configured peers.

@bsv/dpp-profiles supplies versioned product-data schemas and mapping helpers for areas including batteries, textiles and general products.

A separate @bsv/vsc package handles supported credential and interoperability work.

The documentation also separates the roles developers may implement themselves: a passport reader, writer, attestation issuer or verifier, registry, and index can each exist as a separate component.

That matters for interoperability because the standard is not intended to require every product-passport system to use one application or one backend.

Connecting With Existing Supply-Chain Standards

The project is also attempting to fit into existing product-information systems rather than invent an isolated data vocabulary.

Current interoperability work includes GS1 Digital Link identifiers and discovery, EPCIS 2.0.1 event import, selected W3C credential formats and deterministic passport projections.

Those bridges are potentially significant for supply-chain use.

Manufacturers, logistics systems and retailers already use established identifiers and event formats. A useful DPP infrastructure therefore needs to interact with those systems rather than require every participant to abandon existing product records and rebuild them around a blockchain-specific format.

The current work provides reference mappings and compatibility profiles, but these should still be understood as part of a pre-1.0 implementation rather than established cross-industry interoperability.

Cryptographic Verification Is Not Physical Truth

The project is particularly careful about one boundary.

A valid blockchain record can establish that particular bytes were signed, linked and included according to the supplied evidence.

It does not establish that the physical product is genuine.

It does not automatically prove that a manufacturer’s statement is true, that an inspector was legally authorised, that a QR code is attached to the correct physical object or that the provider has supplied every later claim that exists.

The identity documentation makes the same distinction. A valid key relationship does not by itself establish an accredited organizational identity, while a product identifier or DID does not automatically create a secure physical binding between the digital record and the object in someone’s hand.

This is an important limitation for any product-passport system.

Blockchain evidence can make the history of submitted claims difficult to alter unnoticed. It cannot determine whether the original physical-world claim was truthful.

Still a Working Draft

The repository describes the standard as pre-1.0, with breaking changes still expected.

Several important milestones also remain open.

Independent interoperability has not yet been completed. The project has an independent Python reader, but its own conformance documentation notes that it was produced within the same program, so organizational independence remains to be demonstrated.

Provider portability also remains unfinished. The next adoption milestones include independent implementations exchanging and verifying records, followed by migration testing that preserves history and authorized updates.

Legal identity assurance is currently described as Ring 0, meaning the system does not presently verify that a claimed brand corresponds to a legally established organization.

And there is no current integration with the European Union DPP Registry. The project therefore should not be described as demonstrating compliance with future or current EU digital-product-passport requirements.

Those limitations are not hidden in the documentation; they are explicitly tracked as part of the path toward version 1.0.

From Product Data to Portable Product Evidence

The significance of the DPP work is therefore not simply that BSV Blockchain can store information about manufactured goods.

Many databases can record a repair date, owner, serial number or recycling event.

The more interesting question is whether those records can remain independently checkable when they move between manufacturers, owners, applications, indexers and service providers.

The current DPP architecture is being designed around that problem.

Passport states preserve a linked lifecycle.

Independent parties can issue separate signed attestations.

Indexes make records discoverable without becoming the sole source of their validity.

Transactions and proofs can be retained as portable evidence.

Existing product-identification and supply-chain standards can be mapped into the same environment.

The standard is not finished, and several of its most important interoperability claims still need independent demonstration. But the newly published reference packages make the direction much more concrete: a product passport intended to remain verifiable beyond the application that first presented it.

Developer context

The Digital Product Passport project is maintained within the BSV Association’s bsv-blockchain GitHub organization. Its governance currently assigns maintenance responsibility to the BSV Association rather than naming a single individual project lead.

The repository brings together several reference components, including:

• @bsv/dpp-core — passport reading, writing and verification
• @bsv/dpp-overlay-topics — indexing, evidence export and synchronization
• @bsv/dpp-profiles — product-data profiles and mapping
• @bsv/vsc — credential and interoperability tooling

The project is published under the Apache License 2.0, and its specifications, fixtures and reference implementation are available publicly for independent implementation and testing. GitHub

Source Links

Digital Product Passport — Official Repository

Current Development Status and Limitations

DPP Identity, Control and Application Boundaries

BSV TIMES – Under the Surface

Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.

BSV TIMES – Under the Surface

Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.

Update — October 9, 2026