A ledger, where a ledger earns its place
provable
Distributed consensus is the wrong tool for most problems, and we will say so. It earns its place in one narrow case, and in that case nothing else will do.
The test it has to pass
Several independent parties, who do not fully trust one another, need a shared history that none of them can quietly revise. If one organisation owns the record and the others accept it, a database with a good audit trail is cheaper, faster and easier to inherit. We apply that test before proposing a ledger, and most candidates fail it.
The physical bridge decides whether it means anything
An immutable entry only proves somebody typed something. What ties it to the world is the tag: a QR or RFID label on the crate, a scan with a time and a person attached, a weight read off an instrument. Provenance work is mostly this — the physical capture, honestly designed — and the chain is the easy half.
Offline-first, because the field is not a desk
The people entering the most consequential data usually have the least reliable connectivity. Events are recorded locally, signed on the device and queued, reaching the chain when the network allows. A design that assumes a live connection at the moment of capture records nothing on the day it matters.
- Provenance and chain-of-custody tracking
- Smart-contract settlement and escrow
- Tamper-evident audit and document notarisation
- Tokenisation and digital asset infrastructure
- 01A written case for or against a ledger, before any is built
- 02Custody capture that works offline and reconciles when it reconnects
- 03Settlement logic with the dispute path designed, not assumed away
- 04A verification route a counterparty can use without your help
Several parties keep separate records of the same events and disagree
Payment waits on a reconciliation that takes weeks
A buyer or regulator wants origin proved, not asserted
Do we actually need a blockchain?
Probably not, and we would rather tell you that early. The question is whether several parties who do not trust each other must share one history. If a single organisation can own the record, a well-built database is the better system in every dimension that matters.
Which chain do you build on?
It follows from who has to verify, what it must cost per event, and how long the record has to outlive the project. We will not start from a chain and look for a use for it.
What about cost per transaction?
It is a design constraint from the first day, because a per-event cost that is tolerable in a pilot can be ruinous at volume. Batching, anchoring summaries rather than every event, and choosing where settlement actually happens are all part of the answer.
Can it work where connectivity is poor?
That is the normal case in this work. Capture is local and signed, and the chain catches up. See the essay on /insights/designing-for-the-worst-connection.
Start here
Bring us the problem nobody has solved.
A 30-minute technical briefing. We will tell you what we would build, roughly what it costs, and honestly whether we are the right people for it.
- ask@madsoftech.com
- Telephone
- +220 872841578
- Office
- Brusubi, The Gambia