The real question: who has to trust whom
Supply chain projects usually start with a goal that sounds technical: trace a lot from the farm or the mill to the shelf, prove a certificate is genuine, show a regulator or a customer where something came from. The technology choice follows from a simpler question. Who keeps the record, and do the other parties have to take their word for it?
If one company keeps the record and its suppliers and customers are content to trust it, a shared database with good access control and an audit log is enough. If several companies each need to write to the record, and none of them should be able to rewrite history without the others noticing, a ledger shared between them starts to make sense. If the record has to be checkable by anyone, including people with no account and no relationship with you, a public chain is the tool.
| Situation | Usually the right tool |
|---|---|
| One company owns the process; partners read and upload | A shared database with roles and an audit log |
| Several companies write; none should be able to edit alone | A private, permissioned chain with a node per party |
| Anyone, anywhere, should be able to verify a claim | A public chain, holding proofs rather than data |
| You want the word blockchain in a press release | None of the above. Start with the problem |
When a shared database is the honest answer
We build blockchains, and we still recommend a database more often than a chain. A database is faster, cheaper to run, easier to change and familiar to every developer you will ever hire. Access control decides who sees what. An append-only audit log, written by the database itself, shows every change and who made it. Daily backups held by a third party add another witness.
- Choose a database when one organisation is accountable for the record and the others accept that.
- Choose a database when the hard part is getting suppliers to upload anything at all. A ledger does not fix a missing certificate.
- Choose a database when your partners will not run software of their own. A chain where you run every node is a database with extra steps.
- Choose a database when the data changes shape often. Schemas on a database are easy to migrate; data on a ledger is meant to stay as it was written.
Whatever you choose, use a shared vocabulary. GS1's EPCIS standard exists so that different applications can create and share visibility event data within and across companies [5]. Recording events in that shape makes it far easier to connect to partners, auditors and retailers later, on a database or a chain.
Private, permissioned chains
A private chain is a ledger run by a known group. Each member runs a node; a transaction is only recorded when the network agrees on it, and no single member can rewrite the past without the others seeing. Hyperledger Fabric describes this model as one for known, identified participants under a governance model, and notes that its consensus does not need a native cryptocurrency [1]. Fabric also lets members form channels and private data collections, so that a set of transactions is visible only to the parties involved [1].
Besu, an Ethereum client used for private networks, offers node and account permissioning, so that only specified nodes and accounts can access the network [2]. Building on Ethereum tooling has a practical benefit: the smart contracts, wallets and developers are the same ones the public ecosystem uses.
- Right when: several companies write to the record, they each want a copy they control, and they agree on who may join.
- Watch for: governance. Who admits a new member, who upgrades the contracts, and what happens when a member leaves are business questions that need answers before launch.
- Plan for: each party running a node, or paying someone to run it for them. A network is only as independent as its operators.
Public chains
A public chain such as Ethereum can be read and verified by anyone. That is its strength and, for supply chains, its main limit. ethereum.org itself describes Ethereum as a public and transparent ledger by design [4]. Prices, volumes, supplier names and anything else you write there can be read by competitors as easily as by customers.
Writing to a public chain also costs a fee. On Ethereum, the sender of a transaction pays gas, and when demand on the network is high, the fee needed to get a transaction included rises with it [3]. That makes the cost of a public chain depend on other people's activity, which is awkward for a business that records thousands of events a day.
The common answer is to keep the data off the public chain and anchor proofs to it. The portal stores the records in its own database or private ledger, and at intervals writes a single fingerprint (a hash) of a batch of them to a public chain. Anyone given a record can later check that it matches the fingerprint and was not altered since, without anyone publishing the record itself.
- Right when: the audience is the public or customers you have no contract with, and the claim must be verifiable without trusting you.
- Watch for: fees that move with the network, and anything sensitive that would be readable forever.
- Plan for: wallets and keys. Whoever holds the key that writes the anchors holds the authority to write them.
What goes on the chain, and what stays off it
Whatever kind of chain you use, put as little on it as you can. Documents, images and certificates belong in ordinary storage; the chain holds their fingerprints and the events that reference them. That keeps the ledger small and fast, and it keeps sensitive files under access control.
Personal information needs particular care. Canada's private sector privacy law, PIPEDA, rests on fair information principles that include accuracy and individual access, under which people can challenge the accuracy and completeness of their information and have it amended as appropriate [6]. A record that can never be changed sits awkwardly with that. Keep names, addresses and anything else about individuals off the chain, and involve your own advisers early on what your records must allow.
Living with the choice after launch
The build is the visible part. The years after it are where the choices differ most, so think about them before you commit.
- A shared database is maintained like any business system: updates, backups, access reviews and the occasional schema change. Any competent team can take it over.
- A private chain is a small network of independent operators. Each node needs updates in step with the others, members need onboarding and offboarding, and contract upgrades need every party's agreement. Someone has to coordinate that, and it is worth naming who in the governance rules.
- Public-chain anchoring is light to run, but its keys are critical. Store them in a hardware module or a managed key service, keep a written recovery plan, and watch the fees so a busy week on the network does not surprise you.
- On every route, the integrations with suppliers' and customers' systems need the most care over time, because those systems change without asking you.
The same traceability portal, three ways
The three worked examples below are one product: a portal where suppliers upload lot data and certificates in English and French, staff trace a finished batch back to its inputs, and alerts go out when a certificate is missing. Only the record underneath changes. Each shows the range from our rate card today, with the build and the monthly running cost.
Worked example, priced now
On a shared database
The portal on a managed database with roles, an audit log and integrations to the partners' systems. The baseline the other two are measured against.
- Build
- ≈ US$59,800 to US$91,500, delivered within 16 weeksCAD 85,200 to 130,300
Prices in your currency are estimates from today's Bank of Canada rate. All invoicing is in CAD or USD.
Running it
- Hosting
- ≈ US$176 a monthCAD 250 a month
- Support
- ≈ US$2,500 a monthCAD 3,565 a month
Worked example, priced now
On a private permissioned chain
The same portal with each lot and certificate recorded on a private chain, with a node per party, on a larger hosting setup.
- Build
- ≈ US$104,000 to US$160,000, delivered within 22 weeksCAD 148,700 to 227,500
Prices in your currency are estimates from today's Bank of Canada rate. All invoicing is in CAD or USD.
Running it
- Hosting
- ≈ US$492 a monthCAD 700 a month
- Support
- ≈ US$2,500 a monthCAD 3,565 a month
Worked example, priced now
With proofs anchored to a public chain
The same portal on its own database, with smart contracts that anchor a fingerprint of each batch of records to a public chain so anyone can verify them.
- Build
- ≈ US$77,700 to US$119,000, delivered within 23 weeksCAD 110,700 to 169,200
Prices in your currency are estimates from today's Bank of Canada rate. All invoicing is in CAD or USD.
Running it
- Hosting
- ≈ US$176 a monthCAD 250 a month
- Support
- ≈ US$2,500 a monthCAD 3,565 a month
The difference between the first example and the other two is the price of the extra assurance each chain adds. If nobody in your supply chain needs that independent proof, the first example is the one to build.
Questions to answer before you choose
- 01
Who writes to the record?
One organisation, several, or anyone. This alone settles most projects.
- 02
Who must be able to check it, and do they trust you?
Partners under contract can be given access. The public cannot, which is when a public chain earns its place.
- 03
Will your partners run a node?
If not, a private chain is run by you alone, and its independence is on paper only.
- 04
What is sensitive?
Prices, volumes, supplier identities and personal information should not be on any ledger others can read.
- 05
How will data get in?
Integrations with ERPs, scanners and sensors usually take more effort than the ledger. Price them first.
- 06
Who governs the network?
Joining, leaving, upgrades and disputes need written rules agreed by every member before launch.
If the answers point to a database, we will say so and build that. If they point to a chain, we build private networks and public-chain contracts, and every contract that holds value goes through review and, where it warrants one, an external audit.