A Clearer Command Surface for Market Making: ADAMANT WebUI Scenario A-3

Market making becomes safer when the operator can understand the bot’s state before pressing a button.

Today we are sharing the third and final MVP increment of Scenario A: the private, self-hosted ADAMANT Market-Making WebUI. It turns the browser from a collection of isolated controls into a clearer operating surface for the people who run token liquidity day after day.

This is not a hosted trading terminal and it is not a replacement for operational discipline. It is a private control plane that helps an operator answer the questions that matter in the moment: Is market making running? Which policy is active? What changed? Is the bot safe to resume? What does this configuration actually mean?

Good operator software does not make risk disappear. It makes the current state legible enough to act deliberately.

The release is tracked in ADAMANT Discussion #77 and its public implementation tracker, WebUI issue #4. The corresponding implementation PR has been merged as an additive update on top of the earlier Scenario A work.

From a bot console to an operator dashboard

Market-making infrastructure is often technically capable but operationally opaque. Status lives in one command, parameters in another, balances somewhere else, and the reason for a protective stop may be buried in logs. That arrangement can work for a developer at a terminal; it is much less useful for an operator who needs to assess a live market quickly and responsibly.

The new per-bot Dashboard is the primary landing view. It brings together pair and exchange context, market-making state from the bot’s /status API, a feature-edition badge, a compact 15-minute price chart, active and inactive modules, a readable parameters summary, balances, and open orders grouped by purpose.

One subtle detail matters: the edition badge — Basic through Full — is derived from the bot’s installed capabilities, not from whichever modules happen to be enabled at that instant. A temporarily disabled module should not make an operator misidentify the bot they are managing.

Control should preserve the policy already chosen

The Start action has been made intentionally less opinionated. Starting market making no longer sends a strategy override: the bot keeps the current policy already configured on the bot itself. That distinction prevents a user-interface click from silently changing the operating model of a live strategy.

At the market level, the WebUI now makes placement easier to inspect without pretending that visual information is a trading signal. Operators can see a forming candle on the OHLC chart, bot-order markers in the order book and recent trades, open-order overlays, spread context, balances, and the order-entry surface. Cancelling an order sends a precise { id, market, side } request; an order that has already disappeared is handled as a successful outcome rather than an alarming false failure.

This is a practical design choice. Markets move; user interfaces should distinguish a real operational exception from the normal race between a human click and an already-filled or already-cancelled order.

Safety is part of the interface, not an afterthought

A bot that protects itself is valuable. A bot that can explain the protection to its operator is more useful still.

Scenario A-3 connects the safety path into the WebUI. When the bot auto-stops market making or pauses a ladder for safety, the browser surfaces the bot’s notification text in a dialog and reflects the emergency state in Parameters. Safety events appear in the Events board with visible badges; a suspended ladder can be resumed from the relevant event row when an operator has investigated the cause.

The Events board also adds change provenance and balance context. It records parameter changes from the WebUI versus bot-side sources, shows the market-making state, and can display balance snapshots and deltas at the time of an action. That does not replace monitoring, runbooks, or human judgment. It does create a more coherent audit trail for the questions that follow every incident: what changed, who initiated it, and what did the account look like at that moment?

A safety stop is not merely an error state. It is an operational event that deserves context, visibility, and a deliberate recovery path.

Live situation makes history useful

The Parameters screen now includes a 12-hour Live situation strip in the operator’s timezone. It summarizes inventory value and open-order notional by purpose, giving an operator a compact sense of how exposure and liquidity placement evolved over the recent working window.

It also makes degraded and stopped periods visible instead of flattening them into a single reassuring chart. Health history is shown in hourly frames: a degraded hour is yellow, while an hour with market making stopped is grey. After a start operation, the quality model includes a 10-minute grace period so that a newly started bot is not immediately judged against data it has not had time to produce.

That is the product philosophy behind this release: visibility should express uncertainty honestly. “Working”, “degraded”, and “stopped” are more useful than a permanently green dashboard.

Configuration without hunting through files

Configuration is where many tools become either too casual or too exposed. The new admin-only Config view keeps the useful context together: Runtime, Pair, and a live tree of tradeParams_*.js values sit side by side, followed by a structured config.json summary and a raw JSON view.

The design deliberately exposes operational facts without turning the browser into a secret store. The configuration snapshot is sanitized; socket fields say Not included when the bot does not report them; and an exchange that omits minimum trade values is represented as Not provided, rather than as a misleading zero.

A private fleet should retain its context

Running more than one bot introduces another kind of friction: switching tabs can erase the operator’s place in the work. Scenario A-3 adds a clearer fleet shell and registry. Each bot gets an editable Label and Account, with useful defaults derived from the bot ID and configuration; the header shows both. Transport, version, branch, and pair balance are also visible at fleet level. Offline or unknown rows are muted, while connected bots that are simply stopped remain readable rather than being treated as absent.

Behind the interface, keep-alive panes preserve vertical scroll and in-page state across bot and section switches. Hidden panes read a frozen Redux snapshot instead of collapsing to an empty state. It is a small implementation detail with a very human payoff: an operator can compare a market, inspect configuration, and come back without losing the thread.

The security boundary stays intentionally narrow

The WebUI remains a private self-hosted Scenario A deployment. It uses DirectHttpTransport to talk to the bot’s /api/v1 surface; the browser and the WebUI backend do not connect to exchanges, and exchange API keys do not belong in the WebUI. Mandatory operator 2FA supports email, ADAMANT, or Ethereum-wallet verification.

The stack is deliberately conventional where that helps operators maintain it: Vite, React 18, Chakra UI, a Fastify BFF, and a SQLite event log. The feature is additive, with fallback to the existing /health route for older bots that do not yet expose /status. A matching modern bot build is needed for Start-without-strategy behavior; that is a compatibility boundary worth making explicit.

Self-hosted does not mean unmanaged. It means the operator keeps control of the deployment boundary — and accepts the responsibility that comes with it.

What is complete — and what is not

Scenario A, the private self-hosted MVP, is feature-complete for its stated scope. The next deployment model, Scenario B, remains separate: an outbound relay, public subscription WebUI, licence-token scope, and push market data are not quietly bundled into this release. Today’s WebUI still polls REST APIs for market data.

That separation is deliberate. The release makes the existing private operator workflow clearer and more auditable before expanding the trust model. For teams running a token market-making bot, the result is a calmer answer to a basic operational need: one screen that connects live state, controls, history, configuration, and safety context — while keeping the exchange boundary where it belongs, inside the bot.

Read the implementation update: Discussion #77 · public issue #4 · WebUI repository

A Clearer Command Surface for Market Making: ADAMANT WebUI Scenario A-3 was originally published in ADAMANT on Medium, where people are continuing the conversation by highlighting and responding to this story.