Orderbook
Vortum's matching engine is a fully on-chain central limit order book (CLOB) — the same price-time priority model behind every major financial exchange. It matches orders in ~400 ns at over 1M ops/sec, running inside an ICP canister.
The engine is chain-agnostic and storage-agnostic — matching logic has zero blockchain dependencies, and a pluggable storage interface allows swapping between in-memory, stable memory, or any custom backend without changing the engine. This makes the orderbook portable and reusable beyond ICP.
Matching Engine
Every order goes through a deterministic pipeline — validation, risk checks, matching, and settlement — all within a single canister call. Orders match against the best available price first, and at the same price, the earliest order fills first.
Every trade is recorded with both participants, execution price, fees, and timestamps — creating a complete, verifiable audit trail.
Multi-Market Architecture
Each trading pair (BTC/USDC, SOL/USDC, etc.) runs its own independent order book instance with isolated state, risk controls, and metrics. Markets can be added or removed without affecting existing ones.
Market Modes
The platform supports operational modes for safe market management:
| Mode | Description |
|---|---|
| Normal | Full trading — all order types accepted |
| Post-Only | Only maker orders accepted — used during market opening or low-liquidity periods |
| Cancel-Only | Users can only cancel existing orders — used for orderly wind-down |
| Maintenance | Market temporarily offline — all operations paused |
Pre-Trade Simulation
Traders can simulate market order execution before committing capital — previewing expected fill price, slippage estimate, fill quantity, and total notional value. The simulation walks the real order book without modifying state.
Order Types
| Type | Status | Description |
|---|---|---|
| Market | ✅ | Execute immediately at best available price |
| Limit | ✅ | Execute at a specified price or better |
| Stop Loss | 🔜 | Trigger a market order when price drops to a level |
| Stop Limit | 🔜 | Trigger a limit order at a stop price |
| Take Profit | 🔜 | Trigger a market order at a profit target |
| Take Profit Limit | 🔜 | Trigger a limit order at a profit target |
| Trailing Stop | 🔜 | Stop price adjusts as the market moves in your favor |
| Iceberg | 🔜 | Large order split into visible and hidden portions |
| TWAP | 🔜 | Time-weighted average price — executes over a set time period |
| Bracket | 🔜 | Entry order with attached take-profit and stop-loss |
Execution Control
Time-in-Force
| Option | Description |
|---|---|
| GTC | Good Till Cancel — stays on the book until filled or cancelled |
| GTD | Good Till Date — auto-expires at a specified time |
| IOC | Immediate or Cancel — fill what's available, cancel the rest |
| FOK | Fill or Kill — fill the entire quantity or reject completely |
Execution Modes
| Mode | Description |
|---|---|
| Post-Only | Guaranteed to rest on the book — rejected if it would match immediately |
| Reduce-Only | Can only reduce an existing position, never increase it |
| All-or-None | Must fill completely or not at all |
| Minimum Quantity | Minimum fill size per execution |
Batch Operations
- Cancel all orders for a user in a single call
- Cancel by filter — side, price range, or any order attribute
- Bulk order expiry for GTD orders past their deadline
Risk Management
The engine enforces per-user risk controls with tiered access, enabling different limits for retail and institutional participants.
| Control | Description |
|---|---|
| Position limits | Maximum long or short exposure per user |
| Order size limits | Caps on single order quantity and notional value |
| Rate limiting | Sliding-window throttling per user (configurable orders/sec) |
| Daily volume caps | Cumulative quantity and notional limits with automatic daily reset |
| Price bands | Minimum and maximum acceptable price per user |
| Order type restrictions | Restrict users to limit-only, market-only, or both |
| Slippage protection | Maximum price deviation in basis points — matching stops beyond threshold |
| Self-trade prevention | Five modes to prevent matching against own resting orders |
| Order modification | Cancel-and-replace with fill validation and lot size constraints |
Subaccounts
Each user can create up to 255 subaccounts under a single identity. This enables:
- Running multiple trading strategies with isolated positions
- Separating risk across different market approaches
- Portfolio segmentation without multiple logins
Fee Model
The engine supports a maker/taker fee structure tracked per trade:
- Maker fees — charged to the resting (passive) order
- Taker fees — charged to the incoming (aggressive) order
- Fees are recorded with configurable fee symbols per side
- Per-user fee breakdowns available through analytics
Market Data & Analytics
Real-time data available to all participants, updated with every trade:
| Data | Description |
|---|---|
| Order book depth | All price levels with aggregate quantities |
| Best bid/ask | Spread and mid-price — queryable in ~14 nanoseconds |
| Trade history | Complete record with participants, fees, and timestamps |
| 24h OHLCV | Open, high, low, close, volume with automatic daily reset |
| VWAP | Volume-weighted average price (market-wide and per-user) |
| Price change | Absolute and percentage change from open |
| Market quality score | Composite 0–100 score from fill rate, spread tightness, volume, and efficiency |
Per-User Analytics
Every participant has individually tracked metrics — orders submitted, filled, and cancelled; volume and notional traded; VWAP; fill rate; and aggressive-vs-passive order ratio.
Integration
Orders support external order IDs — clients can attach their own identifiers for reconciliation between their systems and Vortum. Each order also tracks its source (API, SDK, UI), enabling analytics by integration channel.
This is how institutional trading desks operate: they need to map every fill back to their internal order management system. Vortum supports this natively.
Audit Trail
Every order and trade is permanently recorded on-chain:
- Complete order history with enforced status transitions (Pending → Active → Filled / Cancelled / Expired)
- Trade records with execution price, quantity, timestamp, taker side, and both participant IDs
- Maker and taker fee breakdowns per trade
- Per-account settlement history
All data is queryable on-chain. No off-chain components, no trust assumptions.