Every technology leader eventually faces the same question:
Should we use blockchain for this?
The answer should not depend on trends, investor expectations, or whether blockchain sounds innovative. It should depend on the architecture, governance model, trust boundaries, and economics of the system being designed.
After working on production blockchain and financial technology systems, I use the following framework to determine whether blockchain is justified.
The Core Decision Framework
Blockchain is worth considering when all three of the following conditions are present:
- Multiple independent parties need to read, write, or verify the same records.
- Those parties do not fully trust one another or do not want one organisation to control the system.
- A tamper-evident and independently verifiable audit trail is a critical requirement.
When one or more of these conditions are missing, a conventional database will usually be simpler, faster, cheaper, and easier to operate.
The Decision Matrix
| Requirement | Traditional Database | Blockchain | |---|---:|---:| | One organisation controls the system | Recommended | Usually unnecessary | | Multiple independent organisations participate | Possible | Potentially suitable | | Participants trust a central administrator | Recommended | Usually unnecessary | | No trusted central authority exists | Difficult | Strong use case | | Records must be independently verifiable | Requires additional controls | Native capability | | Transactions must be reversible | Straightforward | Often difficult | | High throughput and low latency are essential | Strong fit | Requires careful evaluation | | Public asset ownership or token transfer is required | Limited | Strong fit |
The key question is not whether blockchain can implement the system. It usually can.
The real question is whether decentralised consensus provides enough business value to justify the additional complexity.
A Good Use Case: Multi-Party Settlement
Consider three organisations that need to reconcile shared transactions.
Company A ───────┐
│
Company B ───────┼──── Shared Settlement Ledger
│
Company C ───────┘
Each company needs access to the same transaction history, but none of them wants another participant to have unilateral control over the records.
The conditions are:
- Multiple independent parties: Yes
- Trust boundaries between participants: Yes
- Shared audit trail required: Yes
- Central ownership undesirable: Yes
A permissioned blockchain or consortium ledger may be appropriate because it provides a jointly controlled record of settlement activity.
However, the governance model remains more important than the blockchain platform itself. The participants must still agree on:
- Who can operate validator nodes
- Who can onboard new members
- How software upgrades are approved
- How disputes are resolved
- What happens when a private key is compromised
- Whether transactions can ever be corrected or reversed
A Poor Use Case: User Authentication
Suppose an organisation needs to store user accounts and login credentials.
The conditions are:
- Multiple independent record owners: No
- Lack of a trusted central administrator: No
- Public verification required: No
- Decentralised consensus required: No
Blockchain would add complexity without solving a meaningful architectural problem.
A more appropriate solution would be:
Application
│
├── Identity service
├── PostgreSQL
├── Password hashing
├── Multi-factor authentication
└── Audit and security monitoring
The correct architecture is usually a conventional identity platform backed by a securely configured relational database.
The Trust-Boundary Test
Before choosing blockchain, identify every organisation or system that can:
- Create a record
- Update a record
- Validate a transaction
- Reject a transaction
- View restricted information
- Resolve a dispute
Then ask whether one party can reasonably operate the authoritative database.
When all participants already trust one organisation to host and administer the platform, blockchain may not provide meaningful decentralisation. It may simply replace one database with a more expensive distributed database.
The Signed-Log Alternative
Many systems do not require consensus across independent organisations. They only require evidence that records have not been modified.
In such cases, a cryptographically signed append-only log may be sufficient.
interface SignedEntry<T> {
id: string;
data: T;
timestamp: string;
previousHash: string;
dataHash: string;
signature: string;
}
Each new entry references the hash of the previous entry. The application signs the record using a protected private key.
This provides:
- Tamper evidence
- Historical integrity
- Verifiable authorship
- Lower operational complexity
- Conventional database performance
A signed audit log can therefore satisfy many integrity requirements without introducing distributed consensus.
The Cost Test
Blockchain costs are not limited to transaction or gas fees.
The full operating cost can include:
- Smart contract development
- Specialist security audits
- Node infrastructure
- Key-management systems
- Transaction monitoring
- Gas management
- Chain analytics
- Incident response
- Governance coordination
- Protocol and dependency upgrades
- Regulatory and legal review
A realistic comparison should consider total cost of ownership.
| Area | Conventional Platform | Blockchain Platform | |---|---|---| | Application development | Standard engineering skills | Additional blockchain expertise | | Security review | Application and infrastructure testing | Application, infrastructure, wallet, and smart contract review | | Data correction | Controlled database update | May require compensating transactions | | Key recovery | Central account recovery | Potentially complex or impossible | | Performance scaling | Mature scaling patterns | Network-dependent | | Governance | Centralised decision-making | Multi-party coordination | | Infrastructure | Database and application services | Nodes, indexers, wallets, RPC services, and monitoring |
Blockchain should only be selected when its trust and verification benefits exceed these additional costs.
The Decentralisation Test
Ask who genuinely needs decentralisation.
Potentially valid answers include:
- Competing organisations sharing a common transaction network
- Users who must independently own and transfer digital assets
- Participants operating across jurisdictions without a common trusted authority
- Public verification of asset issuance or transaction history
- Protocols that must interoperate with existing blockchain ecosystems
Weak answers include:
- It will make the product appear innovative
- Investors expect blockchain
- Competitors are using it
- The system may need a token later
- Blockchain is more secure by default
Blockchain does not automatically make an application secure. Poor smart contract design, compromised signing keys, insecure bridges, vulnerable frontend applications, and weak governance can still compromise the entire platform.
The Immutability Test
Immutability is useful when historical records must be protected from unilateral alteration.
However, immutability can become a liability when:
- Personal data must be deleted
- Incorrect records must be corrected
- Fraudulent transactions must be reversed
- Private information is accidentally published
- A smart contract contains a defect
- Regulatory requirements change
Before selecting blockchain, define how the system will handle mistakes.
Possible mechanisms include:
- Compensating transactions
- Contract upgrade patterns
- Emergency pause controls
- Governance-controlled corrections
- Off-chain storage with on-chain hashes
- Permissioned data access
- Key rotation and recovery procedures
A system without a correction strategy is not automatically trustworthy merely because its records are immutable.
The Performance Test
Traditional databases are optimised for low-latency reads and writes. Blockchain systems introduce consensus, replication, transaction finality, and execution constraints.
Evaluate:
- Expected transactions per second
- Maximum acceptable latency
- Finality requirements
- Data volume
- Query complexity
- Peak traffic
- Transaction cost volatility
- Availability requirements
- Geographic distribution
- Privacy requirements
Applications such as high-frequency order processing, internal reporting, authentication, and real-time operational systems will often perform better on conventional infrastructure.
A hybrid architecture may be more appropriate:
Operational Applications
│
▼
Primary Database
│
├── Real-time processing
├── Reporting
└── Business workflows
│
▼
Blockchain Anchor
│
└── Periodic integrity proof
This approach keeps high-volume processing off-chain while publishing selected proofs or settlement records to a blockchain.
When Blockchain Is Usually Appropriate
Multi-Party Financial Settlement
Several institutions need a shared and independently verifiable settlement record, and no participant should control the entire system.
Tokenised Assets
The product requires programmable ownership, transferability, interoperability, or access to existing digital-asset markets.
Cross-Organisation Data Exchange
Several organisations contribute records, and each needs confidence that another participant cannot silently alter historical information.
Decentralised Treasury Management
Funds require multiple independent approvals, transparent execution, and auditable control through mechanisms such as multisignature wallets.
Public Verification
External users need to verify ownership, issuance, authenticity, or transaction history without relying solely on the platform operator.
When a Database Is Usually Better
Use a conventional database when:
- One organisation controls the application
- Users already trust the platform operator
- Transactions must be corrected or reversed frequently
- High throughput and low latency are required
- Data must remain private
- Regulatory deletion requirements apply
- Independent consensus provides no additional value
- Blockchain would only serve as a marketing feature
PostgreSQL, MySQL, SQL Server, or another mature database will normally provide better performance, maintainability, reporting, and operational control in these cases.
Implementation Reality
Production blockchain systems require more than writing and deploying a smart contract.
A complete production environment may include:
User Application
│
▼
Backend API
│
├── Identity and access management
├── Transaction orchestration
├── Policy and limits engine
├── Blockchain RPC provider
├── Wallet or key-management service
├── Transaction indexer
├── Conventional database
├── Monitoring and alerting
└── Reconciliation service
Important operational concerns include:
- Secure private-key storage
- Transaction nonce management
- Failed and stuck transactions
- Blockchain reorganisations
- Smart contract upgrades
- RPC-provider outages
- Fee estimation
- Wallet recovery
- Reconciliation between on-chain and off-chain records
- Sanctions and compliance screening
- Incident response
The blockchain itself is only one component of the overall platform.
The Five-Question CTO Filter
Before approving blockchain architecture, ask:
1. Are there multiple independent parties?
When only one organisation creates and controls the data, a database is normally sufficient.
2. Is there a genuine trust boundary?
If all participants accept one central operator, distributed consensus may add little value.
3. Must participants verify records independently?
If independent verification is not required, conventional audit controls may be enough.
4. Does the system require blockchain-native assets or interoperability?
If users must own, transfer, or interact with digital assets across protocols, blockchain may be justified.
5. Can the organisation support the operational complexity?
The organisation must be able to manage keys, contracts, infrastructure, monitoring, governance, security reviews, and incident response.
If the answer to the first three questions is no, the recommendation should normally be a traditional database.
Final Decision Flow
START
│
▼
Are multiple independent parties involved?
│
├── No ──► Use a conventional database
│
▼ Yes
Is there a meaningful trust boundary?
│
├── No ──► Use a shared platform or database
│
▼ Yes
Must records be independently verifiable?
│
├── No ──► Use signed logs or conventional audit controls
│
▼ Yes
Is blockchain-native ownership or interoperability required?
│
├── No ──► Evaluate a permissioned ledger or signed database
│
▼ Yes
Can the organisation support the cost, governance, and security requirements?
│
├── No ──► Redesign or postpone implementation
│
▼ Yes
Blockchain may be appropriate
Conclusion
Blockchain is valuable when it solves a genuine coordination and trust problem between independent parties.
It is not a universal replacement for databases, identity systems, payment platforms, or enterprise integration.
The strongest technology decision is not the one that uses the newest infrastructure. It is the one that meets the business, security, governance, and operational requirements with the least unnecessary complexity.