APEX
Institutional DeFi Platform
Programmable financial infrastructure for digital assets.
Run on-chain credit and liquidity positions with the risk visibility a desk expects before it commits capital.
- Solidity
- Risk engine
- Oracle safety
- Cross-margin
- Event indexing
A lending, liquidity and collateral platform built for desks that need position-level risk visibility before they need yield.
What the product is built around.
APEX treats a DeFi position the way a prime broker treats a margin account: one account view, one health number, one audit trail. The protocol layer is abstracted so a desk reasons about exposure and collateral rather than about which pool a position happens to live in.
Risk before yield
Health factor, liquidation distance and correlated-collateral exposure are first-class, computed continuously rather than polled on page load.
Protocol as a detail
A single position abstraction spans lending markets, so adding a venue does not change how the desk works.
Explainable returns
Every basis point of yield is attributed to a source — base rate, incentive emissions or fee share — so returns can be underwritten.
What makes this hard.
Institutional desks want the capital efficiency of on-chain credit markets without giving up the controls they already run off-chain. The tooling forces a choice: retail-grade interfaces with no risk surface, or custodial products with none of the programmability.
- 01
Collateral health is spread across a dozen protocol UIs with no consolidated view
- 02
Liquidation risk is discovered after the price move, not before it
- 03
Yield strategies are opaque — desks cannot see where the return is actually coming from
- 04
Treasury, risk and trading teams work from different numbers on the same positions
- 05
Position sizing decisions need pre-trade impact simulation that no dashboard provides
What the system does.
APEX consolidates positions across lending venues into one account view with a single health number. A risk engine evaluates collateral continuously off an event stream rather than on page load, simulates price shocks before a trade, and blocks new leverage when a price feed goes stale. Yield is attributed to its source so a return can be underwritten rather than hoped for.
One position view across venues, chains and asset classes
Continuous health-factor evaluation with liquidation projection
Pre-trade shock simulation before capital is committed
Declarative risk limits that a reviewer can diff
Yield attributed to base rate, fees and incentives separately
APEX, as working interface.
Rendered UI, not a mockup. Switch between screens, and try ⌘K for the command palette.
Consolidated exposure across venues, with allocation and yield attribution.
Total portfolio
$48.24M
Collateral posted
$31.60M
Borrowed
$12.84M
Net APY
7.42%
Portfolio value
90DCollateral composition
- ETH & LSTs44.9%
- Stablecoins29.7%
- wBTC16.1%
- Alt L2 assets9.2%
Yield attribution
bpsOpen positions
| Market | Venue | Side | Size | Rate | Health | 7D | Status |
|---|---|---|---|---|---|---|---|
| ETH / USDCCross-margin | Ethereum | Supply | $9.84M | 4.18% | 2.41 | Active | |
| wBTC / USDTIsolated | Arbitrum | Borrow | $6.12M | 6.94% | 1.62 | Monitor | |
| stETH / ETHCross-margin | Ethereum | Supply | $7.45M | 3.26% | 3.08 | Active | |
| USDC / DAIStable pool | Base | Liquidity | $4.90M | 5.71% | — | Active | |
| ARB / USDCIsolated | Arbitrum | Borrow | $2.34M | 9.12% | 1.28 | Action req. | |
| rETH / ETHCross-margin | Ethereum | Supply | $3.18M | 3.94% | 2.87 | Active |
6 of 12 positions shown · collateral haircuts applied per asset · values shown for illustration
Health factor
Liquidation at 1.00- Critical≤ 110
- At risk≤ 150
- Healthy≤ 220
- Over-collateralised≤ 300
Risk limits
policy- Portfolio LTV40.6% / 65%
- Single-asset conc.29.4% / 40%
- Venue conc. (Arbitrum)18.2% / 35%
- Illiquid collateral9.1% / 11%
Liquidation projection
- Scenario
- ETH −25%, BTC −20%
- Positions at risk
- 3 of 12
- Projected health
- 1.11
- Collateral to post
- $4.28M
- Est. liquidation penalty
- $312,400
- Time to breach
- ~ price-dependent
- Recommended action
- Reduce ARB borrow 40%
Risk & position activity
- Health alert — ARB / USDC09:42:18
Health factor crossed 1.30 · auto-deleverage proposal queued for approval
- Collateral rebalanced09:12:04
+1,240 stETH moved from isolated to cross-margin basket
- Rate change — wBTC / USDT08:47:51
Borrow APR 6.41% → 6.94% on utilisation 84.2%
- Yield harvested07:30:00
$18,402 in pool fees claimed and routed to treasury address
- Oracle heartbeat06:15:22
All 14 price feeds within deviation threshold · staleness 0
Interface states
UI statesNo positions yet
Connect a treasury address or open a market position to begin.
Open positionEmpty statePrice feed unavailable
Two oracle feeds exceeded the staleness threshold. Risk figures are held at last-known-good.
How it is put together.
Risk sits between the API and the protocol layer deliberately — no write path reaches a contract without passing a policy check first.
- 01
Frontend
Position and risk surfaces, streamed updates, pre-trade simulation UI.
- Next.js
- React
- TypeScript
- WebSocket
- 02
API Gateway
Auth, rate limiting, request signing and idempotency keys on every mutation.
- Node.js
- REST
- JWT
- Idempotency
- 03
Risk Engine
Continuous health-factor evaluation, haircut model, concentration limits and shock simulation.
- Rust
- Redis
- Event stream
- 04
Protocol Layer
Venue adapters normalising lending markets into one position abstraction.
- Adapter pattern
- TypeScript
- Simulation
- 05
Smart Contracts
Vaults, collateral accounting, liquidation hooks and role-gated admin paths.
- Solidity
- Foundry
- OpenZeppelin
- 06
Blockchain
EVM execution with indexed event streams feeding state reconstruction.
- EVM
- Indexer
- Oracles
What the product does.
The capability set the demonstration is built around.
Liquidity pools
Provision and monitor pool positions with depth, utilisation and fee-share attribution.
Lending & borrowing
Supply and borrow across markets with unified rate discovery and term comparison.
Collateral management
Cross-margin collateral baskets with per-asset haircuts and concentration limits.
Yield strategies
Composable strategy templates with modelled drawdown and attribution breakdown.
Risk monitoring
Continuous health-factor evaluation with threshold alerting and liquidation projection.
Portfolio management
Consolidated exposure across venues, chains and asset classes in one account view.
Challenges, and the MaatX approach.
The problems that actually decide whether a system like this survives production — and how we address each one.
Position state is spread across venues and never agrees at a single instant
State is reconstructed from indexed events rather than read live from each protocol. Every figure carries the block height it was derived from, so a stale number is visibly stale instead of silently wrong.
A health factor computed on page load is already out of date
The risk engine evaluates continuously off the event stream and pushes changes. The UI subscribes to derived risk, not raw chain data, which keeps the client thin and the maths in one place.
Transaction reliability under reorgs and mempool congestion
Mutations are idempotent and keyed. Submissions are tracked through a state machine with explicit replacement and cancellation paths rather than fire-and-forget signing.
Oracle failure is a solvency event, not a UI bug
Feeds are checked for deviation and staleness before entering the risk model. On breach the engine holds last-known-good and blocks new leverage instead of computing on bad prices.
Risk policy must be auditable, not buried in application code
Haircuts, concentration caps and LTV ceilings are declarative configuration with versioned history, so a limit change is a reviewable diff.
The stack behind it.
Risk engine
- Rust
- Redis
- Event-stream evaluation
- Health-factor model
- Collateral haircut matrix
- Concentration limits
- Price-shock simulation
Oracle safety
- Chainlink price feeds
- Multi-source median
- Deviation bounds
- Staleness thresholds
- Last-known-good hold
- New-leverage circuit breaker
Smart contracts
- Solidity
- Foundry
- OpenZeppelin
- Slither
- Invariant tests
- Liquidation hooks
- Role-gated admin paths
Venue adapters
- TypeScript
- viem
- Adapter pattern
- Position normalisation
- eth_call simulation
- Slippage bounds
API & execution
- Node.js
- REST
- WebSocket
- JWT
- Idempotency keys
- Rate limiting
- Transaction state machine
Position state & indexing
- PostgreSQL
- ClickHouse
- Kafka
- Reorg-safe indexer
- Event sourcing
- Block-height stamped reads
Desk interface
- Next.js
- React
- TypeScript
- Tailwind CSS
- WebSocket streams
- Streaming risk subscriptions
- Virtualised position tables
How it grows with the business.
The same system at three stages. Most products should not start at the third — but the architecture should not have to be thrown away to get there.
A single venue and asset class, with the risk surface right from the start.
- One lending market, one chain
- Position and collateral views
- Health factor with alerting
- Read-only portfolio reporting
Multiple venues behind one position abstraction, with execution.
- Venue adapters for additional markets
- Cross-margin collateral baskets
- Pre-trade simulation and slippage bounds
- Yield attribution and strategy templates
Desk-grade controls, reporting and segregation of duties.
- Policy-as-code limits with approval workflows
- Middle-office reporting exports
- Multi-entity and multi-desk segregation
- Scenario library for stress regimes
Where it could go next.
Directions this system would extend into.
- 01
Cross-margin netting across venues to reduce total collateral requirement
- 02
Policy-as-code risk limits with approval workflows and change history
- 03
Intent-based execution so desks express target exposure rather than individual transactions
- 04
Scenario library for stress testing against historical volatility regimes
- 05
Institutional reporting exports aligned to existing middle-office formats
Building lending, collateral or liquidity where a desk has to see its risk before it commits capital?
We built APEX to work through exactly this. Tell us where you are and we will tell you what we would do differently for your constraints.