Blockchain as a trust layer, not as the product's main feature
It’s not about simply adding blockchain to a product, but about understanding what evidence needs to be reliable, which parties are involved, what rules must be followed, and which part of the process is improved by making it verifiable, traceable, or tamper-resistant.
Blockchain · Tokenisation · Traceability · Smart Contracts · Digital evidence · Trust Layer
Trust must also be designed
Blockchain adds value when it ceases to be the focus of the discussion and becomes a layer of trust that supports a real-world process.
In many innovation projects, blockchain is brought up far too early in the discussion. Sometimes even before there is a proper understanding of the process, the stakeholders, the data or the problem being addressed. It is presented as a distinguishing feature, a guarantee of transparency or a sign of modernity. But using blockchain does not automatically make a solution more reliable, more innovative or more useful.
For me, blockchain starts to make sense when there are defined rules, multiple stakeholders with their own interests, and a genuine need to maintain a verifiable, shared and tamper-proof ledger. It’s not about recording data for its own sake, but about deciding which events, pieces of evidence or transactions need to be recorded in a way that can be audited or verified at a later date.
The key is to understand that blockchain is not the product. It is infrastructure. It is a layer of trust that can underpin processes where integrity, traceability, auditability, tokenisation or coordination between parties are important. But the value for those using the solution does not lie in knowing that there is a blockchain behind it, but in being able to have greater confidence in what is happening.
A good blockchain-based solution doesn’t require the user to understand the technology. It allows them to see the value.
The mistake of prioritising technology over the problem
One of the most common mistakes is to start with the phrase “let’s bring in blockchain” without first identifying the underlying trust issue. This often leads to solutions where the technology is present but does not necessarily add value. Information is recorded on a network, people talk about immutability and mention traceability, but it is not always clear which decision is being improved, which risk is being reduced, or which party needs to verify that information.
It is also common to confuse immutability with data quality. Just because data is recorded in an immutable manner does not mean it is correct. Blockchain can help demonstrate that information has not been altered since a specific point in time, but it does not in itself guarantee that the information was true, complete or reliable at the outset. If the input data is poor, incomplete or has not been properly validated, the technology merely preserves a poorly resolved problem.
This is particularly important in traceability projects. Traceability does not simply mean accumulating records. It means understanding which events in the process matter, who generates them, how they are validated, what evidence accompanies them, and who needs to consult them later. In an agri-food supply chain, for example, it is not enough to say that the product’s journey is recorded. We need to define what happens in the field, what is recorded during processing, what data comes from warehouse systems, what evidence is generated, and what information the consumer can ultimately understand.
Something similar happens in projects involving social assistance or the tokenisation of resources. A token can represent a form of assistance, a right of use, a unit of value or a transaction within an ecosystem, but it only provides value if it is linked to clear rules, identified stakeholders and an operational framework that allows it to be used, verified and monitored. Tokenisation for tokenisation’s sake solves nothing.
Furthermore, designing with technology in mind rather than operations often results in experiences that are far too complex. Terms such as wallet, hash, smart contract, token, transaction, address, signature, on-chain and off-chain crop up, but the end user does not want to deal with that complexity. They want to know whether a payment has been received, whether proof is valid, whether a product is traceable, whether a transaction has been completed, or whether they can trust the information they are seeing.
The challenge is not to make blockchain visible. The challenge is to make trust visible.
Blockchain as a product infrastructure
Blockchain can deliver significant value when designed as a layer that underpins real-world processes, rather than as a standalone component. For it to be meaningful, it must address a specific need for trust, integrity, traceability or coordination between stakeholders.
Trust Layer
Blockchain makes sense when multiple parties need to operate on the basis of a shared source of trust without relying solely on a single intermediary. In such cases, it can help to record events, transactions or evidence in a verifiable manner, enabling the parties to share a common understanding of what has taken place. Its value lies in reducing disputes, improving auditability or enabling the integrity of a process to be verified.
Traceability with a purpose
Not all data needs to be recorded on the blockchain. Effective traceability starts with defining which events matter and what decisions their recording enables. This could be the origin of a raw material, a transaction carried out, evidence generated, a delivery, a certification or a milestone within a value chain. The important thing is not to record more, but to record what really needs to be verifiable.
Useful tokenisation
A token only has value if it represents something tangible within the process: a benefit, a right, proof of ownership, an asset, a milestone or an authorisation. Tokenisation allows units of value or utility to be modelled within an ecosystem, but it requires clear rules: how it is issued, who receives it, where it can be used, what restrictions apply, how it is transferred and how its status is verified. Without that logic, the token is merely a technical abstraction.
Privacy and actual operation
A good blockchain solution must also determine which information is recorded on-chain and which remains off-chain. In many contexts, particularly where personal, commercial or sensitive data is involved, it makes little sense to expose the full details on a network. It may be more appropriate to record hashes, references, timestamps or integrity proofs, whilst keeping the original data in secure, controlled systems. Trust should not be built at the expense of privacy.
From use case to trust layer
I am working to identify which part of the process needs to be verifiable before deciding how to document it.
When I’m working on solutions where blockchain might be appropriate, I try not to start with the network, the token or the smart contract. I start with the process: what happens, who is involved, what information is generated, what rules apply, and which parts need to be verifiable.
The first question is whether there really is a problem of shared trust. If a single organisation controls the entire process, a traditional database may suffice. But if multiple parties are involved, each with different responsibilities, interests or validation requirements, blockchain can provide an additional layer of trust. Not because it is more modern, but because it allows a common reference point to be established regarding specific events or evidence.
Next, you need to identify what needs to be recorded. Not every event has the same value. In industrial traceability, it may be useful to record key milestones in a product’s journey, evidence generated in the field, processing steps, checks or certifications. In subsidy systems, it may be useful to record the issuance, use, transfer or settlement of tokens. In certification solutions, it may be worth recording proof of existence, integrity or document validity. Each case requires a different approach.
It is also necessary to distinguish between the data itself and the proof. This distinction is key. Often, it is not the complete information that is recorded on the blockchain, but rather a reference, a hash, a cryptographic proof or a timestamp that makes it possible to verify that the data has not been altered.
The data can remain off-chain, in controlled systems, encrypted or managed under specific access rules. This architecture allows for a combination of integrity and privacy, preventing the network from becoming a repository for sensitive information.
Smart contracts can be useful when there are business rules that need to be executed in a transparent or verifiable manner. They can represent conditions, restrictions, state changes, token issuance or automatic validations. But they are not magic either. A smart contract executes rules; it does not, on its own, determine whether those rules make sense in the context of the transaction. Therefore, before automating, it is essential to have a clear understanding of the process and its exceptions.
The user experience should hide almost all of this complexity. Someone checking a product’s traceability does not need to see the hash. They need to understand the origin, the journey and the relevant evidence. A merchant accepting tokens does not need to think about smart contracts. They need to know whether the transaction is valid and what to do next. An administrator does not need to interpret the network, but rather to monitor states, rules and operations clearly.
That is why product work involves translating the technical layer into understandable actions: recording, verifying, consulting, transferring, validating, auditing. Each of these actions can be underpinned by blockchain, but must be presented as a natural part of the workflow. The technology must underpin trust without becoming a cognitive burden.
The best DApp is one that doesn’t require you to understand blockchain
The best decentralised blockchain-based application is one that solves the trust problem without requiring the user to understand the technical aspects.
Not all products need blockchain. Not all traceability requires a distributed network. Not all evidence needs to be tokenised. And not every immutable record solves a trust issue. Sometimes all that is needed is a good data architecture, a well-designed integration or a traditional database. The key is knowing when trust requires something more.
When it does make sense, blockchain should function as a discreet infrastructure: visible in its value, invisible in its complexity. Users should not have to understand what happens on-chain, what remains off-chain, how a hash is calculated, or how a smart contract operates in order to benefit from the solution. What they do need to understand is what information they can trust, what transaction has taken place, and what evidence exists to support it.
Innovation isn’t about simply saying we use blockchain. It’s about designing systems where trust, traceability and verifiability solve a specific problem.
Let’s talk about traceability and digital trust
We can discuss products, UX, tokenisation, traceability or blockchain solutions that need to transform complex technology into clear, verifiable and useful value for businesses and users.