Engineering
A shared ledger, only
when a database will not do
We decline more blockchain work than we accept, because most requirements are met by a Postgres table and a signed audit log. When several organisations that do not trust one another must agree on one record, we build the network, the contracts and the integration around them.
Overview
Permissioned ledgers, tokenised assets and independently audited smart contracts.
The test is simple. If one organisation controls the data and everyone else is content to read it, you want a database. If four counterparties, two regulators and a warehouse operator all need to write to the same record, and none of them will accept another party's copy as authoritative, a permissioned ledger starts to earn its complexity.
Most of the delivery effort is not chain code. It is key custody, identity, the API layer that hides block confirmation from the business system, and the reconciliation job proving on-chain state matches the ERP. Contracts are perhaps 8 per cent of the work and close to all of the risk, which is why every one we ship is fuzzed in Foundry, analysed with Slither and externally audited.
We build on Hyperledger Fabric and Hyperledger Besu for consortium networks, and on Ethereum or Polygon PoS where public settlement or existing liquidity matters. Upgrade paths, key rotation and a plan for winding the network down are designed at the start, not improvised on the day a member gives notice.
- 1.9 s
- Median transaction finality on the Besu IBFT network for Northwind Commodities
- 0 critical, 3 medium
- External audit findings on Vantara Metals' tokenised warrant contracts
- 14,200 lots
- Consignments with chain-anchored provenance in the first quarter, Pilbara Freight
Capabilities
What this covers
Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.
Feasibility and architecture review
A two to three week assessment ending in a written recommendation that includes the case against using a ledger. Several of ours have concluded with use Postgres and sign the exports.
Consortium network design
Channel and organisation topology on Hyperledger Fabric or Besu IBFT, with membership rules, endorsement policies, node hosting split across members, and the governance agreement that has to sit behind it.
Smart contract engineering
Solidity or Go chaincode built on OpenZeppelin primitives, driven by Foundry invariant tests and fuzzing, statically analysed with Slither, then reviewed by an independent audit firm before any value moves.
Asset tokenisation
On-chain representation of commodity lots, invoices or carbon units, together with the off-chain custody, transfer restrictions and redemption mechanics that make the token mean something legally.
Supply-chain traceability
Chain-anchored provenance for batches and consignments, with device or document attestation at each custody hop and IPFS storage for the payloads that have no business sitting on-chain.
Integration and key custody
HSM or KMS-backed signing, role separation between proposer and approver, and a gateway giving your SAP or Oracle systems ordinary REST semantics instead of asking them to understand finality.
Deliverables
What you get
- Feasibility report with a build or do-not-build recommendation and a cost model
- Network topology and governance model, including node hosting and membership rules
- Audited smart contracts or chaincode with test suite, fuzz corpus and coverage report
- Integration API that hides confirmation, reorg and retry behaviour from business systems
- Key management design covering custody, rotation, recovery and revocation
- Runbooks for node operations, contract upgrades and network wind-down
Stack
What we build it with
- Hyperledger Fabric
- Hyperledger Besu
- Solidity
- Foundry
- Hardhat
- OpenZeppelin Contracts
- ethers.js
- Slither
- Chainlink
- Polygon PoS
- IPFS
- The Graph
Process
How the engagement runs
Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.
Prove the need
We model the same requirement as a conventional system first. If the database version wins on cost and operational risk, we say so and the engagement stops at that point.
Design the network
Topology, consensus, membership and governance agreed with every participating organisation, because a consortium that cannot agree on rules will not agree on blocks either.
Build and test
Contracts developed in Foundry with invariants stated as properties, and a testnet running with all members joined before any production signing key is generated.
Audit and harden
Static analysis, internal review and an independent external audit. Findings are fixed and re-reviewed; anything left open carries a named owner and a written accepted risk.
Operate
Production launch with monitoring on block time, endorsement failures, key usage and reconciliation drift against the systems of record, plus runbooks for node upgrades.
When this is the wrong engagement
If a single organisation owns the data and the real requirement is tamper-evidence, an append-only Postgres table with signed hashes gives you the same audit property at a fraction of the running cost.
FAQ
Questions we get asked
- How do you decide whether we need a blockchain at all?
Three questions. Do multiple organisations write to the same record; do they lack a mutually trusted operator; must the history be provable to an outside party. Two clear yeses usually means a database with signed exports. Three means a permissioned ledger is worth costing.
- Public chain or permissioned network?
Permissioned, unless you need public settlement, existing liquidity or a genuine bearer asset. Fabric and Besu give known validators, predictable cost and privacy between participants. A public chain buys censorship resistance you rarely need and fee volatility you cannot budget for.
- Who audits the contracts?
We run Slither and Foundry invariant tests on every commit, and we commission an independent audit firm before a contract holds value. We do not audit our own code and present that as assurance, and the external report reaches you unedited, findings and all.
- What happens if the consortium breaks up?
The wind-down is part of the design. Every member holds a full node and can take a signed export of the state relevant to them, and the contracts carry a documented terminal state, so leaving the network costs a migration rather than the record itself.
Related
More in Engineering
Engineering
IoT Development
Firmware, connectivity and telemetry pipelines for devices you cannot easily reach.
Engineering
Legacy Modernisation
COBOL, Delphi, WebForms and Oracle Forms moved off, without a big-bang cutover.
Engineering
Enterprise Integration
Contracts, idempotency and replay — the unglamorous parts that keep 40 systems in step.