Most Digital Product Passport Solutions Are Building on Foundations That Will Break. Here’s Why.

The race to build Digital Product Passport solutions is well underway. Dozens of platforms have launched or are launching, all promising to help brands comply with the EU’s ESPR mandate. From SaaS dashboards to enterprise traceability suites, the DPP market is growing fast.

But most of these solutions share the same fundamental flaw. They’re closed systems.

They store product identity data in proprietary databases controlled by a single vendor. They require every stakeholder to operate within one platform to access or update product information. And they create a dependency where the identity of a product, and every participant interacting with it, lives and dies with that vendor’s infrastructure.

For a regulation designed to enable transparency, circularity, and multi-stakeholder collaboration across entire product lifecycles, this is an architectural contradiction.

A DPP ecosystem has dozens of participants, not one

Think about who needs to interact with a single product’s Digital Product Passport across its lifetime. The brand that manufactures it. The raw material suppliers that fed into it. The logistics provider that shipped it. The retailer that sold it. The consumer that bought it. The repairer that serviced it. The recycler that reclaimed it. The regulator that audited it. The secondary marketplace that resold it. The AI agent that discovered it.

That’s at least ten distinct stakeholder types, often spanning multiple countries, industries, and technology stacks. And they all need to read from, write to, or verify the same product record at different points in time.

A centralised platform can serve a few of these stakeholders. It cannot serve all of them without becoming a bottleneck, a single point of failure, or a gatekeeper that dictates terms of access. The moment a brand’s product data is locked inside a single vendor’s database, every other participant in that product’s lifecycle becomes dependent on that vendor’s continued existence, pricing, and willingness to interoperate.

This isn’t theoretical. It’s the exact problem the ESPR was designed to prevent. Article 9 of the regulation explicitly requires DPP data to be structured in open, machine-readable, interoperable formats. The intent is clear: no single entity should control the infrastructure through which product data flows.

Why open and self-sovereign architecture matters

The argument for open, decentralised DPP infrastructure isn’t ideological. It’s practical.

Stakeholder sovereignty. In a properly architected DPP ecosystem, every participant owns and controls their own identity. A brand controls its brand profile. A supplier controls its supplier credentials. A consumer controls their ownership record. No single platform operator holds the keys to everyone’s data. This is self-sovereign identity applied to commerce, and it’s the only model that scales across a fragmented global supply chain without creating dangerous concentrations of control.

Verifiable trust without intermediaries. When a recycler scans a product to determine material composition, they shouldn’t need to trust the brand’s marketing claims or a platform vendor’s database. They should be able to verify the data against an immutable, tamper-proof record that no single party can alter after the fact. Open infrastructure makes this possible. Closed platforms make it a matter of faith.

Resilience and longevity. Products outlive platforms. A jacket manufactured in 2027 might be resold in 2032, repaired in 2035, and recycled in 2040. If the DPP solution the brand used in 2027 shuts down, pivots, or gets acquired, what happens to that product’s digital identity? On open infrastructure, the record persists independent of any single vendor. On a closed platform, it disappears with the company.

Regulatory alignment. The EU’s broader data strategy encourages publicly accessible, interoperable data ecosystems. The ESPR mandates open standards. Building DPP infrastructure on closed, proprietary foundations creates compliance risk the moment regulators enforce interoperability requirements more strictly.

The UX problem, and how smart contract accounts solve it

There’s a reason most DPP solutions default to centralised architecture: it’s easier to build and easier to use. Open, decentralised systems have historically been technically complex, difficult to manage, and hostile to everyday consumers. Managing cryptographic keys, understanding network fees, navigating unfamiliar interfaces. None of this works for a consumer scanning a QR code on a product they just bought.

This was a legitimate barrier. It’s no longer one.

Smart contract account standards have matured to the point where self-sovereign identity can be delivered with consumer-grade simplicity. The most advanced implementation of this is Universal Profiles, built on the LUKSO network.

A Universal Profile is a smart contract-based account that replaces traditional wallet complexity with a human-readable, upgradeable identity. It’s built from a modular stack of open standards (called LUKSO Standard Proposals, or LSPs) that handle identity metadata, permission management, asset ownership, and transaction notifications natively.

In practical terms, this means a brand, a consumer, a supplier, or a recycler each gets an identity on the network that they own and control. They don’t need to manage private keys directly. They don’t need to understand network fees, which are abstracted away entirely through relay services. They don’t need to interact with anything that looks or feels like traditional infrastructure complexity. They just scan, sign, and interact.

Interoperability isn’t a feature. It’s the entire point.

Building DPPs on open, standards-based infrastructure isn’t just architecturally cleaner. It unlocks an interoperability layer that closed platforms structurally cannot deliver.

Verifiable green finance. Green bonds and sustainability-linked lending instruments require auditable proof that products meet environmental standards. When DPPs carry verified, on-chain data about material composition, carbon footprint, and recycled content, financial instruments can be programmatically linked to real product-level evidence rather than aggregate self-reporting.

Granular warranty and returns infrastructure. When every individual product has a unique digital identity with a verified ownership record, warranty claims and returns can be processed at the item level rather than the SKU level.

AI agent interoperability. This is the one that changes everything. As agentic commerce matures, AI agents will need to discover, compare, verify, and transact products autonomously. They need structured, machine-readable, verifiable product data to do this. A DPP built on open infrastructure with standardised data schemas is natively interoperable with AI systems. A DPP locked inside a proprietary platform requires bespoke integrations that fragment the ecosystem and slow adoption.

The clock on closed systems is shorter than people think

Here’s the uncomfortable truth for every DPP solution built on centralised, proprietary infrastructure: the speed at which AI and agentic commerce are developing is compressing the timeline for architectural relevance.

When Google, Shopify, Mastercard, and Stripe are building open commerce protocols designed for machine-to-machine interaction, the direction is unmistakable. The infrastructure of commerce is converging on open standards, structured data, and verifiable identity. Solutions that don’t incorporate these concepts aren’t just suboptimal. They’re building on foundations that the market will route around within a year or two.

We’re building the Universal Goods Protocol on this conviction. Open infrastructure. Self-sovereign identity. Smart contract standards. Verifiable product data that works for regulators, brands, consumers, recyclers, and AI agents alike. Not because it’s the trendy approach. Because it’s the only architecture that holds up when you think past the next 12 months.