Smart contracts that survive contact with production.
Writing the contract is the part everyone estimates. What decides whether the system holds is the layers around it — the indexing that reads the chain, the path that writes to it, and the risk model that says whether a write is safe at all.
Why on-chain systems fail after the audit.
An audit checks the contract. Most of what goes wrong afterwards is not a contract bug — it happens in the layer that reads the chain, the path that writes to it, or the policy that decided a write was acceptable.
A retried transaction submits the same action twice
Fire-and-forget signing cannot tell a dropped transaction from a slow one. Mutations need an idempotency key and an explicit state machine with replacement and cancellation paths, so a congested mempool produces one effect rather than two.
A reorg corrupts indexed balances and nothing notices
An indexer that writes as it reads will happily persist orphaned state. Writing against a confirmed cursor with deterministic rollback makes a reorg a handled event with a known affected range instead of silent data loss.
Oracle failure becomes a solvency event
A feed that goes stale mid-move is worse than one that goes down, because the maths still runs. Deviation and staleness are checked before a price enters the risk model; on breach the engine holds last-known-good and blocks new exposure rather than computing on bad input.
The balance a user sees was read from the chain at display time
Chain state is an input, not an answer. A double-entry ledger with enforced invariants is the authority, and every figure carries the block height it was derived from so a stale number is visibly stale.
Risk policy is buried in application code
Collateral haircuts, concentration caps and LTV ceilings expressed as code are unreviewable by the people accountable for them. Declarative, versioned configuration makes a limit change a diff someone can approve.
The admin key is the real attack surface
Most losses are not clever exploits of contract logic. Privileged paths need role gating, timelocks on parameter changes and an upgrade story decided before deployment rather than improvised during an incident.
How we build one.
The contract is one layer of eight. We design the other seven first, because those are the expensive ones to retrofit once value is sitting in the system.
- 01
Contracts
Role-gated admin paths, collateral accounting and liquidation hooks, written to be upgrade-aware rather than upgraded in a hurry.
- Solidity
- Foundry
- Slither
- 02
Property testing
Invariants stated as properties and fuzzed, so the question is whether the accounting can ever break rather than whether one scripted path passes.
- Invariants
- Property tests
- 03
Indexing
Reorg-safe cursors with deterministic rollback, feeding state reconstruction rather than reading each protocol live.
- Reorg-safe cursors
- Event log
- 04
Risk engine
Continuous evaluation off the event stream with haircuts, concentration limits and shock simulation, sitting between the API and any write path.
- Policy as config
- Shock simulation
- 05
Submission path
Idempotent, keyed mutations tracked through a state machine with explicit replacement and cancellation, instead of signing and hoping.
- Idempotency keys
- Replacement paths
- 06
Reconciliation
An authoritative double-entry ledger with breaks raised as exceptions, so a disagreement between chain and ledger stops the line rather than accumulating.
- Double-entry
- Exception queue
We have already built this.
APEX is our institutional digital-asset platform: role-gated vaults and collateral accounting, a risk engine evaluating continuously off the event stream, oracle deviation and staleness checks that block new leverage on breach, and idempotent submission tracked through an explicit state machine. It is a MaatX demonstration rather than a client deployment, and every mechanism above is running in it.
Questions we get asked.
Do you audit smart contracts?
No, and we would push back on anyone who offers to build and audit the same code. We write property tests and run static analysis as part of building, which catches a great deal early — but an independent audit is a separate engagement and belongs with a firm that has no stake in the implementation. We work alongside auditors and fix what they find.
Which chains do you work on?
EVM chains including Ethereum and the major L2s, and Solana. The choice is usually driven by where your liquidity or your users already are, and by the cost profile of the transaction you expect to be most frequent — which is worth modelling before the contract is written rather than after.
How do you handle upgrades to a deployed contract?
Where we can, by keeping the thing that changes out of the contract. Eligibility, limits and policy live in a registry or in configuration the contract reads, so a rule change takes effect without a redeployment. Where an upgrade path is genuinely needed we decide the pattern and its governance before launch, not during an incident.
What does an engagement look like?
Usually Discovery and Architecture first — one to three weeks to settle the layer boundaries, the risk model and the failure behaviour, ending in an architecture you could hand to any competent team. Build follows if you want us to do it.
What it costs, and what you are agreeing to.
The commercial answers in one place, so none of them has to wait for a call.
Typical route in
Blockchain Engineering
Typically $25,000–120,000
Scoped per system
The contract is one layer of eight. Most of what decides whether an on-chain system survives production lives in the indexing, the risk model and the reconciliation.
A starting point for the scope described, not an estimate for your project. Ongoing engineering runs at $75 per hour blended.
Who owns what you build?
You do. On full payment of the fees for an engagement, the intellectual property in everything built specifically for you is assigned to you.
Our pre-existing tools, libraries and internal infrastructure stay ours — but where a deliverable uses them, you get a perpetual, worldwide licence to run, modify and extend it. Nothing we hand over needs us to keep operating it. Open-source and third-party components keep their own licences, and we tell you which ones and what they require.
We also will not name you as a client, describe your project, or publish a case study about it without your written agreement.
What happens if it does not work out?
Either of us can end an engagement with 30 days written notice, or immediately if the other commits a material breach and does not remedy it within 15 days. You pay for work properly performed up to that point, and we hand over completed work along with every deliverable you have paid for.
Two limits worth stating before you ask. We are engineers, not advisers: nothing we deliver is legal, regulatory, tax or financial advice, and a system built to your specification is not an opinion that it is lawful in your jurisdiction. And where our work includes reviewing or auditing code, the findings cover the scope and time agreed — an absence of findings is not a guarantee that nothing is there.
What do you need from me to start?
Not a specification. Discovery exists precisely because most people do not have one — an idea, or a technical problem you cannot yet size, is enough to begin.
What the work does assume: timely access to the people, systems, credentials and environments it touches; decisions and approvals at roughly the pace the timeline assumes, since delays on your side move both dates and cost; and that you have the right to give us whatever you give us, including data, code and third-party material.
Why you rather than the alternative?
Against hiring a senior engineer in-house: sourcing one takes months and commits you permanently. Discovery runs 1–3 weeks, and you keep the architecture whichever way you then go — including if the answer is to make that hire.
Against the cheapest contractor available: you will pay less per hour. Our argument is that the architecture decision is the one that is expensive to reverse, which is why we sell it first, separately, and at a price you can say yes to before committing to a build.
Against a larger firm: there is no account layer. The people who scope the work are the people who build it.
And when not to hire us: if a no-code or off-the-shelf tool still fits what you are doing, stay on it. We are worth paying once you have hit a ceiling you cannot engineer around from where you are.
These are summaries. The binding version of the ownership, exit and liability terms is in our Terms of Service. A person reads every enquiry. We usually reply within a few hours.
Start a technical assessment
Building lending, collateral or liquidity where a desk has to see its risk before it commits capital?
Send us the architecture or the problem. We will come back with the technical risks we can see and a sensible path forward, free, and tell you if we are not the right people for it.