Distributed Ledger Technology
A shared record, without a shared blind spot.
A distributed ledger is worth its complexity when several organizations need one record that each can check for itself. ColdAI helps decide whether that is your situation, then designs the transactions, governance, key management and integrations around the chosen network. The practice covers public and private ledger architectures, with specialist work on Hedera, tokenisation, decentralised identity and certificates.
The opportunity
Start with a decision
worth improving.
Several organizations need a consistent record of an event, but none wants to depend solely on another party's private database. The system needs explicit participants, rules and evidence.
From possibility to a working system
Follow the flow.
Three connected decisions. One considered architecture.
Conceptual flow, not a live system or measured result.
Define the trust boundary
Identify the parties, disputes and records the system must resolve. Compare a shared ledger with a conventional database before committing to network complexity or public disclosure.
Record a verifiable event
Design transaction structure, identifiers and the data held off-chain. Establish signing, validation and access rules so participants can check what a record actually proves.
Connect the business process
Integrate receipts with the systems and people that act on them. Plan key management, corrections and operating responsibilities alongside the initial network integration.
The work, made concrete
What we can build
with your team.
We agree scope, dependencies and acceptance criteria before delivery. Your project can start with an assessment, a pilot or an integration into an existing system.
A ledger suitability assessment
Clarify the system boundary, the responsible owners and the decisions the architecture needs to support.
Transaction and integration architecture
Turn the agreed design into reviewable work, evaluated against representative inputs and explicit success criteria.
Governance and key-management design
Make the next step operable: document responsibilities, known limitations and the path from pilot to ongoing use.
In depth
Go deeper into distributed ledger design
Start by testing whether your use case needs a ledger at all, then choose the network model that fits your participants.
- 01ChecklistDo you need a blockchain? A suitability checklistTwenty questions that test whether a use case needs a distributed ledger or a conventional system, covering trust, disclosure, off-chain data and governance.
- 02ComparisonPublic vs permissioned ledgers for enterprise useCompare public, council-governed, consortium and hybrid ledger models on governance, admission, privacy, finality, fees, interoperability and exit options.
Matching a multi-party problem to the right starting point
Start from the question the participants keep disputing. It tells you which practice leads and what belongs on the ledger at all.
| The disputed question | Where to start | What the ledger holds | What stays off the ledger |
|---|---|---|---|
| Who owns or is entitled to this asset? | Tokenisation | Token balances, transfer rules and lifecycle events | Legal agreements, investor files and valuations |
| Does this person, device or agent hold a valid credential? | Decentralised identity | Issuer keys, identifiers and revocation status | The credentials themselves and any personal data |
| Is this certificate or credit genuine and still unretired? | Certificates and carbon credits | Issuance, transfer and retirement records | Project evidence, audit reports and methodology documents |
| What happened, and in what order, between organizations? | Hedera Consensus Service | Ordered, timestamped messages or document hashes | The documents and records the hashes refer to |
| Should value move automatically when agreed conditions are met? | Hedera smart contracts | Contract state and the settlement rules | Inputs from external data sources, which need their own verification |
If none of these questions describes a real dispute between separate organizations, read the suitability checklist before going further.
What a ledger entry proves, and where that proof runs out
A ledger entry proves that a specific key signed a specific piece of data, and that the network accepted it in a particular order at a particular time. It does not prove that the data described the world accurately. A falsified inspection report recorded on-chain is still falsified; the ledger simply makes it impossible to change later without trace. Designs therefore need verification where data enters: signed sensor readings, accredited inspectors, independent attestations or reconciliation against authoritative registers.
Mistakes are handled by adding entries, not editing them. A correction becomes a new, signed record that references the one it supersedes, so the history shows both the error and its fix. Business systems must be built to read the latest valid state rather than assume the first record is final.
That permanence collides with data protection law. The General Data Protection Regulation (EU) 2016/679 gives individuals a right to erasure in Article 171, which a record designed never to change cannot honor directly. The usual answer is to keep personal data off the ledger entirely and record only salted hashes, references or revocation status, so that deleting the off-ledger data leaves nothing personal behind on-chain.
Operating duties that begin the day a ledger goes live
Pilots rarely exercise these. Production systems depend on them.
How ColdAI works on distributed ledger projects
Engagements typically begin with a ledger suitability assessment, which compares a shared ledger with a conventional database and names the parties, disputes and records involved. If a ledger is justified, the next pieces are the transaction and integration architecture and the governance and key-management design, including who operates what once the system is live.
The practice covers public and private ledger architectures and cross-chain interoperability. Much of its delivery work is on Hedera, where ColdAI is a member of The Hashgraph Association and works across token, consensus and smart contract services and permissioned networks through the Hedera practice. Choosing between network models is covered in public versus permissioned ledgers.
Useful inputs at the start are a clearly described multi-party coordination problem, an outline of each participant's responsibilities, and early thinking about data privacy and who will run the system.
Frequently asked questions
Is distributed ledger technology the same thing as blockchain?
Blockchain is one kind of distributed ledger, in which records are grouped into blocks linked by hashes. Other designs reach agreement differently; Hedera, for example, uses a hashgraph rather than a chain of blocks. For most business decisions the distinction matters less than the network's governance, privacy options, finality and cost.
Which ledger networks does ColdAI build on?
The practice works with both public and private ledger architectures. Its deepest specialization is Hedera, including the token, consensus and smart contract services, the Hedera studios and permissioned networks through HashSphere. Network choice follows the use case: governance, confidentiality, finality and cost requirements decide it, not a default preference.
Can a distributed ledger work alongside our ERP and existing databases?
It has to. In most designs the ERP or operational system remains the place where work happens, while the ledger holds a verifiable record of key events. Integration services sign and submit transactions, then write network receipts back so the business record shows what was confirmed. Reconciliation between the two is designed from the start.
How should personal data be handled on a distributed ledger?
Keep it off the ledger. Store personal data in systems that support correction and deletion, and record only non-identifying proofs such as salted hashes, credential status or references on-chain. This keeps the ledger useful for verification while allowing data protection obligations, such as erasure requests, to be met in the off-ledger systems.
What does a ledger suitability assessment produce?
A clear answer on whether a shared ledger is justified for the problem, with the reasoning set out: the participants, the trust and dispute issues, what data would sit on and off the ledger, and the governance and operating questions still open. If a ledger is not justified, it identifies the simpler design that fits.
Sources
Connect the architecture
Go deeper into the stack.
Explore the complementary capabilities that can turn an individual technology into a complete workflow.
Your next move
Bring us the
real problem.
A workflow that takes too long. A system that cannot connect. An idea that needs a technical path. Start there, and we can define what to investigate, build and measure.
- A multi-party coordination problem
- Defined participant responsibilities
- A data privacy and operating model