Blockchain & Web3
On-chain where it earns its place: settlement, provenance and ownership. We build the contracts, the integrations and the boring parts that keep them safe.
Who it's for
You are probably here because
-
01
You need a record that several parties can trust without trusting each other.
-
02
You are tracing produce, minerals or pharmaceuticals through several hands.
-
03
You are issuing something: loyalty, carbon, receipts, membership, tickets.
-
04
You have a contract written and want it reviewed before it goes to audit.
What's included
What you actually get.
This page is about record integrity, settlement and provenance. It is not about trading. The most common outcome of our first conversation is a written recommendation to use a database, and we would rather say that early than bill you to find out.
Smart contracts
Solidity and Rust contracts, tokens, escrow, vesting, staking and registries, written to a spec, tested and reviewed before deployment.
Tokenisation and assets
Fungible and non-fungible issuance for loyalty, carbon, agricultural receipts, land and asset records, membership and ticketing.
dApps and wallets
Web and mobile front ends with wallet connection, account abstraction and gasless transactions, so users are not asked to understand chains.
Payments and on/off-ramp
Stablecoin settlement, treasury flows and bridges between on-chain balances and bank rails, with reconciliation.
Supply-chain provenance
Traceability for produce, minerals and pharmaceuticals: batch identity on chain, evidence and documents off chain.
Node and infrastructure
Validator and RPC node operation, indexers, subgraphs and monitoring, hosted with us or on your own hardware alongside the GPU estate.
Integration into existing systems
The common real job: connecting an ERP, POS or core banking system to a chain without rewriting either.
Audit preparation
Internal review, static analysis, test coverage and a threat model prepared before an external audit, so the audit is cheaper.
How it runs
Each stage, and what it produces.
-
01
Fit assessment
An honest read on whether a ledger is needed at all.
Output
A written recommendation, sometimes 'use a database'.
-
02
Design
Token or contract architecture, chain choice, gas and custody model, key management.
Output
A technical specification.
-
03
Build and test
Contracts, front end, integrations and a test suite on a public testnet.
Output
A reviewable deployment you can use.
-
04
Review and deploy
Internal audit, external audit coordination, staged mainnet release.
Output
Verified contracts and deployment records.
-
05
Operate
Monitoring, upgrade governance, incident response, key rotation.
Output
A runbook and an on-call arrangement.
Worth saying
When not to use a blockchain
One organisation controls the data and no one disputes it. Use a database.
The parties already trust each other or an existing intermediary. Use a database.
You need to delete records on request. A public chain and a right to erasure do not sit comfortably together.
The value at stake is smaller than the cost of running and auditing the thing. That is most projects.
List panel
Custody options
- Client-held. You hold the keys. Total control, total responsibility.
- Multisig. Several signers, a threshold to act, no single point of loss.
- Managed. We hold keys under a written agreement with a documented recovery process.
The questions people actually ask first
“Isn't this just crypto speculation?”
The technology and the trading are separate things. Everything on this page is about settlement, provenance and record integrity: making a record several parties can rely on without one of them owning it.
“Is it legal here?”
The technology is. Specific activities, particularly anything touching customer funds or virtual asset services, carry obligations that are moving. We will tell you what we know and where you need your own legal advice, which for anything custodial is always.
“What if the contract has a bug?”
Testing, internal review and an external audit before mainnet. We tell you plainly which parts are upgradeable and which are immutable once deployed, and we write the upgrade governance down before launch.
“Who holds the keys?”
Your choice, documented: client-held, multisig, or managed by us with a written recovery process. We will not take custody informally.
Technology
Proof
One project, in full.
Stock and dispatch system for a regional distributor
Four branches on separate spreadsheets, month-end taking a week.
One day
Month-end close
Four branches tracked stock in separate spreadsheets. Dispatch errors were routine, nobody could see group stock in one place, and month-end close took a week of reconciliation that one person held in their head.
One day
Month-end close
Four
Branches on one system
Single view
Group stock
Commercials
How buying this works.
Engagement
Paid fit assessment, then design, build and audit as separate stages.
Price
On request, after scope
What sets the price
Contract complexity, whether an external audit is in scope, the custody model, and how much of the work is integrating with a system you already run.
Audit is quoted by the auditor, not by us. Our job is to make it shorter.
Every project is quoted after we understand the scope. You will have a written, fixed quote before any build work begins. No open-ended billing.
Questions
Answered plainly.
EVM chains, principally Ethereum, Base and Polygon, and Hyperledger Fabric where a permissioned ledger is the right answer. We would rather name three we stand behind than eight we do not.
Often. The fit assessment exists to produce that answer early, in writing, before anyone has spent build money.
That is usually the actual job. The contract is the small part; the integration and reconciliation are where the work is.
We prepare for it and coordinate it. The audit itself is done by an independent firm, which is the entire point of it.
Often bought alongside
Build
Book a fit assessment
We will tell you in writing whether a ledger earns its place here, and we are content if the answer is no.
We reply to every enquiry within one working day.