A DeFi protocol is a risk engine with contracts attached.
The contract decides what a position is. What decides whether the protocol is still solvent after a bad hour is the layer above it — the prices it agreed to believe, the collateral maths it runs between blocks, and whether a write reaches a vault at all once either of those is in doubt.
Why DeFi protocols fail on the day the price moves.
The contract usually does what it was written to do. What fails is the risk layer around it — the price it believed, the health number it computed a block ago, and the write it admitted while both were already wrong.
Liquidation risk is discovered after the price move, not before it
A screen reporting current health answers the question nobody needed answered. The useful number is conditional: under a stated move, which positions breach, what the projected health factor is, and how much collateral has to be posted. That is a simulation run before capital is committed, not a reconstruction afterwards.
A health factor computed on page load is already out of date
Collateral maths that runs when someone opens a page is a report, not a control. The risk engine evaluates continuously off the event stream and pushes derived risk to whatever is subscribed, which keeps the model in one place and fires an alert on the event rather than on the next refresh.
Oracle failure is a solvency event, not a UI bug
The maths does not stop when a feed does, which is what makes a stale price worse than a missing one. Deviation against a multi-source median and a staleness threshold are checked before a price is admitted to the risk model; on breach the model holds last-known-good and new leverage is blocked, and the interface says held rather than showing a figure that looks live.
Position state is spread across venues and never agrees at a single instant
Reading each venue live produces a portfolio that was not true at any one block. State is reconstructed from indexed events instead, and every figure carries the block height it was derived from, so a number that is behind is visibly behind rather than quietly wrong.
Haircuts and concentration caps are buried in application code
Nobody accountable for a limit can review a conditional inside a service. Per-asset haircuts, concentration caps and LTV ceilings belong in declarative configuration with versioned history, so changing one is a diff somebody approves and the limit in force last quarter is still readable.
A retried borrow under congestion opens the position twice
Signing and walking away cannot distinguish a dropped transaction from a slow one, and on a credit protocol the duplicate is exposure rather than a cosmetic defect. Mutations are keyed and idempotent, tracked through a state machine with explicit replacement and cancellation paths.
How we build one.
The ordering is the argument. Risk sits between the API and the protocol layer deliberately, so no write path reaches a contract without passing a policy check first.
- 01
Smart contracts
Vaults, collateral accounting, liquidation hooks and role-gated admin paths, with the accounting stated as invariants and fuzzed rather than walked down one scripted path.
- Solidity
- Foundry
- OpenZeppelin
- 02
Risk engine
Continuous health-factor evaluation off the event stream, with a per-asset haircut matrix, concentration limits and price-shock simulation run before a position is opened.
- Rust
- Event stream
- Cross-margin
- 03
Protocol layer
Venue adapters normalising lending markets and pools into one position abstraction, so adding a market is an adapter rather than a change to how the system reasons about exposure.
- Adapter pattern
- TypeScript
- Simulation
- 04
Blockchain
EVM execution with indexed event streams feeding state reconstruction, and price feeds admitted to the model only after deviation and staleness checks.
- EVM
- Event indexing
- Oracle safety
- 05
API gateway
Auth, rate limiting, request signing and idempotency keys on every mutation, so a retry in a congested mempool produces one position rather than two.
- Node.js
- Idempotency
- JWT
- 06
Frontend
Position and risk surfaces subscribed to derived risk instead of raw chain data, with pre-trade simulation on the same screen as the position being sized.
- Next.js
- React
- WebSocket
We have already built this.
APEX is our institutional DeFi platform: cross-margin collateral baskets with per-asset haircuts, a risk engine evaluating health factors continuously off the event stream, shock simulation that names which positions breach under a stated move, oracle deviation and staleness checks that hold last-known-good and block new leverage, declarative limits with versioned history, and yield attributed to base rate, fees and emissions separately. It is a MaatX demonstration rather than a client deployment, and every mechanism above is running in it.
Questions we get asked.
Do you design the mechanism, or only implement one?
Both, and the first is the part that is expensive to get wrong. Rate curves, haircuts, liquidation incentives and the conditions under which the protocol is allowed to keep operating are economic decisions before they are code, so they get specified as invariants and stress-tested before anything is written. Lending markets, collateral systems, pool liquidity and the margin logic behind a derivative reduce to the same three questions: what the price is, what the collateral is worth after a haircut, and when a position has to be closed.
Can you fork an existing protocol instead of writing one?
Sometimes that is the right call and we will say so. What a fork saves you is the contract, which is one layer of the system. It also inherits a mechanism tuned for someone else's liquidity and collateral set, so the oracle policy, the haircuts and the liquidation path still have to be decided for yours — and that is where the work was in the first place.
What happens when a price feed goes stale?
The risk model holds at last-known-good and new leverage is blocked. That is a deliberate choice to degrade rather than act on a price nobody traded at. Deviation against a multi-source median and a staleness threshold are evaluated before a price is admitted, and figures derived from a held feed are labelled as held, because a number that looks current and is not is the dangerous state.
What does an engagement look like?
Usually Mechanism and Architecture first — one to three weeks to settle the invariants, the collateral and liquidation model and the oracle policy, ending in an architecture you could hand to any competent team. A build follows from there if you want us to do it, scoped per system.
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
Full System Build
Typically $25,000–120,000
Scoped per system
The contract is one layer. 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.