Market Making
Liquidity simulation with risk controls in view.
What it is
Order books, strategies, treasury guardrails, and an emergency stop — as a simulator. The public demo does not execute live trades.
Liquidity simulation with the risk controls in plain view — books, strategies, treasury guards, and an operator stop.
The public Console runs this module on fabricated data. Nothing there is signed or broadcast.
Who it is for
Liquidity design review
Modelling spread, depth, and cost before capital or a provider is committed.
Risk policy walkthrough
Showing stakeholders exactly which permissions and guards are in force.
Operator training
Rehearsing the arming, monitoring, and stopping procedure before it is needed.
Provider evaluation
Establishing what visibility and controls to require from any liquidity arrangement.
How it works
- 01Review the dashboardEstablish the current state: volume, spread, depth, treasury, and price versus target.
- 02Inspect a marketWatch the order book, depth, and bot activity to see how the book behaves.
- 03Configure a strategySet volume target, sizing, spread, ratio, budget, and guardrails as hard bounds.
- 04Read the estimatesCapital requirement, order count, timeframe, and projected depth before anything runs.
- 05Run the simulationObserve simulated execution against the configuration you set.
- 06Verify the risk panelConfirm permissions, spend ceilings, guards, and that the stop is reachable.
What it includes
Operator dashboard
Volume split, open orders, spread, depth, treasury, price versus target, and daily cost.
Market view
Animated order book, depth chart, recent trades, and bot activity per venue and pair.
Strategy configuration
Volume, sizing, frequency, spread, order count, ratio, range, and budget as explicit bounds.
Price scaling targets
Configure a target move with the capital and timeframe it implies made visible.
Pre-run estimates
Capital requirement, order count, timeframe, and projected depth before simulation.
Risk panel
API permission state, withdrawal status, IP allowlist, spend limit, treasury and deviation guards.
Emergency stop
Operator-accessible kill switch that does not require engineering involvement.
Performance and treasury
Performance charting, treasury tracking, and an activity log.
Boundaries
Withdrawal permission is never requested, and the emergency stop belongs to the operator.
- Trading integrations run with trade permission only; withdrawal is asserted disabled before a strategy can arm
- IP allowlisting required on venue keys where the exchange supports it
- Daily spend ceiling and treasury guard evaluated independently of venue limits
- Price-deviation guard prevents a strategy from chasing its own impact
- Emergency stop is operator-accessible without engineering involvement
- The public demo holds no keys, connects to no venue, and places no orders
Questions
Are these real exchanges?
No. Venues are generic placeholders and every figure is fabricated. There are no client accounts, no venue credentials, and no orders placed from this interface.
Do you need withdrawal permission on our API keys?
No. Strategies run with trade permission only. If a key carries withdrawal permission, the system treats that as a blocking risk state until it is removed — which is why the risk panel shows permission state before anything else.
Is this market manipulation?
The public surface is a simulator and executes nothing. In production, this is liquidity provision with explicit bounds, spend ceilings, and price guardrails specifically so a configuration cannot become the dominant participant on a book.
Who can stop a running strategy?
The operator, from the interface, without engineering involvement. A kill switch that requires a support ticket is not a kill switch.
What does the simulation actually tell us?
Capital requirement, expected order count, timeframe, and projected depth for a given configuration — enough to decide whether the target is achievable before any capital is committed to it.