Market Making
Liquidity simulation with risk controls in view.
Liquidity simulation with the risk controls in plain view — books, strategies, treasury guards, and an operator stop.
- project
- Lunor Demo
- token
- LUNR
- module
- markets
- category
- liquidity
- status
- live · sandbox
Every figure in this module's demo is fabricated. No wallet connection, no signing, and no broadcast path exists from this site.
The problem
Liquidity operations are usually a black box holding your exchange keys.
The standard arrangement is an opaque one: a provider receives API keys and a budget, reports volume numbers, and gives the project no visibility into what the strategy is doing, what it is permitted to do, or what happens when it goes wrong. Frequently those keys carry withdrawal permission because it was easier to issue them that way.
The failure modes are not theoretical. A misconfigured strategy becomes the dominant participant on a thin book, spend runs past the intended daily budget, or the price moves against the treasury while nobody on the project side has a way to stop it. The project carries the loss and the explanation.
The approach
A simulator where the controls are the product.
The dashboard shows what an operator needs: volume split, open orders, spread, depth, treasury, current versus target price, and daily cost. Markets show an animated order book, depth chart, recent trades, and bot activity so the behaviour of a configuration is observable rather than reported.
Strategies are configured with explicit bounds — volume target, order sizing, frequency, spread, order count, buy/sell ratio, liquidity range, daily budget, treasury limits, and price guardrails — and simulated before capital is committed, with estimated capital requirement, order count, timeframe, and projected depth shown first. The risk panel puts permission state, spend limits, and the emergency stop on one screen.
Capabilities
What the module does.
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.
How it works
The workflow, step by step.
- 01Review the dashboard
Establish the current state: volume, spread, depth, treasury, and price versus target.
- 02Inspect a market
Watch the order book, depth, and bot activity to see how the book behaves.
- 03Configure a strategy
Set volume target, sizing, spread, ratio, budget, and guardrails as hard bounds.
- 04Read the estimates
Capital requirement, order count, timeframe, and projected depth before anything runs.
- 05Run the simulation
Observe simulated execution against the configuration you set.
- 06Verify the risk panel
Confirm permissions, spend ceilings, guards, and that the stop is reachable.
Specification
At a glance.
- Strategy parameters
- Volume, sizing, frequency, spread, order count, ratio, range, budget
- Guards
- Daily spend, treasury limit, price deviation, safety stop
- Permission checks
- Trade, withdrawal, IP allowlist state
- Market views
- Order book, depth chart, trades, bot activity
- Venues in demo
- Generic placeholders — no client accounts
- Public environment
- Simulation — no orders are placed
Security
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
Full posture, including what we deliberately do not claim, is on the security page.
Use cases
Where it gets used.
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.
Solution paths
Where this module sits in a bigger job.
FAQ
Questions asked before adopting this module.
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.
Other modules
Same Console, same project record.
Next step
Run it before you ask us anything.
The Console needs no signup and no wallet. Open the module, use it against sandbox data, then bring us the specific questions.