Tokenized real-world assets: provenance and verification apps

By Marco Lopes · June 24, 2024 · Blockchain & Web3

Tokenizing a real-world asset sounds straightforward: create a digital token, associate it with something physical or legally recognized, and let people hold or transfer it. The difficult part begins when someone asks what that token actually proves.

Does it represent ownership, a claim against a custodian, a certificate of authenticity, or simply a record? Who inspected the asset? Can the evidence be checked independently? What happens if the physical item disappears while its token continues to circulate?

At Kordspace, we approach these questions as product and systems design problems, not just smart contract problems. As a remote collaborative software, AI, Web3, hardware, and design studio, we work across the interfaces where digital claims meet physical operations. Here, we outline how we would build provenance and verification apps that make those claims understandable and testable.

Start with the claim, not the token

Before choosing a blockchain, we write down the exact statement the application needs to support. “This token represents this asset” is too vague to guide implementation.

For a piece of equipment, the useful claim might be that an identified inspector recorded a particular serial number and condition on a specific date. For a warehouse receipt, it might be that an authorized custodian acknowledges holding a defined quantity of goods under stated terms.

We separate three questions:

• Identity: Which asset, batch, or legal claim are we describing?
• Evidence: What supports the description, and who supplied it?
• Rights: What can the token holder actually do or enforce?

A token transfer does not automatically transfer legal title. We need the applicable contracts, registry processes, and custody arrangements to establish that relationship. When rights are unclear, we treat that as a launch blocker rather than a documentation task for later.

Understand what blockchain can verify

A blockchain can help us establish that a transaction was accepted under a network’s rules and that a particular key authorized an action. We can also anchor a document’s cryptographic hash so that later readers can check whether their copy matches the committed version.

Those properties do not establish that the document was truthful. A false inspection report can be signed correctly and stored immutably.

We therefore distinguish between record integrity and real-world accuracy. Integrity asks whether evidence changed. Accuracy asks whether it described reality in the first place.

Our architecture needs named trust boundaries: inspectors, custodians, issuers, registries, device operators, and dispute handlers. Each should have a defined responsibility and a way to lose its authority. Decentralizing the transaction log does not remove dependence on whoever observes the asset.

Model provenance as a sequence of events

We avoid treating an asset as a token with one editable description. Provenance is a history: creation, inspection, custody changes, maintenance, certification, damage, redemption, and retirement.

For each event, we typically record:

• A stable asset identifier and unique event identifier.
• The event type and structured claims.
• The time of observation, separately from the time of submission.
• The issuer’s identity, authorization, and signature.
• References to evidence, including hashes and schema versions.
• Any event it corrects, supersedes, or revokes.

We define how identifiers are issued and how duplicate registrations are detected. A manufacturer’s serial number may be useful, but we do not assume it is globally unique or impossible to copy.

Corrections should remain visible. Instead of silently replacing a mistaken inspection, we append a corrective event and explain its relationship to the original. The application can present the current accepted state while preserving the underlying history for authorized reviewers.

Build a verification workflow people can use

Consider a hypothetical application for industrial equipment. We would begin with enrollment: an authorized operator identifies the machine, captures supporting documents, and submits the initial record for review.

An inspector then signs an assessment with a defined scope. We want “serial number and exterior condition checked” rather than an ambiguous “verified” badge. A custodian can separately acknowledge possession, without being presented as an authority on mechanical condition.

When a prospective buyer opens the verification page, we show the claims individually: who made them, what evidence is available, when they were made, and whether they remain valid.

We also show what we cannot confirm. An old inspection is not a live guarantee. Missing evidence, an expired credential, or an unavailable custody service should produce a clear status, not a reassuring green checkmark.

Before a transfer or redemption, we recheck the conditions relevant to that action rather than relying solely on an earlier onboarding decision.

Choose token mechanics after defining operations

We choose a token standard according to the asset model. ERC-721 can suit individually identified assets; ERC-1155 can suit applications managing multiple asset types or quantities. Neither standard, by itself, defines custody, legal ownership, or reliable verification.

For restricted or regulated transfers, we may need eligibility checks and transfer controls. We assess existing approaches, including ERC-3643 where appropriate, against the actual legal and operational requirements rather than assuming a standard guarantees compliance.

We also specify minting, burning, freezing, recovery, and redemption behavior. Who can pause transfers? Can an administrator replace a lost holder’s position? What approvals are required?

These powers affect trust. We document them in the product interface and protect sensitive actions with suitable approval policies. If contracts are upgradeable, we disclose who can change them and how users learn about proposed changes.

Keep the architecture deliberately hybrid

We generally put minimal commitments and essential state transitions on-chain, while keeping detailed evidence in controlled storage. Large documents, photographs, personal information, and operational logs rarely belong on a public ledger.

On Google Cloud, our preferred starting point, a practical implementation could use Cloud Run for APIs and verification workers, Cloud Storage for evidence, Cloud SQL for operational records, and Pub/Sub for asynchronous processing. Secret Manager and Cloud KMS can support secret and key management, with signing arrangements selected for the blockchain’s requirements.

We can build equivalent patterns on AWS or Azure when an organization’s infrastructure or governance calls for them.

The blockchain integration needs particular care. We separate submitted, included, and finalized transaction states; make event processing idempotent; and reconcile indexed data against chain state. We also account for reorgs and RPC outages.

A cloud database remains a useful application index, not an unquestionable source of blockchain truth. Our recovery procedures should explain how to rebuild that index and restore access to evidence.

Treat hardware and AI as supporting evidence

QR codes, NFC tags, and connected sensors can make asset verification easier. We still ask what binds the identifier to the physical item. A copied QR code does not authenticate a machine, and even a tamper-evident label needs an inspection process.

For connected hardware, we evaluate device identity, secure key storage, firmware updates, calibration, and replacement procedures. Signed telemetry shows which credential produced a message; it does not prove a sensor was installed correctly.

We can use AI to extract fields from documents, flag inconsistent descriptions, or prioritize suspicious submissions for review. We keep those outputs attributable and distinguish them from verified facts. A model’s confidence score is not an attestation of ownership or authenticity.

Design privacy and retention before launch

Public blockchains create durable visibility. Even without names, wallet addresses and transaction patterns can expose commercial relationships or allow people to infer sensitive activity.

We minimize public data and define who may access each evidence category. Buyers may need an authenticity summary, while auditors need detailed records and inspectors need only the material relevant to their assignment.

We also avoid assuming that hashing makes information private. Predictable values can be guessed and checked against a published hash. Where necessary, we use properly designed commitments, controlled disclosure, or other privacy techniques appropriate to the threat model.

Off-chain storage lets us apply retention and deletion policies to documents, but it does not erase on-chain commitments or copies already shared. We explain those limits and have qualified counsel review personal-data handling and jurisdiction-specific obligations.

Plan for broken links between tokens and assets

The most important operational scenarios are often exceptions: a stolen asset, an insolvent custodian, a compromised inspector key, or two issuers claiming the same goods.

We define a dispute workflow before enabling transfers. That includes who may report an issue, what evidence is required, whether transfers can be suspended, and how a resolution becomes part of the record.

Redemption deserves equal attention. If a token can be exchanged for a physical item, we need a coordinated handover process that prevents the claim from remaining active after delivery. We cannot make a physical handover and an on-chain transaction perfectly atomic simply by adding a smart contract.

For assets involving investment rights, we involve qualified legal and compliance specialists early. Tokenization is not an exemption from securities, custody, consumer protection, or other applicable rules.

Pilot the whole trust chain

We recommend starting with one asset class, a small set of accountable participants, and a clearly defined verification decision. A narrow pilot exposes weaknesses more effectively than a marketplace filled with poorly specified tokens.

We test evidence capture and recovery alongside contract behavior. Can another reviewer reproduce the verification result? What happens when the evidence store is unavailable? Can we revoke an inspector without hiding legitimate historical reports?

Our security work covers contracts, APIs, access control, signing keys, and administrative interfaces. We test duplicate messages, failed transactions, expired credentials, and recovery from backups.

For our remote collaboration process, we keep schemas, threat models, and operational runbooks versioned and reviewable. We measure practical outcomes such as review effort, unresolved exceptions, and evidence availability, not merely how many tokens were minted.

A short launch checklist

Before launch, we check that:

• The token’s claim and associated rights are explicit.
• Asset identity and duplicate-registration controls are defined.
• Evidence issuers have clear authorization and revocation procedures.
• Custody, transfer, redemption, and dispute workflows are tested.
• Public data is minimized and retention policies are documented.
• Contract privileges, key recovery, and cloud recovery are reviewed.
• Verification screens communicate uncertainty and evidence freshness.

Build a verifiable product, not just a token

We see the strongest opportunity in applications that make evidence easier to inspect, responsibilities easier to understand, and exceptions easier to resolve. The blockchain is one component of that system, not a substitute for accountable real-world operations. If we can help turn your asset workflow into a practical provenance and verification product, start a project, or explore our related software, AI, Web3, hardware, and design work on our services pages.