Skip to content
Trader Console

From a questionto a filled order

Six things happen between you asking and an exchange seeing an order. Two of them are the model’s. The other four are code that runs the same way every time, and this page walks through all of them.

BTC/USDTReduce
decision · draft

Proposed Close half the position, market

  • Account connectedMEXC futures · yours
  • Reduce-onlyno new exposure
  • Daily loss haltexits stay allowed
  • Approval signaturevalid · 30s

Sent, filled, and written down

The fill carries the decision that caused it: the question you asked, the proposal, the four checks and the venue’s order id.

A proposed long in BTC/USDT, refused by 0 of 4 risk checks before reaching the venue.

The four steps that are not the model

The model writes and reads. It does not decide, and it is not asked to be trusted — this is the part of the system built so that trusting it is unnecessary.

  1. 01

    Intent

    A proposal becomes an intent: one account, one instrument, one size, one direction. Anything the model left vague is refused here rather than guessed.

  2. 02

    Risk evaluation

    Your limits are applied — size, daily loss, exposure, leverage, instrument. The answer is signed, and it expires in seconds so a stale approval cannot be replayed.

  3. 03

    Confirmation

    Live orders wait for you unless you have granted a strategy automatic execution. Granting it widens what may pass; it never removes a check.

  4. 04

    Execution

    One order, once. It is claimed under an id we issue, so a lost response resolves into exactly one order at the venue rather than two.

The checks, named

These run on every order — proposed by you, by a strategy, or by the model. There is no path around them, because the service that places orders will not accept an intent without a valid signature from the service that checks them.

  • Position size against your maximum risk per trade, computed from the stop, not from the notional.
  • Daily loss: past your limit, new entries stop for the day. Reducing and closing stay open, because blocking an exit turns a bad day into a bad month.
  • Open exposure and position count, per account and across accounts.
  • Leverage, per instrument, capped below whatever the venue would allow you.
  • The instrument itself: an account trades what you enabled for it and nothing else.

What people ask next

What if the model is simply wrong?

Then it produces a wrong proposal, and the proposal is text. It costs you a paragraph to read. The checks are not there to make the model right — they are there to bound what being wrong can cost.

Can the model change my limits if I ask it to?

It can walk you to the screen where you change them yourself. It has no call that writes them, and the service that evaluates orders does not accept limits from the same process that drafts orders.

What happens if the exchange never answers?

Every order carries an id we issue before sending. On a lost response the console asks the venue what it has under that id, and reconciles to exactly one order — the failure mode that quietly doubles a position is the one thing this part of the system exists to prevent.

Do you see my keys?

They are stored per account and used only by the process that talks to the venue. They are not readable from chat, not sent to any model, and not held in a process that serves another customer.

The whole path, on paper first

A paper account runs every step above against live market data — the same proposals, the same checks, the same audit trail, with nothing at stake.