The interesting thing about enterprise blockchain in 2026 is not that adoption grew. It is that the surviving use cases cluster tightly in one band and the abandoned ones cluster just as tightly in another. The pattern is consistent enough to use as a filter before you spend anything.
The short version: a shared ledger earns its place when it removes a reconciliation between organisations that will not accept each other's records. If it only removes a spreadsheet inside one organisation, you are buying an expensive database with a governance committee attached.
The four conditions
Run any candidate through these. Three or four, look seriously. Two or fewer, build the boring thing.
- More than one organisation writes to the record.
- None of them will accept another's copy as authoritative.
- Disagreement is measurably expensive: reconciliation headcount, settlement delay, cost of funds, failed trades, dispute resolution.
- Someone outside the group, usually a regulator or an auditor, needs to verify without asking a participant for permission.
Notice what is absent from that list. Immutability, transparency, decentralisation and cost reduction in the abstract are properties, not reasons.
Why the use cases that worked are financial
The categories that moved from pilot to production are almost all cash adjacent: tokenized treasuries and money market funds, tokenized deposits, collateral movement and repo, regulated settlement rails, and cross border payments between institutions.
They pass all four conditions cleanly. Several institutions transact, none keeps the others' books, settlement delay carries an interest cost you can attach a number to, and independent verification is a regulatory expectation rather than a nice idea.
There is a second reason these worked where provenance projects did not. The asset is already digital and can be made legally native to the ledger. When the token is the instrument rather than a pointer to one, transferring the token transfers the asset, and the reconciliation genuinely disappears. Where the token only points at an off chain register that somebody else still controls, you have added a system rather than removed one.
That distinction, legal finality on the ledger, is what separates a real settlement system from a synchronised copy of a database.
Where the picture is mixed
Provenance, trade documents and multiparty logistics still make sense on paper and still fail more often than they succeed. Neither reason is technical.
The first is the input problem. A ledger guarantees a record was not altered after it was written. It guarantees nothing about whether the record was true when written. If a certificate or a weight is keyed in by hand, immutability preserves the error permanently and gives it an unearned air of authority.
The second is commercial. The largest shipping ledger consortium of the last decade wound down with the technology working fine. Participants would not share commercially sensitive data with competitors, and a network missing its major participants is worth very little. Incentives killed it, not cryptography.
These use cases can work, but only where a genuine consortium already exists, where the physical to digital link is solved with hardware rather than trust, and where every member gains more than they give up.
Where a shared ledger is the wrong tool
Say no early in these cases:
- Audit trails inside a single company. Append-only tables, signed log entries and write-once storage give you tamper evidence without validators, partners or gas.
- Document management projects rebranded as data integrity projects.
- Anything holding personal data. Erasure obligations and immutable storage are in direct conflict, and hashing personal data does not reliably escape that.
- Designs where everything meaningful lives off chain and only hashes go on chain. Ask plainly what the ledger buys at that point.
- ERP replacement. Enterprise systems fail at the integration boundary, not at the ledger.
The recentralization question the pitch skips
Somebody has to run the validators, the ordering service or the sequencer. Somebody holds the upgrade key and the permissioning roles. Ask who, in writing, before committing.
If the answer is one dominant member, you have rebuilt the incumbent intermediary with added latency and a consensus protocol.
Two answers survive scrutiny. Either use a public chain as a neutral settlement layer that no member controls, accepting the data constraints that come with it. Or build a consortium with rotating operators, a written dispute procedure, and a timelock on privileged actions so no participant can change the rules quietly.
Compliance is a design input
For regulated assets, eligibility rules belong inside the token. Permissioned standards such as ERC-3643 place identity, claims and transfer restrictions at contract level, so an ineligible transfer fails at the contract instead of surfacing later in a report.
Decide early which jurisdictions and investor categories are live at launch, where KYC and AML checks run and who stores the personal data, what the contract actually sees (an eligibility claim, never a document), and whether you need forced transfer and reissuance for lost keys or court orders.
That last answer alone eliminates several architectures.
Where the budget actually goes
Not to the smart contracts. Three lines dominate:
- Integration. Adapters into core systems, idempotent message handling, replay and reorganisation handling, and an off-chain read model so reporting never queries a chain directly. On most projects this is the majority of the work, and most enterprise failures are integration failures rather than cryptographic ones.
- Independent audits. Funded and scheduled, with scope frozen before review and budget for a second round after remediation. Do the invariant testing and fuzzing yourself first.
- Key management. Custody model, multisig thresholds, where the hardware lives, signer offboarding, and timelocks on admin actions. In a consortium this is governance, not operations.
We also insist that clients own the repositories, deployer accounts, admin roles and vendor accounts in their own name. In a multiparty network neutrality is the product, and a shared ledger whose keys sit with a vendor is not shared.
A shortlist worth evaluating
- Institutional settlement of cash equivalent instruments
- Collateral mobility across entities and jurisdictions
- Cross-border payments between counterparties with no common correspondent
- Private placements and fund administration, where the register is the reconciliation
- Carbon and renewable certificates, where double counting is the core failure mode
- Verifiable credentials issued by one organisation and checked by many
Every one of these still needs the four conditions applied honestly, including the possibility that your version fails the test.
Running the test costs a workshop. Discovering the answer after the build costs a year.
RWaltz Software Services builds custom blockchain, tokenization and enterprise software systems for organisations that intend to run them for years. We work on a build-to-own model: the client owns the code, the keys and the accounts. We scope honestly, we budget for independent audits, and we will tell you when a shared ledger is not the right answer.
