Blockchain belongs in a software architecture when several independent parties need to create, approve or verify shared records, but no single party should have unilateral control over the history.

It usually does not belong in an application simply because the system processes transactions, stores sensitive data, requires an audit log or needs strong security.

Most of those requirements can be handled more efficiently with conventional databases, digital signatures, access controls, append-only event logs and well-designed APIs.

The real architectural question is not:

Can this application use blockchain?

Almost any application can.

The useful question is:

Does a distributed ledger solve a trust and coordination problem that conventional architecture cannot solve as effectively?

That distinction separates practical distributed-ledger systems from expensive technology demonstrations.

---

Quick answer: When should software use blockchain?

A software system should consider blockchain when:

• Multiple independent organisations need to update or approve shared records
• Participants do not want one organisation to control the authoritative database
• The history must be tamper-evident and independently verifiable
• Business rules require multi-party endorsement or consensus
• Records must remain portable across systems or jurisdictions
• A shared audit trail provides measurable operational or regulatory value

A conventional database is usually better when:

• One organisation owns and operates the system
• Transactions occur mainly inside one trusted environment
• Records need frequent correction or deletion
• Very high performance and low latency are priorities
• The application is primarily standard CRUD functionality
• Secure APIs already provide sufficient interoperability

The strongest blockchain use case is not “storing data securely.” It is coordinating trusted state across independent administrative boundaries.

Key takeaways

1. Blockchain is a form of distributed ledger, but not every distributed system or replicated database is a blockchain.
2. A blockchain provides tamper-evident history under defined technical and governance assumptions. “Immutable” should not be interpreted as magically impossible to change.
3. Blockchain does not confirm that submitted information is true. It records who submitted it, what was submitted and how the network agreed to accept it.
4. Smart contracts automate agreed rules, but they cannot independently know whether a shipment arrived, a document is genuine or a customer fulfilled an offline obligation.
5. Most enterprise applications should keep operational data, personal information, files and analytics off-chain.
6. A practical architecture often combines ordinary databases and APIs with a small permissioned-ledger layer for shared approvals, provenance and audit evidence.
7. Governance is usually harder than the blockchain code. Participants must agree on membership, data models, validation policies, upgrades and dispute resolution.

What is a blockchain?

A blockchain is a distributed digital ledger in which transactions are grouped into blocks and cryptographically linked to earlier blocks.

Copies of the ledger are maintained by multiple nodes. A consensus process determines which transactions are accepted and in what order.

NIST describes blockchains as distributed, tamper-evident and tamper-resistant ledgers that allow a community of participants to record transactions without relying on one central repository. [1]

A blockchain commonly combines:

• Cryptographic hashes
• Digital signatures
• Replicated ledgers
• Consensus or ordering mechanisms
• Transaction-validation rules
• Identity and key management
• An append-oriented transaction history

None of these components is unique to blockchain by itself. The architectural value comes from combining them to maintain a shared history among participants that may be operated by different organisations.

What is a distributed ledger?

A distributed ledger is a record system replicated across multiple nodes or participants.

Blockchain is one type of distributed ledger in which data is organised into cryptographically connected blocks. Other distributed-ledger approaches may use different data structures or consensus models.

The important distinction is not the shape of the data structure. It is the trust model.

A conventional distributed database is generally operated under one administrative authority. Replication improves availability, performance or disaster recovery, but one organisation still controls the system.

A distributed ledger can allow several organisations to maintain and verify a shared record without granting any one participant unrestricted authority over it.

Blockchain is not the same as a distributed database

Question	Distributed database	Distributed ledger or blockchain
Who normally governs it?	One organisation	Multiple organisations or an open network
Why is data replicated?	Availability and performance	Shared verification and coordinated state
Who can change records?	Authorised database administrators or applications	Participants operating under network rules
How are conflicts resolved?	Database consistency and application rules	Consensus, ordering and endorsement policies
Can history normally be rewritten?	Yes, with sufficient authority	Designed to make rewriting difficult and evident
Best fit	Operational application data	Shared, cross-organisational records
Typical performance	High	Lower because of validation and replication overhead
Governance complexity	Internal	Multi-party

Both technologies can be secure. Both can be distributed. The difference is the number of administrative authorities and how they agree on state.

The architectural problem blockchain actually solves

Blockchain addresses a specific class of problem:

Several parties need a common record, several parties may write to or approve that record, and the parties do not want one member to have exclusive control over the authoritative history.

Consider a manufacturer, supplier, logistics provider, certification body and regulator.

Each organisation may maintain its own database. When their records disagree, somebody must determine:

• Which version is authoritative
• Who changed a record
• When the change occurred
• Whether all required parties approved it
• Whether evidence was modified later
• Which organisation is responsible for an incorrect entry

A central platform can solve this by becoming the trusted intermediary.

A distributed ledger becomes relevant when the participants do not want one organisation to serve as that intermediary, or when independent verification of the shared history creates significant value.

The seven-question blockchain test

Before selecting a blockchain platform, answer these questions.

1. Are there multiple independent organisations?

Different departments in the same company are not necessarily independent parties.

A distributed ledger becomes more relevant when participants have separate ownership, infrastructure, incentives and legal responsibilities.

2. Do several parties need to write or approve records?

If one organisation writes all records and everyone else only reads them, a digitally signed database or API may be enough.

The case becomes stronger when several organisations create transactions, validate events or approve state changes.

3. Is there no acceptable central authority?

Participants may trust each other enough to cooperate but not enough to let one party control the complete record.

When everyone already accepts one organisation as the system owner, conventional architecture is normally simpler.

4. Does the history need independent verification?

A ledger may be useful when participants need to verify:

• Who submitted a transaction
• Which parties approved it
• The order of events
• Whether a record was changed
• Which rules were applied

5. Is shared consensus worth the overhead?

Consensus and replication create operational cost.

The value of shared governance must exceed the cost of slower processing, more complex infrastructure, key management and network coordination.

6. Can participants agree on governance?

A network cannot function sustainably without rules for:

• Membership
• Node operation
• Data access
• Transaction approval
• Software upgrades
• Emergency intervention
• Dispute resolution
• Participant removal

7. Can on-chain data be kept minimal?

A practical design should avoid putting large files, sensitive personal information and frequently changing operational records directly on the ledger.

---

When blockchain is a strong architectural fit

Multiple organisations need a shared source of evidence

The participants have separate systems but require one agreed record of selected events.

Examples include:

• Product custody changes
• Supplier certifications
• Regulatory approvals
• Cross-company asset transfers
• Shared insurance claims
• Trade-document processing

No participant should control the complete record

A consortium may want shared infrastructure without allowing the largest member to rewrite records or unilaterally change validation rules.

A permissioned ledger can distribute operational and validation responsibilities among members.

Transactions require multi-party endorsement

Some transactions should be accepted only when several organisations approve them.

For example:

• The manufacturer confirms dispatch
• The logistics provider confirms receipt
• The buyer confirms delivery
• The finance provider approves settlement

Hyperledger Fabric, for example, supports endorsement policies that specify which organisations must sign a transaction before it becomes valid. [3]

A tamper-evident audit trail is commercially valuable

An ordinary audit log is normally controlled by the organisation that operates the application.

A replicated ledger can allow several organisations to retain and verify the same history, making unilateral alteration more difficult.

Records must be verified outside the original platform

Blockchain may support portable verification when evidence must be checked by organisations that do not share the originating application.

Examples include:

• Certifications
• Accreditations
• Product provenance
• Ownership history
• Regulatory attestations
• Organisational authority records

Participants need an agreed execution layer

Smart contracts can encode agreed transaction rules so every participant evaluates the same logic.

This is valuable when automation must be shared rather than controlled by one organisation’s private application.

When conventional architecture is better

One organisation owns the application

A company building its own CRM, ERP, HR platform, job board or customer portal generally does not need blockchain.

The organisation already controls:

• User accounts
• Permissions
• Data storage
• Business logic
• Audit logs
• System administration

Adding distributed consensus does not remove a meaningful trust dependency because the same organisation still controls the application.

The application is standard CRUD software

Create, read, update and delete operations are usually handled more efficiently by a relational or document database.

Blockchain does not make ordinary application records inherently more useful.

Data changes frequently

Blockchain histories are append-oriented. Corrections are normally represented as new transactions rather than destructive edits to previous records.

This is valuable for historical evidence but inconvenient for data that must be routinely corrected, replaced or deleted.

Very high throughput or low latency is essential

Every additional node, endorsement rule and consensus step creates work.

A conventional database under one trusted operator can normally process internal transactions with less coordination overhead.

The system stores large files

Images, videos, contracts, reports, sensor streams and product documents should generally remain in object storage, document management systems or content-addressed storage.

The ledger can store:

• A cryptographic hash
• A document identifier
• A storage reference
• The submitting organisation
• A timestamp
• A status
• Approval evidence

A secure API already solves the problem

When organisations trust an authoritative source, a signed API response may provide faster, simpler and more current information than a replicated ledger.

Participants are unwilling to share governance

A blockchain network cannot fix political disagreement.

When participants cannot agree on rules, data definitions, responsibilities or funding, the technical network will not create trust for them.

Public blockchain or permissioned blockchain?

The choice should follow the governance model.

Public permissionless blockchain

A public blockchain may be appropriate when:

• Anyone should be able to participate or verify
• No approved membership list should control access
• The application depends on public digital assets
• Open composability is important
• A neutral public settlement layer is required
• Transactions must remain verifiable without consortium membership

Public networks typically introduce transaction fees, public metadata exposure, probabilistic or protocol-defined finality and limited control over infrastructure changes.

Permissioned blockchain

A permissioned ledger may be appropriate when:

• Participants are known organisations
• Membership requires approval
• Data access must be restricted
• Commercial confidentiality matters
• Governance is contractual or regulated
• Transaction validation must reflect organisational roles
• Network operators require predictable control

NIST distinguishes permissionless networks, where participation is broadly open, from permissioned networks, where access is restricted to defined people or organisations. [2]

Hyperledger Fabric provides permissioned-network features such as authenticated membership, channels, endorsement policies and private data collections. Channels can isolate ledgers and communications among selected participants. [3][7]

The practical enterprise default

For cross-company workflows involving manufacturers, suppliers, regulators and service providers, a permissioned ledger is often the more natural starting point.

That is not because permissioned blockchain is universally superior. It is because enterprise participants usually need identifiable membership, privacy controls and formal governance.

What smart contracts actually do

A smart contract is software executed according to the rules of a blockchain or distributed-ledger network.

It can:

• Validate transaction inputs
• Enforce permissions
• Check required approvals
• Update shared asset state
• Calculate an agreed result
• Reject transactions that violate rules
• Record execution in the ledger

In Hyperledger Fabric, smart contracts define executable transaction logic, while the ledger maintains current state and historical transactions. Endorsement policies determine which organisations must approve particular actions. [3]

Smart contracts are not autonomous legal intelligence

A smart contract does not understand:

• Whether a physical shipment arrived safely
• Whether a supplier behaved honestly
• Whether a photograph is genuine
• Whether a legal obligation was fulfilled
• Whether a sensor is malfunctioning
• Whether an external database is accurate

It can only process the data and rules available to it.

The oracle problem

Public smart contracts cannot independently retrieve real-world information while preserving deterministic network execution.

External data must be introduced through an oracle, signed message, API integration or authorised participant.

Ethereum’s documentation explicitly notes that smart contracts cannot obtain off-chain events by themselves. Oracle systems are therefore part of the trust model, not a minor technical detail. [4]

If a contract releases payment when an oracle reports that goods were delivered, the system must still answer:

• Who operates the oracle?
• How does it know delivery occurred?
• Can its key be compromised?
• What happens when sources disagree?
• Can the decision be challenged?

Blockchain can make the oracle’s submitted statement tamper-evident. It cannot make a false statement true.

Real applications where distributed ledgers can add value

1. Supply-chain provenance

A distributed ledger can record selected custody and transformation events across a supply chain.

Participants may include:

• Raw-material supplier
• Manufacturer
• Testing laboratory
• Logistics provider
• Distributor
• Retailer
• Regulator

The ledger might record:

• Batch creation
• Ownership or custody transfer
• Test-result references
• Certification status
• Shipment events
• Maintenance actions
• Recall notices

The physical goods and source documents remain outside the ledger. The ledger preserves evidence about which participant reported each event and how the event was approved.

Value created: Reduced reconciliation, clearer provenance and a shared basis for investigating disputes.

Limitation: The system still depends on accurate physical-to-digital data capture.

2. Shared compliance and audit evidence

Several organisations may need to prove that the same controls, approvals or reporting obligations were followed.

A shared ledger can record:

• Control attestations
• Approval events
• Policy versions
• Audit findings
• Remediation status
• Evidence hashes
• Accreditation status

A regulator or auditor can independently verify the sequence and origin of these events without receiving unrestricted access to every participant’s internal systems.

Value created: Consistent evidence and reduced duplication across organisations.

Limitation: Sensitive evidence often needs to stay off-chain, with only references and integrity proofs recorded on the ledger.

3. Credential and document trust registries

Blockchain can support trust registries that identify recognised issuers, accreditation authorities or credential-status information.

The European Blockchain Services Infrastructure uses permissioned blockchain-based trust registers to support verification while keeping personal credential data out of the ledger. [5]

This is an important architectural pattern:

• Credentials remain with the holder or in appropriate storage
• Personal data is not published on the ledger
• The ledger provides information needed to establish issuer trust
• Verifiers use the registry as one part of their decision

Value created: Cross-organisational verification without centralising every person’s document.

Limitation: Blockchain is only the trust-registry layer; credentials, wallets, policies and governance remain separate components.

4. Multi-party approvals and settlement

A contract, invoice or shipment milestone may require approval from several parties.

A smart contract can enforce rules such as:

• Buyer and supplier must approve the quantity
• Logistics provider must confirm delivery
• Inspector must confirm quality
• Finance must authorise settlement
• No single participant may complete the process alone

Value created: Shared workflow execution and clear responsibility.

Limitation: Fiat payment, delivery and inspection usually occur through external systems that must be integrated securely.

5. Shared asset or ownership records

A ledger may track ownership or status of assets that move among organisations.

Examples include:

• Industrial equipment
• Shipping containers
• Renewable-energy certificates
• Digital assets
• Licences
• Intellectual-property rights
• Maintenance entitlements

Value created: A common ownership history available to authorised participants.

Limitation: Legal ownership depends on the relevant legal framework, not solely on a ledger entry.

6. Digital Product Passport ecosystems

A Digital Product Passport platform may receive information from manufacturers, suppliers, laboratories, recyclers and certification bodies.

A distributed ledger could record:

• Who supplied an important claim
• Which organisation approved it
• Which version was current at a given time
• Whether a supporting document was replaced
• Which actor changed a product status
• Which certification authority issued an attestation

The complete product passport should not be placed on-chain.

Instead, the ledger can support provenance and assurance for selected high-value claims while conventional systems handle product data, documents, user interfaces, analytics and regulatory reporting.

Value created: Traceable claims across a multi-party product ecosystem.

Limitation: Poor source data remains poor source data, even when its origin is cryptographically recorded.

The best production design is usually hybrid

A blockchain should rarely become the main database for an enterprise application.

The application still needs:

• User interfaces
• Authentication
• Role and permission management
• Operational databases
• Search indexes
• Reporting systems
• File storage
• APIs
• Notifications
• Monitoring
• Customer support tools
• Analytics

The ledger should be assigned only the responsibilities that require distributed trust.

What should remain off-chain?

Normally keep these outside the ledger:

• Personal and customer data
• Product images and documents
• Application sessions
• Search indexes
• Analytics data
• Sensor streams
• Email and notification content
• Internal notes
• High-volume operational events
• Frequently modified records
• Large files
• Confidential commercial terms

What may belong on-chain?

Potential ledger records include:

• Transaction identifiers
• Asset-state transitions
• Approvals
• Signatures
• Document hashes
• Provenance references
• Credential-status references
• Policy versions
• Compliance attestations
• Shared workflow events
• Ownership transfers
• Dispute-resolution outcomes

Example hybrid flow

1. A supplier uploads a certificate to the application.
2. The certificate is stored in encrypted document storage.
3. The application calculates a cryptographic hash.
4. The supplier signs a ledger transaction containing the hash, certificate type and product identifier.
5. A certification body approves the transaction.
6. The ledger records the submissions and approvals.
7. The application indexes the information in its operational database.
8. A verifier retrieves the document from authorised storage and checks that its hash matches the ledger entry.

The blockchain provides shared integrity evidence. It does not replace the document repository, access-control service, application database or user interface.

Blockchain compared with architectural alternatives

Requirement	Recommended starting point
Standard transactional application	Relational database
Internal historical audit	Append-only audit table or event store
Cross-company data access	Secure APIs
Document authenticity	Digital signatures and hashes
Identity and qualification evidence	Verifiable credentials
Fast cache or session state	Key-value store
Distributed availability under one owner	Replicated database
Shared state among independent organisations	Consider a distributed ledger
Public digital asset ownership	Consider a public blockchain
Multi-party workflow approval	Permissioned ledger may be appropriate

Event sourcing

Event sourcing stores state changes as an ordered event history.

It provides many audit and reconstruction benefits associated with blockchain but remains under the control of the system owner.

Use event sourcing when:

• One organisation controls the application
• Historical reconstruction is required
• Domain events are valuable
• External consensus is unnecessary

Cryptographically signed audit logs

Signed or hash-linked logs can make tampering detectable without operating a blockchain network.

Use them when:

• One organisation writes the records
• External auditors need integrity evidence
• Distributed consensus is unnecessary

Shared database managed by a neutral operator

A trusted industry body or service provider can operate a common database.

This may be simpler than blockchain when participants accept the operator’s authority.

Verifiable credentials

Verifiable credentials can make claims portable and cryptographically verifiable.

They do not always require blockchain. A ledger may be added for issuer trust, accreditation or status information when shared governance requires it.

Data truth versus ledger integrity

One of the most important distinctions is:

Blockchain can protect the integrity of recorded data. It cannot guarantee the truth of the original input.

If a supplier falsely reports that a material is recycled, a blockchain can reliably preserve the false report.

The system still needs:

• Trusted issuers
• Testing processes
• Audits
• Sensor assurance
• Legal accountability
• Data-quality controls
• Fraud detection
• Correction and dispute procedures

A distributed ledger can improve accountability because it records who submitted the claim and what evidence was provided.

It cannot replace real-world verification.

What “immutable” should mean

Marketing descriptions often call blockchain records immutable.

A more accurate term is tamper-evident and tamper-resistant.

Ledger history can still be affected by:

• Governance decisions
• Software upgrades
• Network capture
• Compromised keys
• Consensus failures
• Application bugs
• Protocol forks
• Administrative intervention
• Collusion among authorised members

In a permissioned network, a sufficiently powerful group of governing members may be able to change network rules or coordinate corrective action.

The architectural value is not absolute immutability. It is that changing accepted history is significantly more controlled, detectable and difficult than editing one organisation’s database.

Security risks do not disappear

Blockchain introduces different security responsibilities.

Private-key compromise

A valid digital signature proves that a key authorised a transaction. It does not prove that the legitimate user controlled the key at that moment.

Production systems require:

• Secure key storage
• Hardware-backed protection where appropriate
• Rotation
• Revocation
• Recovery
• Organisational custody policies
• Separation of duties

Smart-contract vulnerabilities

Smart contracts can contain:

• Access-control failures
• Incorrect business logic
• Reentrancy problems
• Arithmetic or precision errors
• Oracle manipulation
• Upgrade vulnerabilities
• Denial-of-service conditions
• Front-running or ordering risks
• Signature-verification flaws

OWASP maintains a current Smart Contract Top 10 and a security-verification framework for designing and testing smart-contract systems. [6]

Privacy leakage

Even when personal data is kept off-chain, metadata can expose:

• Which organisations transact
• Transaction frequency
• Asset relationships
• Timing
• Participant behaviour
• Commercial activity

Permissioned access does not eliminate metadata risk.

Node and infrastructure security

Nodes, APIs, wallets, integration services and administrator interfaces remain ordinary software infrastructure and must be secured accordingly.

Oracle and integration risk

A secure ledger connected to a compromised API still receives compromised information.

The boundary between on-chain and off-chain systems is often the most important security boundary in the architecture.

Governance is part of the software design

A permissioned network needs a governance model before production deployment.

The participants should agree on:

Membership

• Who may join?
• Who approves admission?
• Who operates nodes?
• What identity evidence is required?

Transaction authority

• Who may submit each transaction type?
• Which organisations must endorse it?
• Can authority be delegated?

Data visibility

• Which participants can access each record?
• Which data remains private?
• Which metadata is visible to the network?

Software upgrades

• Who approves contract changes?
• What voting threshold is required?
• How are emergency patches handled?
• How are incompatible versions prevented?

Disputes and corrections

• What happens when a participant submits incorrect data?
• How is a correction recorded?
• Who can suspend a participant?
• Can a transaction be marked as disputed?

Cost and operation

• Who pays for infrastructure?
• Which organisation provides support?
• What availability level is required?
• How are new participants onboarded?

A technically decentralised system can remain operationally centralised when one vendor controls the code, hosting, identity service and upgrade process.

Architecture reviews should evaluate actual control, not only the number of ledger nodes.

A practical implementation roadmap

Phase 1: Describe the trust problem

Write the problem without using the words blockchain, Web3, token or smart contract.

For example:

Five organisations need to approve product-certification events, and none of them should be able to rewrite the shared history alone.

When the problem cannot be explained without naming the technology, the use case may not be mature.

Phase 2: Map participants and authority

Identify:

• Data creators
• Approvers
• Consumers
• Regulators
• Auditors
• Network operators
• Dispute authorities

Phase 3: Compare simpler alternatives

Evaluate:

• Central database
• Neutral platform operator
• Signed APIs
• Event sourcing
• Digital signatures
• Verifiable credentials
• Hash-linked audit logs

Document why those alternatives are insufficient.

Phase 4: Select the ledger model

Decide whether the network should be:

• Public or permissioned
• Token-based or non-token-based
• Open-verification or restricted
• Fully replicated or privacy-partitioned
• Consortium-governed or publicly governed

Phase 5: Minimise ledger data

Define exactly what goes on-chain.

Prefer identifiers, hashes, status values, approvals and state transitions over complete business records.

Phase 6: Define contracts and endorsement policies

Specify:

• Valid transaction types
• Required signatures
• State-transition rules
• Authorised roles
• Error conditions
• Versioning
• Emergency controls

Phase 7: Threat-model the complete architecture

Include:

• Ledger nodes
• Smart contracts
• APIs
• Oracles
• Wallets
• User interfaces
• Key stores
• Identity providers
• Off-chain databases
• Administrator access

Phase 8: Build an interoperability pilot

Test with at least two independently operated organisations.

A pilot in which one development team controls every node does not prove cross-organisational governance.

Phase 9: Measure business outcomes

Measure:

• Reconciliation time
• Disputes
• Manual approvals
• Verification time
• Audit preparation effort
• Failed transactions
• Infrastructure cost
• Support incidents
• Participant onboarding time

Phase 10: Establish an exit strategy

Define how the ecosystem will operate if:

• A vendor closes
• A participant leaves
• The ledger platform is replaced
• Keys are compromised
• Data must be migrated
• Governance breaks down

A production architecture should not depend on indefinite survival of one blockchain vendor or protocol.

A compact decision framework

Consider a distributed ledger when this statement is true:

Multiple independent organisations need to maintain and verify shared state, no acceptable single owner exists, and tamper-evident multi-party history creates enough value to justify consensus, governance and operational complexity.

Use conventional architecture when this statement is true:

One organisation can legitimately operate the authoritative system, and databases, signatures, audit logs and APIs satisfy the security and interoperability requirements.

Conclusion

Blockchain is neither a universal replacement for databases nor a technology limited to cryptocurrency.

It is a specialised coordination mechanism.

It belongs in everyday software architecture when independent organisations need:

• Shared state
• Multi-party control
• Tamper-evident history
• Portable verification
• Agreed transaction rules
• Independently verifiable approvals

It does not belong where a conventional system already has a legitimate owner and sufficient trust.

The best blockchain architecture is often the one in which the blockchain appears smallest:

• Operational records remain in ordinary databases
• Documents remain in appropriate storage
• APIs handle integrations
• Identity systems manage users
• Analytics platforms process reporting
• The ledger records only the shared facts that require distributed trust

That approach removes the hype and treats blockchain as what it actually is: one architectural component with a narrow but potentially valuable job.

Frequently Asked Questions

When should blockchain be used in software architecture?

Blockchain should be considered when multiple independent parties need to write, approve or verify shared records without giving one party complete control over the authoritative history.

Is blockchain better than a database?

No. A database is usually better for applications operated by one organisation, high-volume transactions, frequently changing records and ordinary CRUD functionality. Blockchain is useful for shared state across independent organisations.

Does blockchain make data true?

No. Blockchain can show who submitted data and whether the recorded data was altered. It cannot prove that the original input was factually correct.

Does enterprise blockchain need cryptocurrency?

No. A permissioned distributed ledger can operate without a publicly traded cryptocurrency or token.

What is the difference between public and permissioned blockchain?

A public blockchain generally allows open participation or verification. A permissioned blockchain restricts participation to identified and authorised members under a defined governance framework.

Should personal data be stored on a blockchain?

Generally, personal and sensitive data should remain off-chain. A ledger can store identifiers, hashes, approvals or status references where appropriate.

What should be stored on-chain?

Good candidates include shared approvals, asset-state transitions, document hashes, provenance events, signatures, policy versions and compliance attestations.

What should remain off-chain?

Operational records, personal data, documents, images, analytics, search indexes, internal notes and high-volume transactions should normally remain in conventional systems.

Are smart contracts legally binding contracts?

Not automatically. A smart contract is executable software. Its legal status depends on applicable law, contractual arrangements, jurisdiction and how the code relates to the parties’ legal agreement.

Can smart contracts access real-world information?

Not directly. They require oracles, signed messages, APIs or authorised participants to introduce off-chain information.

Is blockchain immutable?

Blockchain is more accurately described as tamper-evident and tamper-resistant. Its security depends on consensus, governance, key protection, participant behaviour and implementation quality.

Can blockchain replace APIs?

No. Blockchain systems still need APIs, integration layers and application services. A ledger normally complements rather than replaces these components.

Is blockchain appropriate for Digital Product Passports?

It can support selected functions such as claim provenance, multi-party attestations, certification status and shared audit history. The complete product passport and its documents should generally remain off-chain.

What is the biggest enterprise blockchain challenge?

Governance. Participants must agree on membership, transaction policies, data visibility, software upgrades, cost, liability and dispute resolution.

How can a business test whether it needs blockchain?

Start by describing the cross-organisational trust problem, compare simpler alternatives and pilot only the shared records that genuinely require distributed control.