Get in Touch
Blockchain Scope Method Coverage Alternatives FAQ
Scope Method Coverage Alternatives FAQ
About Us
AI Solutions overview AI Consulting Services AI Strategy and Readiness Enterprise AI Implementation Generative AI Consulting Agentic AI Consulting AI Automation AI Integration
Oracle Services overview Oracle Fusion Cloud Oracle Fusion Financials Oracle Fusion HCM Oracle Fusion SCM Oracle Fusion Project Oracle Sales Cloud Oracle EPM Planning and Budgeting Oracle Hyperion Financial Accounting Hub Oracle BI Integration Oracle Technology Oracle SOA Suite Oracle DBA Oracle APEX Oracle OIC Oracle VBCS Oracle E-Business Suite EBS Upgrade and Support EBS Migration to Cloud Oracle NetSuite NetSuite SuiteScript NetSuite CRM NetSuite Supply Chain, Inventory & Manufacturing NetSuite HCM NetSuite Analytics & AI
Salesforce overview Salesforce Implementation Salesforce Integration Salesforce Managed Services Agentforce and Salesforce AI Salesforce Migration
Microsoft Enterprise Services overview Microsoft Dynamics 365 F&O Microsoft Business Central Microsoft Power BI The .NET Framework
Application Management overview Java Development Mobility Solutions Android App Development React Native Xamarin Universal Windows Platform Automation Testing Services Katalon Selenium DevOps Web Development LAMP Stack MEAN Stack E-commerce Solutions Enterprise E-commerce
Managed IT Services overview Infrastructure Monitoring Network Support End User Support System Support Managed Cloud Services Managed Security Services
Managed Business Services overview Logistics BPO Services Finance and Accounting Services Healthcare BPO Services Mortgage Loan Processing Order Processing
AtomicRoute Enterprise AI Atomic HR
Manufacturing Government and Non-profit IT Services and Networks Education Real Estate Media Logistics Pharmaceutical
Insights Newsroom Gallery Why AtomicNorth Get in Touch

Most proposals fail
the first test

Distributed ledger work for the cases that genuinely need it, and a straight answer for the ones that do not, which in our experience is the larger group by a wide margin.

The honest test is whether several parties who do not trust each other must write to the same record. If one organisation controls the data, a database with an audit log is cheaper, faster and easier to fix.

Get in touch See the qualification test
First questionWho must write?

If the answer is one organisation, the answer is not a blockchain.

Usual alternativeA database and an audit log

Append-only tables, signed records and retention give most of the wanted properties.

Where it fitsShared state, low trust

Several independent parties, a record none of them should solely control.

What we will sayNo, when it is no

We would rather lose the engagement than build a ledger for a single-owner process.

What we deliver

Qualification first, then engineering

This is the family where vendor noise is thickest, so the most valuable thing we do is often the disqualification. Where a case does survive the test, it needs the same integration and operations discipline as any other system.

Qualification and disqualification

A short structured assessment against the questions that actually decide it: who writes, who must not be able to rewrite, what happens when parties disagree, and what governance exists between them.

Failing the test is the common result and it is delivered as a clear recommendation with the conventional alternative costed alongside it.

A defensible yes or no, in writing, with reasoning.

Supply chain provenance

Multi-party traceability where suppliers, carriers, processors and buyers each contribute records that none of them should be able to amend afterwards.

The hard part is almost never the ledger. It is getting the parties to agree on identifiers, data quality and who is accountable when a record is wrong.

A shared history the parties can each verify independently.

Tokenisation and digital assets

Representation of assets, entitlements or instruments on a ledger, with the custody, identity and regulatory questions treated as design inputs rather than afterthoughts.

The technology is the smaller half. Legal enforceability, custody of keys and the redemption path are what determine whether the thing is usable.

A design where the off-chain obligations are explicit.

Smart contract development and review

Contract design, implementation, testing against adversarial cases, and independent review of contracts written by someone else.

Code that moves value and cannot be patched in place needs a different standard of care from an internal application, including an upgrade and pause strategy decided in advance.

Contracts reviewed adversarially before anything is at stake.

Integration with the estate

Connecting a ledger to the systems that run the business: the ERP, the warehouse system, the payment rail, the reporting layer.

This is where most pilots stall, and it is the part we are actually built for, because the same firm usually runs those systems already.

A pilot with somewhere to go afterwards.

Operations and key management

Node operation, monitoring, upgrade coordination across participants, and the key custody and recovery arrangements behind all of it.

Key loss is the failure mode with no support ticket. Custody, backup and recovery are designed before the first key is generated.

A network someone is accountable for running.

How we qualify a ledger case

TestOneParties

Who has to write to the record, and are they genuinely independent organisations with divergent interests, or departments inside one company?

Internal departments do not need a trustless protocol between them. They need a system of record with permissions and an audit trail.

You receive:

The party test

The writing parties named, their relationship described, and a judgement on whether trust between them is actually the problem.

One writer is a fail. Several writers who all trust a shared administrator is also a fail.

TestTwoTrust

Would any single party accept another operating the master record, and what specifically goes wrong if one of them can amend history?

If everyone is comfortable with a neutral operator, or with the largest party running it, a conventional shared system is the cheaper answer.

You receive:

The trust test

The harm from unilateral amendment stated concretely, and whether an append-only database with signed entries and external audit would address it.

Regulatory or contractual reasons for immutability are recorded here if they exist.

TestThreeGovernance

Who decides on schema changes, admission of new participants, dispute resolution and the response to a defect once the network is live?

This is where consortium projects die. The technology is tractable and the multi-party governance is not, and it does not get easier after launch.

You receive:

The governance test

A named decision-making arrangement between participants, or an honest statement that none exists yet and the project is not ready.

Without this, a pilot is a demonstration with no route to production.

TestFourBuild

Cases that pass all three go to design and build: platform selection, contracts, integration, node operations and key management.

Cases that fail get the alternative designed instead, usually an append-only store with signed records, retention controls and independent audit.

You receive:

A build plan or a better alternative

For a pass: architecture, platform choice with reasoning, contract scope, integration points and an operating model across participants.

For a fail: the conventional design that delivers the properties you actually wanted, costed.

01
Coverage

Cases that pass, and cases that do not

This table is deliberately blunt. The right-hand column is the one that saves money, and it applies to most enquiries we receive.

Blockchain coverage
ProposalWho writesVerdictWhat we recommend instead
Internal audit trail for approvals One organisationFailAppend-only tables with signed entries and access logging
Document integrity for compliance One organisation, external auditor readsFailContent hashing with timestamps held by an independent party
Supplier traceability across tiers Many independent suppliers and buyersCan passPermissioned ledger, once identifiers and governance are agreed
Inter-company settlement and reconciliation Several counterparties with no shared administratorCan passShared ledger for the state, conventional systems either side
Customer loyalty points One organisation issues and redeemsFailA ledger table in the existing database, with reconciliation
Asset or entitlement tokenisation Issuer plus independent custodians and holdersCan passOnly alongside resolved custody, identity and regulatory positions
Data sharing between agencies Several bodies with statutory boundariesUsually failGoverned APIs with consent records and per-party access logging
Alternatives

A database with an audit log solves most of this

When we unpick what a client actually wants from a blockchain, it is usually one of four things: records nobody can quietly change, a verifiable history, several parties seeing the same data, or proof that a document existed at a point in time. Each of those has a conventional answer that is cheaper to build, easier to change and supportable by people you can already hire.

Append-only storage, cryptographic signing of entries, hashes deposited with an independent party, and governed APIs between organisations cover the great majority of it. We would rather build you that and be honest about why than sell a consortium network that never gets past its pilot.

Ask for a ledger qualification
  • Immutability without a ledgerAppend-only tables, signed and hashed entries, and separated write and delete rights give tamper evidence inside one organisation.
  • Proof of existenceHashing a document and depositing the hash with an independent party proves it existed unchanged, without a network to operate.
  • Shared visibilityGoverned APIs with per-party access logging let several organisations see the same data while one of them remains accountable for it.

Indicative alternatives. Which one applies is decided during qualification, against what you actually need to prove.

Questions we get asked

Before funding a ledger

Our board has asked for a blockchain strategy. What do we tell them?

That the useful strategy is a test rather than a programme: which of our processes involve several organisations that must write to one record and do not trust each other to hold it. If the answer is none, the strategy is one page saying so, which is a better result than a pilot that quietly ends after a year. We are happy to write that page and to present the reasoning.

Is a private or permissioned chain the answer for internal use?

Usually not. A permissioned chain run by one organisation is a distributed database with extra operational complexity and a smaller pool of people who can support it. If you control all the nodes, you can also amend the history, so the immutability argument does not hold either. The exception is a consortium where the members are genuinely independent.

What about smart contracts for automating agreements?

They automate execution, not agreement, and they are only as good as the data feeding them. Where the parties, trust and governance tests pass, they are genuinely useful for settlement and conditional transfers. Where a single company wants automated workflow, that is a workflow engine, and it can be changed on a Tuesday when the policy changes.

Can you review contracts we already have deployed?

Yes, and it is a sensible engagement whether or not we built them. Review covers the contract logic against adversarial cases, the upgrade and pause arrangements, the key custody, and the off-chain assumptions the code depends on. Findings are ranked by what they cost if exploited.

Why would a company that says no to most of these do this work at all?

Because a small number of cases are real, and those cases need someone who can integrate a ledger with an ERP and operate it afterwards rather than deliver a proof of concept and leave. Being willing to disqualify the rest is what makes the yes worth anything.

Ask thehard question.

Start with a ledger qualification. It is short, it produces a written yes or no with the reasoning, and where the answer is no it comes with the conventional design instead.

Get in touch Book a scoping call