Blockchain
Blockchain development, built for the systems you already run.
Public chains, permissioned networks, smart contracts, and the integration work that connects any of them to identity, payments and the records a company already keeps. We design that boundary first and pick the chain to fit it.
Scope
What the work covers.
Most engagements touch several of these. Very few need all of them, and we will say which ones yours does not.
Network design
Choosing between a public chain, a permissioned network and no chain at all. Then the consensus model, the data model, the node topology, and who is able to run a node once it is live.
Smart contracts
Specified behaviour before implementation, property and invariant tests, explicit upgrade and pause paths, gas characteristics understood rather than discovered, and a codebase laid out so an external auditor can work through it without a tour.
Web3 engineering
Wallet connection and signing flows, RPC and indexing infrastructure you control rather than rent from a single provider, event pipelines, and the reconciliation layer that keeps an application correct when a chain reorganises underneath it.
Decentralised applications
The interface engineered with the same care as the contract behind it, including the states most projects leave undesigned: pending, replaced, reverted, underpriced, and the wallet that disappeared mid-transaction.
Permissioned networks
Membership, governance, key custody and access designed at the start. Consortium rules are an organisational problem before they are a technical one, and they do not survive being bolted onto a public-chain pattern.
Integration
The seam between the chain and everything else: identity, payments, ERP records, reporting, and the exception paths for when one of those is unavailable and a transaction has already settled.
Selection
How a chain gets chosen.
The question is rarely which chain is best. It is which properties the process actually requires, and whether a ledger is the cheapest way to get them. We work through five questions before recommending anything, and the answer to the first one is sometimes that you do not need this.
Who is allowed to write
If every party that submits data is known and contracted, a permissioned network is usually simpler and cheaper to operate. If they are not, that changes almost every decision downstream.
What has to be provable, and to whom
A regulator, a counterparty and the public need different things. Proving something to a party who already trusts your database is not worth a distributed ledger.
Where the data actually lives
On-chain storage is expensive and permanent. Most designs end up with hashes on chain and payloads elsewhere, which moves the hard problem to availability and retention rather than removing it.
What finality has to mean
Protocol finality and business finality are different deadlines. A process that releases goods on confirmation needs an answer about reorganisation depth before the architecture is fixed, not after.
Who operates it in year two
Nodes, keys, upgrades, gas funding and monitoring all outlive the build. If nobody has been named for that, the design should be simpler than the one you were about to approve.
The seam
Where blockchain projects usually go wrong.
The contract is rarely what delays delivery. The delay comes from the boundary, where a system that cannot be rolled back meets systems that expect to be. These are the joins we design before anything is written.
Identity
Mapping people and organisations in your directory to keys and addresses on the network, and deciding what happens when someone leaves.
Payments and settlement
Connecting an on-chain event to a real movement of money, in both directions, with a reconciliation that a finance team can audit.
Records of account
ERP and internal systems stay the record of account for most of the business. The chain is one input among several, and the write order between them has to be decided rather than assumed.
Off-chain data
Anything a contract needs to know about the outside world arrives through something that can be wrong, late or absent. That path gets a design, a fallback and a cost.
Reporting
Indexed, queryable history that answers the questions the business asks, rather than a block explorer link handed to someone in operations.
Failure paths
A settled transaction against a downstream system that was offline is the case that defines the architecture. It is designed first, not discovered in production.
Security
Written to be audited.
A deployed contract is public, permanent and holds value, which makes it the least forgiving code most teams will ever ship. We build it to be reviewed by people who did not write it.
Threat modelling at design time
Who benefits from breaking this, what they can reach, and what they would have to hold to do it. Answered before implementation, not during review.
Key custody
Where the keys live, who can use them, what needs more than one signature, and how any of it is rotated without a redeployment.
Upgrade and governance
Whether the contract can change at all, who decides, over what delay, and what a holder can do in the window between the decision and the change.
Audit preparation
Specification, test coverage, invariants and documentation assembled so an external audit spends its time on logic rather than on orientation. We prepare for that audit; we do not mark our own work.
Monitoring after launch
Alerting on the conditions that matter, from balance drift to a pause that nobody expected, with someone named to answer it.
Delivery
How a project runs.
Five phases. The first one can end the project, and occasionally should.
Feasibility
The five questions above, answered in writing, with a recommendation that includes the option of not building this. You keep the document either way.
Architecture
Chain, data model, key custody, the integration boundary and the failure paths. Costs and risks recorded alongside the recommendation, and any dissenting view recorded with them.
Build
Contracts and integration developed together rather than in sequence, because the boundary is where the surprises are and finding them late is what moves a launch date.
Review
Internal review, then the preparation and support for an external audit. Findings are fixed and re-tested before launch rather than logged for later.
Operate
Nodes, monitoring, key rotation, gas funding and the runbook. We stay on it, which is the part that stops a system becoming somebody else s problem in year two.
Questions
The ones worth asking first.
Do we actually need a blockchain?
Often not. If every party involved already trusts one organisation to keep the record, a database is cheaper, faster and easier to change. A ledger earns its cost when parties who do not trust each other have to agree on the same history, or when you have to prove something to someone outside the arrangement. Feasibility is the first phase precisely so this gets answered before the budget is committed.
Public chain or permissioned network?
It follows from who is allowed to write and what has to be provable. A network whose participants are all known and contracted rarely needs the cost or the exposure of a public chain. One that has to convince an outside party often does. The decision also sets who operates nodes, which is the part that tends to be decided last and should be decided early.
Do you audit the contracts you write?
No, and you should be wary of anyone who says otherwise. We build the codebase so an independent auditor can work through it, we run internal review, we prepare the specification and test suite an audit needs, and we fix and re-test what the audit finds. Marking our own work would not tell you anything.
What happens when the chain reorganises?
Any system that acts on a confirmation has to decide how deep a confirmation must be before it is treated as final, and what to do if that assumption breaks. We set that depth against the business process rather than the protocol default, and build the reconciliation that repairs downstream state if a reorganisation goes past it.
Can it connect to our ERP?
That is usually the substance of the project rather than an afterthought to it. The chain becomes one input among several, and the work is in the write order, the reconciliation and the behaviour when one side is unavailable while the other has already settled.
Who runs it after launch?
We do, if you want that. Nodes, monitoring, key rotation, gas funding and upgrades are ongoing work, and a system handed over at go-live tends to be legacy within about two years. Knowing we will be operating it changes how we build it.
Tell us what you are trying to build.
Describe the process and who has to agree on it. If a ledger is the wrong tool we will say so on the call, and that costs you nothing.
info@eorbitt.com · We reply within one business day.