The spot desk: orders, withdrawals and customer tickets

Three screens carry the day-to-day work of an XT-backed spot book, and none of them is the exchange hub. The hub tells you whether the provider is connected; these tell you what your customers are actually doing with it and where their money has stopped.

Read this page before you grant anyone the permissions in the next section. On an XT install two of these screens behave in ways the interface does not explain, and one of them can refund a customer while looking like it paid them.

The permissions, including the three nobody documents

The Spot Orders screen is gated on access.exchange.order, and its endpoints on three further keys that no reference page in this product listed until now.

The other two screens use keys of their own: access.withdraw and view.withdraw for the payout queue, edit.wallet for approve and reject, edit.withdraw for the bulk decision, and access.support.ticket / view.support.ticket / edit.support.ticket / delete.support.ticket for the support desk.

Spot Orders

/admin/finance/order/exchange is a record, not a control panel. It lists every exchangeOrder row with the trader joined, twelve to a page, and the only action is opening one.

The columns are id, referenceId, the trader, symbol, type (MARKET / LIMIT), timeInForce (GTC / IOC / FOK / PO), side (BUY / SELL), price, amount, filled, remaining, cost, fee, feeCurrency, status and createdAt. Several are collapsed into the expanded row rather than shown in the grid.

referenceId is XT's own order id. It is the join key between your database and anything you export from XT's interface, and it is the value the reconciler passes to fetchOrder.

The five statuses

The status column is an ENUM and holds exactly these:

Opening an order

The view dialog is the one place the full record is visible: the trader (name, email, user id), pricing including average fill price — which has no column of its own and is the only field that says what the order actually executed at — a fills table built from the order's trades, the local id beside XT's referenceId, the raw settlement metadata, and the timeline.

The tiles above the table, and how to read them on XT

The analytics strip is worth learning because three of its figures are the early warning that the XT connection is degrading.

Two rankings sit below: Fee Revenue by Currency (top five, each bar in its own asset — ranked, never summed) and Top Symbols by Settled Notional (top eight).

What settles an order, and the XT quirk in it

processPendingSpotOrders runs every 60 seconds on the cron worker. It sweeps every OPEN order with a referenceId, calls fetchOrder(referenceId, symbol) on XT, and acts only on a terminal status or a partial fill. Failures are isolated per order and logged under the SPOT_RECON module — a stuck order produces Failed to reconcile spot order <id> (ref <referenceId>) on every tick.

Two behaviours are worth knowing at the desk:

• A market with no exchangeMarket row cannot settle. The reconciler resolves the fee rate from the market row for the order's symbol; without it it logs "Market data not found for <symbol>" and abandons that order, permanently, with the hold in place. Never delete a market that still carries open orders.
• Buy quantities from XT are in the quote asset. For a BUY, XT reports info.executedQty as the amount spent; the platform divides it by info.avgPrice before crediting. This is handled, and it is why the filled column will not match a raw XT CSV column by column. See Deposits and withdrawals.

Withdrawals

The queue itself — how it opens, what Approve does per wallet type, the two 409s, the mandatory rejection reason — is Working the withdrawal queue. Everything below is what changes when the active provider is XT.

That leaves one working configuration for spot payouts on XT, and one workaround:

Auto-approve. With withdrawAutoApprove on, the customer's own withdrawal request calls exchange.withdraw through the XT branch at request time and never reaches the admin queue.

Both are stored as text: the string "true" is on, anything else is off. The shipped default is manual review — which is the configuration in which XT payouts do not work.

Or pay by hand and reject with an explanation. Send the payout from XT's own interface, then reject the platform row with a reason that says so. Rejection refunds the customer, so this only balances if you have separately debited them — it is bookkeeping you must get right yourself. There is no admin action that marks a spot withdrawal paid without calling XT.

The status vocabulary XT answers with

When a withdrawal does dispatch, XT's statuses are mapped onto the platform's: SUCCESS → COMPLETED, SUBMIT / REVIEW / PENDING → PENDING, AUDITED / AUDITED_AGAIN → PROCESSING, FAIL → FAILED, CANCEL → CANCELLED. Anything else is uppercased and used verbatim, which is how an unfamiliar value reaches this screen unchanged.

The two withdrawal crons

Both were missing from this product's cron table. Both matter at the desk.

reconcileSpotWithdrawals is the one to understand, because it is the only thing standing between a crashed dispatch and either a lost payout or a double one. A PROCESSING row has already been debited, and there are two cases:

• referenceId set — exchange.withdraw succeeded and the status update was lost. The job converges the row to XT's reported status, refunding atomically (refund first, status second) on FAILED or CANCELLED. If the id is not in the page XT returns, the row is not refunded: pagination is not evidence of absence.
• referenceId null — the process died somewhere around the withdraw call and the payout may or may not have been sent. Nothing happens for 24 hours. After that the job scans XT's withdrawal history over a window starting an hour before the row was created, and only refunds when that scan positively shows no plausible match on address or amount.

Anything ambiguous is escalated rather than settled: the row stays PROCESSING, a Super Admin gets an in-app notification titled "Withdrawal Requires Manual Review", and the backend logs MANUAL REVIEW REQUIRED: with the reason. The row then backs off exponentially — one hour, doubling, capped at 24 — so a permanently unresolvable row stops burning XT rate limit. A row that never refunds a customer is behaving correctly; it is waiting for you.

The five crons behind this desk

Admin → System → System Monitoring → Scheduled Tasks (/admin/system/cron, access.cron) shows the last run, the last error and the next scheduled run for each. Nothing in the System menu is called "Cron" — that word appears only in the URL. Triggering a job by hand needs manage.cron.

Every one of them is a no-op while there is no active provider or while the Redis ban switch exchange:ban_status is set — and a banned install reports green on all five, because they complete successfully having done nothing. See Reference.

backend and cron are separate processes by default. These five run in the cron process only.

The memo hazard, and why XT can never warn you about it

XT publishes no memo metadata. The XT branch of the currency standardiser sets withdrawMemo: false on every network it builds, with the reason in the code:

withdrawMemo: false, // XT data doesn't have memo information, defaulting to false

It then goes nowhere. The spot currency import assembles those network rows into a chains value and never writes it: exchange_currency has columns for currency, name, precision, price, fee and status, and nothing else. There is no memo flag in your database for any provider, and on XT there is no data path that could ever produce one.

What actually decides whether a customer is asked for a destination tag is a hard-coded list of five tickers in the withdrawal form — XRP, XLM, EOS, ATOM, HBAR — plus BNB when the selected chain is BEP2 and not BEP20. For those, the field is mandatory and the form says a missing memo is unrecoverable.

Deposits are the mirror image: memos are only as good as what the customer is told on the deposit screen, and nothing in the imported data says a memo is required there either. Say it in the currency's description yourself.

Why the desk breaks if the server presents IPv6

One line in the connection layer decides whether any of this works, and it names XT:

// Force IPv4 for exchanges like XT.com that don't support IPv6 whitelisting
const httpsAgentIPv4 = new Agent({ family: 4, keepAlive: true, timeout: 30000 });

Every XT connection the platform builds — the live one, the credential test, the proxy test — uses that agent unless a proxy URL is set on the provider row, in which case the proxy agent replaces it and the family: 4 pin is gone.

XT's API-key IP allowlist takes IPv4 addresses. A dual-stack server that presents an IPv6 source address is refused on every signed call, and the refusal looks exactly like a bad secret: invalid credentials, on a key you know is correct. That is the failure this pin exists to prevent, and it is why a proxy must itself be IPv4-capable and its own address allowlisted.

If the desk goes dark all at once — orders failing, balances empty, deposits unverified — check curl -4 https://api.ipify.org from the app server against what is on the key before you touch anything else. Details in API keys and network access.

Customer tickets

Support is where the first three sections arrive, usually before your monitoring does. The desk itself — the queue's ordering rule, the five filters, assignment, the archive and its bulk verbs — is Running the support desk. Four statuses, all answering whose turn is it: PENDING and OPEN are waiting on you, REPLIED is waiting on the customer, CLOSED is done.

What is worth having ready is the mapping from what a customer says to what to open first.

Two things to keep out of a reply: the provider's name, and the reason a withdrawal was rejected if you have not established it. Neither is recoverable once sent.

What we could not determine

• Nothing records which provider an exchangeOrder, wallet or transaction row belongs to. There is no column and no audit entry. After a provider change the only signal is the row's creation date against the date you switched.
• The withdrawMemo value the XT standardiser computes is not persisted anywhere, so we cannot say what it was originally meant to drive. Nothing in the current codebase reads it.
• Whether XT's own API would expose memo requirements through a different call is outside what this platform asks it for.

Related

• Working the withdrawal queue — the queue's own contract, wallet-type routing and the bulk decision
• Running the support desk — queue ordering, statuses, assignment and the archive
• Deposits and withdrawals — the three network maps and the XT status mapping in full
• Currencies and markets — where fees and precision come from
• API keys and network access — IPv4, allowlisting and the proxy path
• Reference — every endpoint, permission, cron and Redis key
• Troubleshooting — symptom-first diagnosis