Phygital Assets
Connect an object to its digital history.
A phygital asset pairs a physical object with a digital record that describes it, shows where it came from and, where the design calls for it, carries ownership or licensed digital content. ColdAI's phygital framework uses NFC chips, QR attestations and supply-chain oracles to tie each object to its on-chain identity. The token is rarely the hard part. The binding is: enrolling every item through a trusted process and being honest about what a scan can prove.
The opportunity
Start with a decision
worth improving.
A customer scans a product and wants to understand its origin or entitlement. The system must connect the scan to an authoritative record without assuming that a copied label proves authenticity.
From possibility to a working system
Follow the flow.
Three connected decisions. One considered architecture.
Conceptual flow, not a live system or measured result.
Bind the identifier
Choose an identification approach suited to the object and threat model. Define manufacturing or enrollment controls so the initial digital record is attached through a trustworthy process.
Make the interaction useful
Connect a scan or device interaction to the relevant product history and experience. Validate the request and present evidence in language the owner, customer or operator can understand.
Maintain the history
Track authorized changes such as ownership, service or retirement. Define how lost identifiers, replacement objects and disputed records are handled without silently rewriting the provenance trail.
The work, made concrete
What we can build
with your team.
We agree scope, dependencies and acceptance criteria before delivery. Your project can start with an assessment, a pilot or an integration into an existing system.
Physical-to-digital identity architecture
Clarify the system boundary, the responsible owners and the decisions the architecture needs to support.
Scan and provenance experiences
Turn the agreed design into reviewable work, evaluated against representative inputs and explicit success criteria.
Lifecycle and exception workflows
Make the next step operable: document responsibilities, known limitations and the path from pilot to ongoing use.
In depth
Go deeper into phygital product design
Two working guides: choosing the identifier that binds each object to its record, and running ownership from the buyer's first claim through resale to redemption.
- 01ComparisonNFC vs QR vs RFID for product authenticationStatic QR, copy-detection patterns, cryptographic NFC, RAIN RFID and unclonable features compared for product authentication: clone resistance, reach, privacy.
- 02ProcessPhygital ownership: claim, resale and redemption flowsHow a phygital item's token is claimed, resold, serviced and redeemed: lifecycle stages with controls for vaulted goods, lost tags, theft and ownership claims.
Five layers that make up a phygital product
Each layer can fail independently, so each needs its own owner and its own controls.
- Owner and buyer experience
Scan pages, claim flows, resale listings and service requests: the part people actually see.
- Product record and IP terms
Enrolment data, ownership state, service history and the licence for any linked digital content.
- Attestations and oracles
Signed statements from factories, logistics hand-offs, authenticators and repairers that update the record.
- Ledger anchor or token
A token or hash that lets outsiders confirm the history without trusting a single company's database.
- Physical identifier
The NFC chip, printed code or unclonable feature attached to the object, or part of it.
Enrolment decides how much a scan is worth
Every later check compares against what was captured when the item was first registered, so enrolment is where a phygital programme succeeds or fails. If identifiers are personalised on an open line where blank tags can walk out of the door, or keys are exported in a spreadsheet, a counterfeiter can obtain genuine identifiers and all the downstream cryptography becomes irrelevant.
A sound enrolment process answers four questions. Who holds the keys that personalise each chip, and are they injected in a controlled environment? Which station binds the identifier to a serial, a batch and, for valuable items, photographs or measurements of the object itself? How are rejected, damaged and test tags voided so they never verify? And does the factory's unit count reconcile with the number of records created, so that surplus genuine tags are noticed?
Goods already in circulation can be enrolled later. An authenticator inspects a second-hand item, fits an identifier and signs an attestation recording who vouched for it and when. That evidence is weaker than enrolment at manufacture, and the result page should say which kind of enrolment stands behind each item.
Terms used in ColdAI's phygital framework
- QR attestation
- A signed statement reached from a printed code. A named party asserts a fact about an item, such as origin, inspection or batch, and the signature shows who said it and that it has not been edited. The code is only a pointer; the attestation carries the evidence.
- Supply-chain oracle
- A service that takes events from systems outside the ledger, such as warehouse scans, customs releases, temperature loggers or a repairer's job card, checks their origin and writes them to the product record. It is only as trustworthy as its data source and operator.
- Digital twin token
- A token, usually non-fungible, that stands for one enrolled item and points to its product record. It can carry ownership or an entitlement. By itself it does not show that the item still exists or is undamaged.
- Binding
- The link between identifier, record and object. Strong binding makes the identifier hard to copy and hard to move to another object; weak binding leaves one or both attacks open.
- Linked digital IP
- Content or rights that come with the object, such as a 3D model, an artwork file, a game item or access to an owners' service, governed by licence terms that state what the holder may do with them.
Deciding what goes on the ledger and what stays in the product record
A ledger is good at proving order and integrity. It is poor at holding detail that may need correcting, withholding or deleting.
| Record element | On the ledger | In the off-ledger record |
|---|---|---|
| Enrolment event | A hash of the enrolment record and the enrolling party's signature | Serial, batch, line data and reference photographs |
| Current owner | The token-holding account, where ownership is tokenised | Customer identity, contact details and consents |
| Custody and logistics events | Ordered messages or hashes submitted by the oracle | Source documents, scans and location detail |
| Service and repair history | One timestamped entry per job, signed by an approved repairer | Job cards, replaced parts and photographs |
| Licence for linked digital content | A pointer to a fixed, hashed version of the terms | Licence text, content files and access control |
| Personal data | None | All of it, under the brand's privacy controls |
Networks differ in cost and confidentiality; an ordered event log such as the Hedera Consensus Service suits anchoring, while a token service suits ownership.
Attaching digital content and intellectual property to an object
Many phygital products ship with something digital: a 3D model of a trainer for use in games, a high-resolution file of a limited print, membership of an owners' community or an extended warranty. The design question is what the holder is entitled to, and the answer belongs in a licence rather than in campaign copy.
Decide whether the rights pass to the next owner on resale, whether they survive if the object is destroyed or redeemed, whether commercial use is allowed and what happens if the content host closes. Unless the licence grants it, assume a token holder has no right to reproduce or commercialise the underlying work, and pin a hashed copy of the terms to the token's metadata so buyers can see exactly what they acquire.
Deliver the content from a service that reads current ownership at the moment of access. Access then follows the record when the object is sold, rather than staying with whoever downloaded a file first.
When a phygital design fits, and when something simpler will do
- If
Counterfeiting is rare and the product is seldom resold.
ThenUse serialised codes and an ordinary product database, and leave tokens out.
Without a copying problem or a resale market, a ledger adds cost and support work without answering a question anyone is asking.
- If
The main driver is an EU digital product passport obligation.
ThenStart from the regulatory data model in our digital product passport work and add ownership features only if a separate business case exists.
A passport serves regulators, repairers and recyclers with product information; ownership tokens solve a different problem.
- If
Items change hands through marketplaces where buyers pay for proven history.
ThenBind a cryptographic identifier at manufacture and tokenise ownership so provenance travels with each sale.
In these markets the record of previous owners and services is part of what the buyer is paying for.
- If
The object stays in a vault and only the claim on it trades, as with bullion or fine wine.
ThenTreat it as a real-world asset programme, with custody and legal structure settled first.
Once the token is what trades, financial regulation and custody arrangements dominate the design.
- If
The goal is engagement or loyalty rather than proof of authenticity.
ThenLook at digital asset experiences, which need no physical binding.
Binding hardware to every unit is wasted effort when nobody needs to check the object itself.
What a phygital pilot should demonstrate before full rollout
Frequently asked questions
How does a phygital asset differ from a digital product passport?
A digital product passport is a structured set of product information that the EU's Ecodesign for Sustainable Products Regulation makes mandatory for product groups named in later delegated acts, aimed at authorities, repairers, recyclers and buyers1. A phygital asset binds an individual object to a record that may also carry ownership, provenance or linked digital content. The two can share a data carrier, but a passport needs no token, and a token does not meet passport rules on its own.
Does a phygital product need a blockchain at all?
Not always. Binding the object to its record is mostly a physical and process problem. A ledger earns its place when several parties who do not share a database rely on the same history, such as brands, resellers, authenticators, repairers and insurers, or when the record must remain checkable if the brand's own systems change hands or close. If one company controls every interaction, a signed database may be enough.
Can products that are already on the market be brought into a phygital programme?
Yes, through later enrolment. Owners can register with proof of purchase, or an authenticator can inspect the item, fit an identifier and sign an attestation. The record should state that enrolment happened after sale and who vouched for the item, because that evidence is weaker than enrolment on the production line. Many brands run both routes: new stock enrolled at the factory and existing stock enrolled at resale or service.
What happens if the keys used to personalise tags are compromised?
Plan for it before launch. Keep master keys in hardware security modules, derive a separate key for each tag so one extracted tag does not expose the rest, and record which key batch every tag belongs to. If a batch is compromised, the verification service can flag those items, ask owners to re-verify through a second feature such as a photographed serial, and stop issuing new claims on them until the case is resolved.
Which kinds of products suit a phygital approach?
Products whose value depends on authenticity or history and which change hands: luxury goods and watches, collectibles and art, limited-edition trainers, fine wine and spirits, musical instruments, and industrial parts that carry safety or maintenance records. It suits low-value consumables less well, because the identifier and the service behind it cost more than the problem they solve.
Sources
Connect the architecture
The next connection.
Explore the complementary capabilities that can turn an individual technology into a complete workflow.
Your next move
Bring us the
real problem.
A workflow that takes too long. A system that cannot connect. An idea that needs a technical path. Start there, and we can define what to investigate, build and measure.
- A physical product and interaction use case
- An enrollment or manufacturing process
- An explicit copying and tampering threat model