Blockchain is frequently proposed before the real software problem has been defined.

A product needs traceability, so blockchain is suggested.

A business needs stronger audit records, so blockchain is suggested.

Several companies need to exchange data, so blockchain is suggested.

A platform wants digital assets, automation or more customer trust—and again, blockchain becomes the proposed architecture.

But many of these requirements can be solved more simply with:

A conventional database
Secure APIs
A managed multi-tenant platform
Digital signatures
An append-only audit log
Verifiable credentials
Event streaming
A trusted third-party service

Blockchain becomes valuable only when its particular trust model solves a problem that these simpler architectures cannot solve adequately.

The central question is not:

Could this product use blockchain?

Almost any product could store a hash, transaction or token on a blockchain.

The useful question is:

Does this product need several independent parties to maintain shared state without giving one party complete control—and are the costs of distributed consensus justified?

If the answer is no, blockchain is probably not the right foundation.

If the answer is yes, blockchain may deserve serious evaluation.

Blockchain decision framework evaluating trust, collaboration, auditability, cost, performance and alternative architectures. — Blockchain should be selected because its distributed trust model solves a necessary problem—not because the product needs a database with stronger marketing.

Quick answer: Does your software product need blockchain?

Your software product may need blockchain when all or most of the following are true:

Several independent organisations must write to or validate shared data.
The organisations do not fully trust one another.
No acceptable central operator can own the definitive record.
Participants need independently verifiable transaction history.
Tamper resistance, shared execution or digital-asset ownership provides material business value.
Governance rules can be agreed between the participating organisations.
The product can accept the additional latency, cost and operational complexity.
Privacy and regulatory requirements can be satisfied.
The same outcome cannot be achieved more simply with a database, API or signed audit log.

You probably do not need blockchain when:

One organisation controls the system.
Users already trust a platform operator.
Only one party writes the data.
The main requirement is ordinary CRUD functionality.
Records must be deleted or frequently corrected.
High throughput and low latency are critical.
The organisation needs a better audit log rather than distributed consensus.
Blockchain would merely duplicate an existing authoritative database.

The practical rule is:

Use blockchain when decentralised agreement is a core product requirement. Do not use it merely as a different way to store data.

Key takeaways

Blockchain is a distributed, tamper-evident ledger—not a universally superior database. [1]
The first question is not whether data should be stored. It is whether several independent parties need to write or validate shared state.
If a trusted central operator can run the system acceptably, a conventional architecture will usually be simpler, faster and less expensive.
“Immutable” should be used carefully. NIST describes blockchains as tamper-evident and tamper-resistant rather than absolutely unchangeable. [1]
A requirement for auditability does not automatically justify blockchain. Signed records and append-only Merkle logs can provide strong tamper evidence without a distributed consensus network. [6]
Permissioned blockchains retain participant identities and governance controls. They do not eliminate centralisation; they redistribute selected authority among known participants. [3][4]
Public blockchains are strongest when open participation, neutral execution and publicly verifiable digital ownership are essential.
Smart contracts automate shared transaction rules, but they introduce new security, upgrade and governance risks. [8]
Sensitive or personal data should generally remain off-chain, with commitments, keyed hashes or other proofs recorded where appropriate. [7]
Blockchain cannot prove that external information is true. It can preserve what an authorised participant or oracle submitted.
Tokens are useful when transferable digital ownership or cryptoeconomic incentives are part of the product model—not as a substitute for ordinary database IDs or loyalty points. [9]
A blockchain pilot should validate the trust and governance model, not merely demonstrate that a transaction can be written to a ledger.

What is blockchain?

Blockchain is a distributed ledger maintained by a network of participants.

Transactions are grouped, ordered and cryptographically linked so that attempts to alter previous records can be detected and resisted according to the network’s consensus and governance model.

A blockchain commonly combines:

Digitally signed transactions
Cryptographic hashes
An append-only transaction history
Replication across nodes
A consensus or agreement process
Rules governing valid state changes
Participant incentives or identities
Smart-contract execution where supported

NIST describes blockchain as a tamper-evident and tamper-resistant ledger implemented in a distributed fashion, usually without a single central repository. [1]

What is the product actually buying?

When a software product adopts blockchain, it is not simply buying storage.

It is buying a particular set of trade-offs:

Several nodes retain copies of the ledger.
State changes require distributed validation.
Participants can verify history independently.
One operator may have less unilateral control.
Changes to rules require network governance.
Data and logic become more difficult to alter privately.
Transactions may take longer and cost more.
Errors can be harder to reverse.
Sensitive data becomes harder to manage.

These characteristics may be valuable.

They may also be unnecessary.

What blockchain does well

Blockchain can be a strong architectural choice for several narrowly defined needs.

Shared state across independent organisations

Several organisations can maintain a consistent transaction history without one party owning the only authoritative database.

Tamper-evident history

Cryptographic linking and replication make silent historical alteration significantly more difficult.

Independent verification

Participants can verify transactions or state according to shared protocol rules rather than relying only on reports from one operator.

Digital assets

A network can represent and transfer ownership of digitally native assets or claims.

Shared execution

Smart contracts can execute transaction rules consistently across participating nodes.

Open participation

A public blockchain can allow participants to transact without bilateral onboarding by one platform owner.

Resilience against one operator

The network may continue operating even if one participant or infrastructure provider fails, depending on its architecture.

What blockchain does not do

It does not make incorrect data true

Suppose a supplier records:

Recycled content: 80%

The blockchain can prove:

Which account submitted the value
When it was submitted
Whether the recorded transaction was later altered

It cannot prove that the supplier measured the recycled content correctly.

This is often called the oracle problem or the boundary between on-chain and off-chain truth.

Data quality still requires:

Authoritative sources
Verification
Certification
Audits
Sensor assurance
Legal accountability

It does not create trust between organisations

Blockchain can reduce the need to trust one operator with the transaction record.

Participants must still trust:

Identities
Governance
Smart-contract code
Oracle providers
Wallets
Key-management systems
Software implementations
Legal agreements

Blockchain changes where trust is placed. It does not remove trust.

It does not guarantee privacy

Public blockchain transactions are commonly replicated and visible across many nodes.

Even when names are absent, addresses and transaction patterns may be linkable.

Permissioned networks can restrict data, but privacy still requires deliberate architecture.

It does not eliminate administrators

Networks still need people or organisations to decide:

Who may participate
Which software version is accepted
How defects are handled
How keys are recovered
How disputes are resolved
How the protocol is upgraded
Which data model applies

It does not eliminate centralisation

A network described as decentralised may still depend heavily on:

One development organisation
A small group of validators
One cloud provider
One wallet
One bridge
One token issuer
One oracle
One governance group

Decentralisation should be measured across the entire system, not inferred from the presence of a blockchain.

It does not make software secure

Smart contracts and supporting infrastructure remain software.

They can contain:

Access-control defects
Business-logic errors
Input-validation failures
Oracle weaknesses
Reentrancy vulnerabilities
Upgrade problems
Key-management failures

OWASP’s 2026 Smart Contract Top 10 continues to identify these as major risk classes. [8]

The practical blockchain decision framework

A useful decision should proceed through a sequence of questions.

Decision flowchart for choosing a traditional database, API, signed audit log, permissioned blockchain or public blockchain. — Most products should exit the decision tree before reaching blockchain; only products with genuine distributed trust requirements should continue.

Question 1: Are multiple independent parties involved?

The first question is whether more than one independent organisation needs to participate in maintaining the shared system.

Examples may include:

Manufacturers and suppliers
Banks and payment institutions
Insurers and healthcare providers
Logistics operators and retailers
Government agencies and regulated businesses
Buyers and sellers in an open marketplace

Independent parties have:

Different ownership
Different administrators
Different commercial interests
Different legal responsibilities
Different infrastructure

When the answer is no

If one company owns and operates the product, a traditional database is usually preferable.

Examples include:

Internal HR system
Customer relationship management
Content-management platform
Private inventory application
Employee expense system
Analytics dashboard

Adding nodes operated by the same company does not create meaningful decentralisation.

It creates distributed infrastructure under one authority.

A replicated SQL database can already provide:

Availability
Backups
Read replicas
Geographic resilience
Audit logs
Access controls

When the answer is yes

Continue to the next question.

Multiple parties alone do not justify blockchain.

They may still be comfortable using a shared SaaS platform or neutral intermediary.

Question 2: Must these parties share and update the same state?

Several organisations may exchange information without maintaining one common state.

For example:

A supplier sends invoices to customers.
A regulator receives periodic reports.
A retailer requests product information.
A partner consumes an API.
A bank sends payment confirmation.

These interactions can often use:

APIs
Webhooks
Events
Secure file exchange
Data spaces
Federated databases
Verifiable credentials

Blockchain becomes more relevant when participants need a jointly maintained sequence of state transitions.

Examples include:

Transfer of an asset
Shared settlement
Multi-party approval
Chain of custody
Shared allocation of limited resources
Jointly maintained ownership records

Ask what the state represents

Define the shared state precisely:

Asset:
Container C-192

Current custodian:
Logistics Company B

Previous custodian:
Manufacturer A

Transfer:
Accepted by both parties

Timestamp:
2026-06-20T11:30:00Z

Do not use a blockchain to share a collection of documents merely because several companies need access to them.

Question 3: Can an acceptable central operator exist?

This is often the decisive question.

Could one organisation or managed service operate the authoritative database in a way all participants accept?

Possible central operators include:

Industry association
Regulator
Marketplace
SaaS provider
Consortium company
Independent auditor
Trusted infrastructure provider

When a central operator is acceptable

Use a conventional platform unless blockchain creates another measurable benefit.

A central operator can provide:

Clear accountability
Faster transactions
Simpler correction
Easier privacy management
Lower operational overhead
Familiar support
Straightforward upgrades

When a central operator is unacceptable

Blockchain may deserve further evaluation when:

Every potential operator is also a competitor.
One party should not be able to rewrite history.
Participants need their own independently verifiable record.
Political or jurisdictional concerns make one operator unsuitable.
The ecosystem is intended to remain open.
One platform owner would create unacceptable lock-in.
The network must continue if one organisation exits.

A classic blockchain decision model by Wüst and Gervais similarly begins by examining whether persistent shared state has multiple writers and whether a trusted third party is available. [2]

Question 4: Who needs to write or validate transactions?

A system with many readers but one writer does not necessarily need blockchain.

For example, a regulator may publish a public register.

Millions of users may read it, but only the regulator writes authoritative entries.

That can be implemented through:

Signed records
Public API
Append-only log
Merkle transparency tree
Digitally signed snapshots

Blockchain is more relevant when multiple independent parties must:

Propose transactions
Approve transactions
Validate transactions
Maintain ledger copies
Enforce shared rules

Do the writers distrust one another?

Multiple authorised writers may still fully trust one operator.

For example, employees in several departments may update one ERP system.

The fact that many people write does not create a decentralised trust problem.

Question 5: Is a tamper-resistant shared history essential?

Many products require audit history.

Far fewer require a distributed ledger.

Ask why history must be protected.

Ordinary audit requirement

The organisation needs to know:

Who changed a record
What changed
When it changed
Which account authorised it

A database audit table may be sufficient.

Strong tamper-evidence requirement

The organisation needs evidence that administrators could not silently rewrite the log.

Possible solutions include:

Digitally signed events
Write-once storage
Immutable cloud retention
Hash chaining
External timestamps
Merkle transparency logs
Independent log replication

RFC 9162 demonstrates that append-only Merkle trees can provide efficient inclusion and consistency proofs without requiring a blockchain consensus network. [6]

Distributed-history requirement

Several independent organisations need to maintain and verify the same transaction history, and no one operator should be able to rewrite it alone.

This is a stronger case for blockchain.

“Immutable” is not absolute

NIST cautions that blockchain records should be described as tamper-evident and tamper-resistant rather than absolutely immutable.

Forks, governance decisions, attacks or protocol changes can affect what the network recognises as canonical history. [1]

Question 6: Do you need shared automated execution?

A smart contract can implement rules that all participating nodes apply to a transaction.

Examples include:

Release payment after required approvals
Transfer ownership
Enforce transaction limits
Distribute token rewards
Settle trades
Apply governance votes
Allocate digital assets

Hyperledger Fabric describes smart contracts as executable transaction logic agreed between participating organisations, with policies determining which organisations must endorse transactions. [10]

When ordinary workflow is better

Use a traditional workflow engine when:

One organisation controls the process.
Rules change frequently.
Administrators need to correct mistakes.
Human judgement is central.
Confidential logic cannot be replicated.
The workflow requires complex integration.
Transactions need compensation or reversal.

Workflow engines offer mature support for:

Durable state
Human tasks
Timers
Retries
Compensation
Versioning
Error handling

When smart contracts add value

Smart contracts become more valuable when:

Several organisations must accept the same execution rules.
No participant should run the only implementation.
The transaction controls digital assets already on the network.
Independent verification of execution is essential.
The rules can be specified deterministically.

Question 7: Do you need a token?

A token is not a required feature of every blockchain system.

Permissioned ledgers may operate without transferable tokens.

A token may be justified when the product needs:

Digitally native transferable ownership
Network participation incentives
Staking or security deposits
Programmable settlement
Fungible network assets
Fractional ownership
Community governance rights

NIST describes tokens as instruments that can represent digital ownership, incentives, governance and programmable assets across blockchain systems. [9]

Weak token use cases

A token is probably unnecessary when it merely represents:

An internal database ID
Conventional loyalty points
A non-transferable account balance
A subscription entitlement
A voucher controlled by one company

These can generally be implemented more simply in a database.

The token test

Ask:

Would the product still need blockchain if the token were removed?

If the answer is no, the product may be token-first rather than problem-first.

Question 8: Can the trade-offs be justified?

Blockchain changes non-functional requirements.

Evaluate:

Transaction latency
Finality
Throughput
Storage growth
Network fees
Node costs
Development complexity
Security-audit cost
Governance overhead
Key recovery
Incident response
Regulatory obligations

Public-network fees

Public smart-contract networks charge for computation and state changes.

Ethereum, for example, requires gas for transaction execution, with fees affected by computation and network demand. [5]

A product must decide:

Who pays?
Can the fee vary?
Can users understand it?
Can transactions wait?
What happens when the network is congested?

Finality

A database transaction can often commit in milliseconds.

Distributed networks may distinguish between:

Included
Confirmed
Finalised

On proof-of-stake Ethereum, finality depends on validator agreement between checkpoints and cryptoeconomic penalties. [5]

The required waiting period may be acceptable for asset settlement but inappropriate for an interactive application request.

Governance overhead

The network must govern:

Participant admission
Node operation
Contract upgrades
Emergency response
Protocol changes
Data models
Fees
Dispute resolution
Member removal

The governance model is part of the software architecture.

Compare blockchain with simpler alternatives

Before choosing blockchain, compare it against the nearest alternative.

Comparison of traditional databases, managed platforms, signed audit logs and blockchain networks. — Blockchain should be selected only after comparing its trust and audit benefits with simpler architectures.

Requirement	Traditional database	Shared SaaS platform	Signed or append-only log	Blockchain
One authoritative operator	Strong fit	Strong fit	Strong fit	Usually unnecessary
Several independent writers	Requires integration	Possible	Possible	Strong fit
No acceptable central operator	Weak fit	Weak fit	Limited	Strong fit
Low latency	Strong	Strong	Strong	Variable
High throughput	Strong	Strong	Strong	Usually lower
Easy correction or deletion	Strong	Strong	Moderate	Weak
Tamper evidence	Moderate	Moderate	Strong	Strong
Independent verification	Limited	Platform-dependent	Strong for logged records	Strong
Public participation	Weak	Platform-controlled	Read access possible	Strong on public chains
Programmable digital assets	Custom implementation	Platform-controlled	Weak	Strong
Privacy control	Strong	Strong	Strong	Requires careful design
Operational simplicity	Strong	Strong	Moderate	Weak
Multi-party governance	External process	Provider-led	External process	Built into network design

Alternative 1: Traditional database

Use a relational, document or distributed database when:

One organisation is accountable.
Performance matters.
Records require updates and deletion.
Access is centrally governed.
The system serves normal application workflows.

A traditional database is not technologically inferior.

It is often exactly the correct abstraction.

Alternative 2: Shared SaaS or neutral platform

A managed platform can coordinate multiple organisations through:

Tenant isolation
APIs
Workflows
Audit logs
Contractual governance
Role-based access
Data exports

This is appropriate when participants trust the platform operator sufficiently or can manage the relationship contractually.

Alternative 3: Signed records

A record can be cryptographically signed by its issuer.

This can prove:

Which key signed it
Whether it changed
When it was issued, if trusted timestamping is used

Signed records are useful for:

Certificates
Credentials
Compliance evidence
Supplier declarations
Reports
Documents

They do not require every recipient to share one ledger.

Alternative 4: Append-only transparency log

A Merkle-based log can provide:

Inclusion proofs
Consistency proofs
Public or independent monitoring
Evidence of log misbehaviour
Efficient append-only verification

This may solve the requirement when the primary concern is detecting unauthorised historical modification.

It still depends on log governance and monitoring, but does not require a general-purpose blockchain. [6]

Alternative 5: Event streaming

An event platform can distribute immutable-style business events to several consumers.

Examples include:

Order created
Product shipped
Certificate issued
Account updated
Service completed

Consumers can build their own state from the event history.

This is useful when the principal requirement is system integration rather than decentralised consensus.

Public, permissioned or hybrid?

Once blockchain appears justified, the next decision is which participation model is required.

Public permissionless blockchain

Anyone can generally:

Read network data
Submit transactions
Operate supporting software
Verify state
Participate according to protocol rules

Strong fit when:

The ecosystem must remain open.
No organisation should approve every participant.
Publicly verifiable digital assets are required.
Neutral global settlement is valuable.
The application needs composability with an existing public ecosystem.

Main trade-offs:

Public data exposure
Transaction fees
Variable capacity
Key custody
Harder regulatory control
Dependence on protocol governance
Smart-contract security risk

Permissioned blockchain

Participants are known, approved and represented through digital identities.

Hyperledger Fabric, for example, uses membership service providers, certificates and policies to identify participants and assign network permissions. [3][4]

Strong fit when:

Several companies share a business process.
Participants are legally identifiable.
Data visibility must be controlled.
The consortium needs joint validation.
Governance can be defined contractually.
No participant should control the complete record alone.

Main trade-offs:

Consortium governance
Membership administration
Node-operation cost
Less open participation
Risk of collusion
Potentially limited decentralisation
Complex onboarding

Permissioned consensus can often be faster and less computationally expensive because validators are identified and can be removed for misconduct. [3]

Hybrid architecture

A hybrid design keeps operational data off-chain while recording selected proofs or settlement events on-chain.

For example:

Off-chain:
Product specifications
Personal information
Documents
Commercial terms
High-volume events

On-chain:
Document commitment
Ownership transition
Approval
Timestamp
Credential status
Settlement

This is often more practical than placing complete business datasets on a ledger.

Data privacy and blockchain

Privacy must be analysed before deployment, not after the ledger has accumulated records.

Do not put sensitive data on-chain by default

Blockchain data may be:

Replicated
Retained indefinitely
Visible to several participants
Difficult to correct
Difficult to erase
Correlatable with other information

CNIL recommends processing cleartext personal data outside the blockchain and, where justified, storing commitments, keyed hashes or ciphertext instead. [7]

A hash is not automatically anonymous

A hash may still be personal data when:

It can be linked to a person.
The original input can be guessed.
Another party retains the source data.
The value is stable across contexts.

Avoid storing hashes of low-entropy identifiers such as:

Email address
Phone number
National identity number
Date of birth

without appropriate keyed constructions and legal analysis.

Plan for correction

Blockchain history is usually appended rather than overwritten.

A correction may look like:

Transaction 100:
Incorrect status recorded

Transaction 124:
Transaction 100 superseded
Correct status recorded

The incorrect information remains in history.

The product must determine whether this satisfies legal and operational requirements.

Permissioned does not mean private automatically

Hyperledger Fabric can restrict private data to authorised organisations while placing corresponding hashes in the shared block, but this still requires correct collection policies and key governance. [4]

The oracle problem

Smart contracts cannot directly know whether an off-chain event is true.

They depend on an external input source, often called an oracle.

Examples include:

Market price
Weather measurement
Delivery confirmation
Laboratory result
Identity status
Insurance event

Ask:

Who supplies the input?
Can that party be compromised?
Are several sources used?
What happens if sources disagree?
Can the result be challenged?
Is human review possible?
Can the contract pause during uncertainty?

A decentralised ledger fed by one central data source still has a central trust point.

Smart-contract risk

Smart contracts can control valuable assets or irreversible state.

The code may be difficult to modify after deployment.

OWASP’s 2026 Smart Contract Top 10 includes risks such as:

Access-control vulnerabilities
Business-logic vulnerabilities
Oracle manipulation
Weak input validation
Unsafe external calls
Arithmetic errors
Reentrancy
Upgradeability defects [8]

Production controls

Use:

Independent security review
Automated testing
Property-based testing
Static analysis
Fuzzing
Formal methods where justified
Limited permissions
Time locks
Emergency pause
Upgrade governance
Transaction limits
Monitoring
Incident-response procedures

Upgradeability is a governance decision

An upgradeable contract is easier to repair.

It also creates authority capable of changing the system.

A non-upgradeable contract reduces administrative control.

It also makes defects more difficult to correct.

There is no universally correct answer.

The upgrade policy should specify:

Who proposes changes
Who approves them
Required delay
Emergency process
User notification
Migration procedure

Governance is not an afterthought

A multi-organisation blockchain requires a governance agreement before technical deployment.

Define:

Membership

Who can join?
Who approves membership?
What identity evidence is required?
How is a participant removed?

Node operation

Who runs validators or peers?
What availability is expected?
Which hosting locations are allowed?
Who pays the operating cost?

Decision rights

How many organisations approve changes?
Does each participant have one vote?
Are votes weighted?
Can one organisation veto?

Smart-contract lifecycle

Who deploys contracts?
Who audits code?
Who approves upgrades?
How are old versions retired?

Data governance

Which data is shared?
Who owns it?
Who may read it?
How are errors corrected?
How long is off-chain information retained?

Disputes

Which law applies?
Which organisation investigates?
How are losses allocated?
Is arbitration required?
Can transactions be reversed operationally?

Hyperledger Fabric’s policy system illustrates how network membership, endorsement and configuration changes must be governed through explicit organisational rules. [4]

When blockchain is a strong fit

1. Multi-party asset transfer

Several organisations need to transfer ownership of a digital or physical asset while maintaining a jointly verifiable history.

Examples:

Trade settlement
Tokenised securities
Shared collateral
Digital collectibles
Inter-company asset registries

2. Shared settlement without one platform owner

Participants need deterministic settlement across a neutral network.

3. Open digital-asset ecosystems

Assets must be:

User-controlled
Transferable
Publicly verifiable
Usable by applications from different providers

4. Consortium processes with partial trust

Known organisations need a shared ledger but do not want one member controlling the authoritative record.

Potential examples include:

Trade finance
Insurance syndication
Shared logistics events
Inter-organisational approvals
Regulated market infrastructure

5. Public transparency with independent verification

The product needs a public, independently verifiable record, and the data is appropriate for permanent publication.

6. Cryptoeconomic network coordination

A network requires incentives, staking or token-based governance to coordinate participants who lack normal contractual relationships.

When blockchain is usually a weak fit

Internal business software

One company owns the users, database and business process.

Standard SaaS

Customers already trust the software provider to manage tenant data.

High-volume operational systems

The workload requires:

Very low latency
Frequent updates
Large files
Complex queries
High transaction throughput

Private document storage

Documents should remain in controlled object storage, with signatures and hashes where needed.

Customer identity database

Identity data often requires correction, deletion, consent and privacy controls.

Ordinary supply-chain tracking

If one major platform operator is accepted, APIs and shared event standards may be enough.

Product traceability with unverifiable input

Blockchain does not improve the quality of supplier information merely by preserving it.

Loyalty points

A company-controlled balance rarely needs an open distributed network.

Audit logs managed by one organisation

Write-once storage, signatures and external log monitoring may be more appropriate.

Practical use-case assessments

Digital Product Passports

A Digital Product Passport does not inherently require blockchain.

A conventional DPP architecture can use:

Product identifiers
Secure APIs
Verifiable credentials
Data spaces
Access policies
Signed records
Audit logs

Blockchain may add value when several independent organisations must update shared lifecycle state and no operator should control the history alone.

Sensitive product or personal data should remain off-chain.

Supply-chain provenance

Blockchain may be appropriate when:

Several companies write events.
Participants need independent verification.
No neutral platform is accepted.
Governance is clearly defined.

It is not sufficient when:

Supplier claims remain unverified.
Physical goods can be substituted.
Sensors are insecure.
Participants can collude.
The shared identifiers are inconsistent.

Digital identity

Decentralised identifiers and verifiable credentials do not necessarily require every credential or presentation to be stored on a blockchain.

A ledger may be used for:

Issuer registries
Credential schemas
Status
Public keys
Governance

Credentials and personal information should generally remain with the issuer or holder.

Compliance records

The organisation may only need:

Signed evidence
Trusted timestamps
Append-only audit history
External verification

A blockchain is stronger when several independent parties jointly maintain or verify the compliance history.

Payments

Public blockchain can provide:

Global settlement
Programmable assets
Peer-to-peer custody
Composability

Traditional payment infrastructure may provide:

Consumer protection
Reversibility
Familiar identity controls
Predictable user experience
Established legal frameworks

The correct choice depends on the product’s settlement and custody model.

A blockchain readiness scorecard

Score each factor from 0 to 2.

Factor	0	1	2
Independent organisations	One	Several under common control	Several independent parties
Shared writers	One writer	Limited shared input	Several authoritative writers
Central operator	Accepted	Possible but contested	Unacceptable or impossible
Trust	High	Partial	Low
Shared state	Not required	Useful	Essential
Tamper resistance	Ordinary audit sufficient	Strong evidence useful	Independent tamper resistance essential
Digital assets	None	Closed internal asset	Transferable network-native asset
Shared execution	Not needed	Some automation	Neutral shared execution essential
Open participation	Closed	Expandable consortium	Open ecosystem required
Performance tolerance	Milliseconds required	Seconds acceptable	Delayed finality acceptable
Privacy compatibility	Frequent deletion	Off-chain design possible	Public or persistent data appropriate
Governance maturity	One owner	Consortium forming	Agreed operating model

Interpreting the score

0–8: A traditional architecture is likely better.

9–15: Investigate signed records, neutral platforms or permissioned integration before blockchain.

16–20: A permissioned blockchain pilot may be justified.

21–24: Blockchain is a strong candidate, with public versus permissioned determined by participation and governance.

This score is a discussion aid, not an automatic architecture generator.

A single critical requirement—such as mandatory deletion—can outweigh the total.

A practical implementation roadmap

Software-product roadmap for evaluating blockchain from problem definition through production decision. — A responsible blockchain programme validates the business, trust, governance, security and performance assumptions before committing to production.

Phase 1: Define the problem

Document:

Customer problem
Business outcome
Current process
Current failure
Success criteria
Why blockchain is being considered

Avoid requirements such as:

Build a blockchain-based supply-chain platform.

Prefer:

Allow five independent companies to verify custody transfers
without giving any one company control over the historical record.

Phase 2: Map stakeholders

Identify:

Data producers
Data consumers
Transaction validators
Network operators
Regulators
Auditors
End users
Governance authority

Phase 3: Map trust

For every relationship, ask:

Who trusts whom?
Who might act dishonestly?
Who can correct an error?
Who can remove a participant?
Which legal agreements already exist?
Which party could operate a neutral service?

Phase 4: Define the shared state

Specify:

Business objects
Transaction types
Writers
Validators
Readers
Privacy levels
Finality requirements
Correction model

Phase 5: Evaluate simpler alternatives

Create working designs for:

Central database
Managed platform
Federated API model
Signed records
Append-only log
Event platform
Blockchain

Compare them against the same requirements.

Phase 6: Design governance first

Before writing a smart contract, agree on:

Membership
Voting
Node ownership
Contract deployment
Upgrade process
Incident response
Dispute resolution
Cost sharing
Exit process

Phase 7: Choose the network model

Decide whether the requirement is best served by:

Public permissionless network
Existing public layer-two network
Permissioned consortium network
Private single-operator ledger
Hybrid architecture

A private ledger run entirely by one organisation should be compared honestly with a conventional database.

Phase 8: Build the smallest meaningful pilot

The pilot should include:

At least two independent organisations
Independent identities
Realistic data
Real governance decisions
Failure scenarios
Privacy controls
Key recovery
Performance measurement

A pilot run by one development team on several local nodes proves only that the software runs.

Phase 9: Threat-model the complete system

Include:

Smart contracts
Wallets
Keys
Nodes
APIs
Frontend
Oracles
Bridges
Administrators
Governance
Supply chain
Cloud infrastructure

Phase 10: Test non-functional requirements

Measure:

Transaction latency
Finality
Throughput
Storage
Query performance
Node recovery
Network failure
Cost per transaction
Operational staffing
Upgrade time

Phase 11: Test privacy and compliance

Determine:

What is on-chain?
Is it personal or confidential?
Can it be corrected?
Can access be withdrawn?
Where are nodes located?
Who is legally responsible?
Which records must be retained?
Which records must be deleted?

Phase 12: Define the production decision

The final decision should be one of:

Proceed
Proceed with reduced blockchain scope
Use a hybrid design
Return to a conventional architecture
Stop the project

Choosing not to use blockchain can be a successful architectural outcome.

Questions to ask a blockchain vendor

Why is blockchain necessary for this use case?
Which party would have to be trusted without it?
Who operates the nodes?
Can one organisation change the rules?
What consensus mechanism is used?
What is the expected transaction finality?
What is the measured throughput?
Which data is stored on-chain?
How is confidential data protected?
How are incorrect records handled?
How are smart contracts upgraded?
Who pays transaction and infrastructure costs?
How are keys recovered?
What happens when a member leaves?
Can the organisation export and migrate its data?
Which features could be implemented without blockchain?
What independent security audits have been completed?
Who is legally accountable for network failures?

A vendor should be able to explain why its system needs distributed consensus without relying on vague language about transparency or innovation.

Common blockchain anti-patterns

Blockchain as a database upgrade

The product needs better data management but adopts a distributed ledger instead of fixing its data architecture.

Blockchain as marketing

The architecture is selected mainly to make the product sound innovative.

Single-company decentralisation

One company controls:

All nodes
All keys
All contracts
All users
All governance

This may still be a useful ledger implementation, but it does not remove the central trust relationship.

On-chain document storage

Large documents are placed directly on-chain despite cost, privacy and correction problems.

Token without economic purpose

A token is created without a real need for transferability, incentives or shared governance.

Blockchain before governance

Technical development begins before participants agree on ownership, rules and liability.

Smart contracts for subjective decisions

Ambiguous legal or human decisions are forced into deterministic code without an exception process.

Assuming provenance proves authenticity

A record shows where information came from, but nobody verifies whether it was correct.

Ignoring the user experience

Users are expected to manage:

Seed phrases
Gas
Networks
Signatures
Wallet approvals

without a strong product reason.

The most practical rule

Start with the simplest architecture that satisfies the trust model.

Add cryptographic signatures when records need attributable integrity.

Add append-only transparency when administrators should not be able to alter history silently.

Add a neutral platform when several organisations need coordination.

Add a permissioned blockchain when known organisations need jointly controlled shared state.

Use a public blockchain when open participation, neutral settlement or publicly verifiable digital ownership is essential.

Complexity should be earned by the problem.

Conclusion

Blockchain is not a general replacement for databases, APIs or cloud platforms.

It is a specialised architecture for shared state under distributed trust.

It becomes valuable when:

Several independent parties participate
Several parties write or validate transactions
No acceptable central operator exists
Participants require independent verification
Tamper-resistant history or shared execution is essential
Governance can be agreed
The product can accept the trade-offs

If those conditions do not exist, blockchain will often make the software:

More expensive
Slower
Harder to operate
Harder to correct
Harder to regulate
Harder for users to understand

without solving a necessary problem.

The correct question is not:

How can blockchain be added to this product?

It is:

Which party should control the authoritative state, who must verify it independently, and what is the simplest architecture that satisfies that trust requirement?

Sometimes the answer will be a public blockchain.

Sometimes it will be a permissioned consortium ledger.

More often, it will be a database, an API or a signed audit log.

Choosing the simpler architecture is not a failure to innovate.

It is good software engineering.

Frequently Asked Questions

What is blockchain?

Blockchain is a distributed, cryptographically linked ledger maintained and validated by a network of participants.

Does every software product need blockchain?

No. Most products work more effectively with conventional databases, APIs and managed services.

What is the clearest sign that blockchain may be needed?

Several independent parties must write or validate shared state, and no acceptable central authority can control the definitive record.

Is blockchain better than a database?

Not generally. Databases are usually faster, simpler and easier to manage. Blockchain provides a different trust and governance model.

When should a traditional database be used?

Use a traditional database when one organisation controls the system and users accept it as the authoritative operator.

Can a blockchain record be changed?

Blockchain history is designed to be tamper-evident and resistant to change, but it should not be described as absolutely immutable in every circumstance.

Does blockchain guarantee data accuracy?

No. It preserves submitted transactions but cannot prove that off-chain information was correct when entered.

What is the oracle problem?

The oracle problem is the difficulty of securely bringing external facts—such as prices or delivery events—into a blockchain application.

What is a permissioned blockchain?

A permissioned blockchain restricts participation to approved and identifiable organisations or users.

What is a public blockchain?

A public blockchain allows open participation according to protocol rules and provides publicly verifiable state.

Does a permissioned blockchain require cryptocurrency?

No. Permissioned networks can operate without native or transferable tokens.

Does blockchain require smart contracts?

No. A blockchain may only record transactions. Smart contracts are needed when shared programmable execution is required.

When is a token justified?

A token is justified when digitally native transferable ownership, network incentives, staking or programmable settlement is part of the product model.

Can blockchain satisfy GDPR?

It may be possible to design GDPR-aware systems, but permanent replicated data creates significant challenges. Personal data should normally remain off-chain.

Should documents be stored on-chain?

Usually not. Store the document in controlled storage and record a commitment, keyed hash or proof when necessary.

Can an append-only log replace blockchain?

Yes, when the primary need is tamper evidence rather than distributed consensus among independent writers.

Is blockchain useful for supply chains?

It can be useful where several independent organisations require shared, verifiable records, but it cannot ensure that physical events or supplier claims are truthful.

Does blockchain eliminate intermediaries?

Not necessarily. It may replace one intermediary while introducing validators, wallet providers, oracle operators, software maintainers and governance bodies.

What is the biggest blockchain implementation risk?

The largest strategic risk is using blockchain where a simpler architecture would solve the problem more effectively.

How should a company begin evaluating blockchain?

Define the business problem, map the participants and trust relationships, compare simpler alternatives and pilot the governance model with independent organisations.