Risk console

You are the counterparty to every position on this book, so the book's risk is your risk. Three admin screens answer three different questions, and it is worth being deliberate about which one you open.

Screen	Path	Permission	Answers
Dashboard	/admin/futures	access.futures.market	Is the open book acceptable right now?
Positions	/admin/futures/position	access.futures.position	What is this specific trader holding?
Orders	/admin/finance/order/futures	access.futures.order	What was placed, filled or cancelled?

The orders table sits under Finance → Orders rather than in the Futures menu, alongside the spot, ecosystem and binary order books.

The dashboard

/admin/futures shows five things, over a window you choose — 24h, 7d or 30d. The window affects the activity series and the period counters; the open-book figures are as of now.

Overview. Open positions, notional exposure and the headline risk figures for the live book.

Exposure by market. Open interest per symbol and the side skew — how far the book leans long or short on each contract. This is the number that tells you what directional position you are involuntarily holding. Long and short are never distinguished by colour alone on this page; every direction also carries a word and an arrow.

At risk. The open positions closest to liquidation, ordered by how much of their posted margin they have already lost.

Leverage bands. Where the leverage is concentrated, in five buckets: 1-5x, 6-10x, 11-20x, 21-50x and 50x+. A book whose exposure sits in the top band is one ordinary daily range away from a wave of liquidations.

Activity. Positions opened, closed and liquidated over the window.

The number that makes the page worth opening

Margin used, expressed as a percentage of the way to liquidation. It is derived from the position row alone — return on margin is exactly unrealisedPnl ÷ postedMargin — so it needs no price feed and no extra query. A position at 50% is half way there; the engine has not acted yet, and you can see it before it does.

The risk bands on the page are the engine's own, not a designer's:

Band	Range	Meaning
Comfortable	below 50%	Ordinary
Watch	50% to 77.8%	Losing, not yet the engine's problem
At risk	77.8% and above	The engine will trim these on their next mark

The 77.8% boundary is the partial-liquidation threshold expressed on the same scale as the full one (0.7 ÷ 0.9). It moves automatically if either engine constant ever changes; there is no second copy to drift.

One honest cap, reported

The Scylla position table is partitioned by user id, so there is no time-ranged read of it and the dashboard has to scan. That scan is paged and stops at a cap — 50,000 rows by default, tunable with FUTURES_DASHBOARD_SCAN_CAP.

Results are cached for 15 seconds, so an auto-refreshing tab does not put a full table scan on your cluster every poll.

The positions table

/admin/futures/position is a read-only view of the Scylla position table. There is no admin force-close: you can see a position and you can disable the market it trades on, but you cannot end it for the trader.

Columns: symbol, side, user id, entry price, position size, leverage, unrealised PnL, stop loss, take profit, status and opened-at.

Three things to know before you read a row.

Status is one of three values. OPEN, CLOSED or LIQUIDATED. Nothing else is ever written.

Size tells you which ending it had. A CLOSED row keeps the size the position had — closing writes the status only. A row liquidated against the mark has its size written to zero. So a LIQUIDATED row with size zero was settled by the engine when the book could not take it; see Liquidation.

Unrealised PnL is meaningless on a closed row. It is a mark-to-market figure maintained only while a position is open; on a closed or liquidated row it is frozen at whatever the last mark happened to be. Never sum it across statuses.

Why the analytics are all counts

The positions and orders tables run against ScyllaDB, whose aggregator understands exactly one thing: count rows where a column equals a literal. Entry price, amount, leverage and PnL cannot be summed there. Every KPI on those two pages is therefore a row count — open, closed, liquidated, total — and the money figures live on the dashboard, which does its own scan.

The orders table

/admin/finance/order/futures lists every futures order with pagination, filtering, sorting and search. It is view-only: no create, no edit, no delete.

Useful fields when you are reconstructing what a trader did:

• isTaker — which rate was actually applied, decided from the resting book at placement and stored on the row. This is how you answer "why was I charged the taker fee on a limit order": because it crossed.
• filled, remaining, average — a CLOSED order still tells you exactly how much of it traded and at what average price.
• reduceOnly and positionId — set on liquidation orders. An order with reduceOnly true, zero cost and zero fee was placed by the engine, not by the trader.
• leverage — a plain integer. If a table anywhere renders it as 0.00x, that display is de-scaling a value that was never scaled.

A daily routine

• Dashboard, 24h: is exposure skewed hard one way on any market?
• At-risk panel: anything sitting above 77.8% that has been there for hours?
• Leverage bands: how much notional is in 50x+?
• Logs: any FUTURES_SHORTFALL lines since yesterday?
• Cron page: are the three futures jobs running, and did the reconcilers report errors?

The first two are about today. The third and fourth are about whether your market configuration is writing cheques your order book cannot cash — and the fix for those is always upstream, in the leverage rungs and the cost limits, never in a position row.