QX Admin

Transaction List

The Withdrawal Main Wallet per EVM/TRON network — it pays withdrawals and sweep gas. Clean/Dirty risk-sweep wallet balances live on the Risk Wallets page; Abelian payout wallets on the Abelian Main Wallet page. Wallets and configured assets load without chain reads; use Refresh all or a single network's Refresh to read live balances (not persisted).

The platform's Abelian payout wallets. The default wallet pays withdrawals first, receives U9 sweeps, and funds ABEL fee top-ups; when it has no spendable balance a withdrawal automatically fails over to the other active wallets. Inactive wallets are never used for new operations. Each wallet must hold U9 (the transfers) and native ABEL (the fees) — scan a wallet's address to top it up. Balances are read live per wallet with Refresh.

The clean (low-risk) and dirty (high-risk) sweep destination wallets. Each is configured by entering its 24-word recovery phrase: the server validates it, derives the deposit addresses (EVM shared by ERC20/BEP20, and TRON), and stores only the addresses. The phrase itself is never saved anywhere — keep your offline backup; funds swept into a wallet are unrecoverable without it. After saving, verify the derived addresses match the same phrase opened in your own wallet software — the Abelian app, MetaMask, or TronLink all show these exact addresses (standard first account, m/44'/60'/0'/0/0 for EVM and m/44'/195'/0'/0/0 for TRON). Balances below load per network with Refresh; they are read live and not persisted.

Wallet Management

Deposit wallets across all users. The list is database-only: wallet balances are read on demand with the per-row Fetch balance action, and Sweep queues a single-wallet sweep through the existing sweep checks.

Balance Management

Internal balances for every user account and active asset. Pairs without a balance record show as zero without creating one; Adjust balance uses the audited manual adjustment flow.

Balance Ledger

Append-only record of every change to user balances. Each row shows the before → after for available and locked, the delta, the entry type, and the causing transaction. The sum of deltas per user/asset equals the current balance.

Audit Log

Unified history of sign-in outcomes and administrative changes.

3DS OTP Prompts

Every live one-time code prompt in pending_3ds (prompt_type = otp): a Wasabi merchant 3DS step-up, or a Tevau card-token OTP for Apple Pay / Google Pay wallet provisioning — where Merchant / Wallet carries the requesting wallet and the amount is zero. Interactive approve challenges and the url/activation kinds are not listed. Status tells you whether the app ever got the code: the cardholder app's poll marks an OTP sent the moment it collects it and never delivers it again, so pending means the app has not collected it yet (or the window lapsed first) and sent means it did — read that code out to a cardholder who missed it. Rows are kept after delivery and nothing prunes them. A row with no user is a prompt on a card QX has no local record of — it is never delivered to any app. Local database read only; nothing here calls the provider or consumes a prompt.

The customer message inbox the mobile app lists (user_messages). Three kinds share the table: type 1 — OTP is a one-time code QX wrote when a provider delivered an OTP for one of the owner's cards (a Wasabi merchant 3DS step-up, or a Tevau card-token OTP for Apple Pay / Google Pay wallet provisioning), type 2 — Admin is a message composed here, and type 3 — Card transaction is one QX wrote when one of the owner's cards was authorized for a purchase (a Wasabi or Tevau authorization). State is what the app sees: Show is listed by the app, Hide withdraws the message from it without deleting the row — that is how you retract a message a cardholder should no longer see. Title, content and state are editable on every kind, so a wrong OTP message can be corrected or pulled. The owner and the kind are not editable. Content is shown in full, which for an OTP row means the code itself. Nothing prunes this table, so old codes accumulate. Every create and edit is audited.

Finance — Card Program

Visa Cards

Every user who holds at least one Visa card, grouped by user. Expand a user to see their cards and, per card: Balance (a signed provider read), Card detail (opens the provider-hosted secure page after a password step-up — QX never sees the full number, expiry, or CVV), and Transactions (the vendor's paginated history, with per-transaction detail). View detail on a user row opens their own KYC submission — identity fields and uploaded images (audited; not offered for skip-KYC users, whose cards come from the pool, nor for submissions made before retention was enabled). The list itself is a local read; the per-card actions are the only provider calls.

Tevau Pool

Tevau cardholders created through the public /kyc page. An approved entry is stock: skip-KYC customers' card applications are issued under it, up to the per-type capacity in Card Program Settings — one entry can serve cards for several customers. The Cards column shows each issued card and the customer it belongs to. View detail opens what the applicant submitted — identity fields and the uploaded document images (audited; only for submissions made after retention was enabled). On sandbox, Simulate pass/fail submits Tevau's review decision for an applicant who completed their face scan; the verdict arrives back through the KYC webhook. Local reads only — the simulate action is the only provider call.

Wasabi Cardholder Pool

Wasabi cardholders created through the public /kyc/2 page. There is no liveness stage on this program: the submission itself is the KYC, and the verdict arrives on the card_holder webhook — a pass_audit entry is stock for skip-KYC issuance. View detail opens what the applicant submitted — identity fields plus the front, back, and selfie images (audited; only for submissions made after retention was enabled); the Export also carries the applicant email and document number. On local/staging, Simulate pass/fail writes the verdict directly (Wasabi ships no sandbox review trigger). Local reads only.

Wasabi Card Types

The stored Wasabi product catalogue — a snapshot, not a live mirror. Loading this page reads the local table only; the provider is called exactly once, when you press Fetch from provider. The rows marked usable are what the public /kyc page fans out over: one Wasabi cardholder is created per usable product on every applicant submission. Usable is the verdict of three gates. Two are the vendor's and are derived, never editable here — the vendor's own status must be a recognised live value and the product must require a cardholder (a product needing none has nothing for the KYC page to submit); the vendor's verbatim status is shown beside it, which is how an unrecognised status value is spotted. A product marked excluded is one Wasabi will only create a cardholder for with a third-party kycVerification reference (SUMSUB / DIDIT / MyInfo / Jumio / Shufti): the document-based public flow has no such reference, so those products are never submitted even while the vendor reports them online. That list is the vendor's own, from their cardholder-create documentation. A Fetch replaces the whole catalogue in one transaction: every returned product is upserted and every product the vendor no longer lists is deleted, all of it or none of it. Any failure — an unreachable provider, an empty list, a list with no usable product — leaves the stored rows exactly as they were, so the public page never loses its product list because the vendor blinked. The third gate is the Enabled switch, and it is the only thing on this page you can change: turning a product off takes it out of the fan-out, so no cardholder is created for it and the applicant's KYC documents are never submitted to the vendor under that product. It survives every later Fetch — a Fetch rewrites the vendor's fields and leaves your switches alone — and a product id the catalogue has never held before arrives off, so a newly listed vendor product is never put in front of applicants until someone here decides it is ready. It cannot be used on the last usable product, because a non-empty catalogue with nothing usable has no fallback and would fail every public submission. Turning a product off does not change a submission already in flight: each applicant's product set is frozen when they first submit. Everything else here is read-only: the catalogue is the vendor's truth, not a QX setting. While the catalogue is empty (no fetch has ever succeeded) the public page falls back to the single product configured in WasabiCard Settings.

Wasabi Accounts

The stored Wasabi funding-account catalogue — a snapshot, not a live mirror. Loading this page reads the local table only; the provider is called exactly once, when you press Fetch from provider, which walks every page of Wasabi's Accounts list read-only. No account is created, edited, or funded from here, and nothing on this page changes a card. A Fetch replaces the whole catalogue in one transaction: every returned account is upserted and every account the vendor no longer lists is deleted, all of it or none of it. Any failure — an unreachable provider, a decline, an empty list — leaves the stored rows exactly as they were, because an empty vendor answer is far likelier to be a credential or merchant-configuration problem than a merchant that genuinely holds no account. The catalogue's whole purpose is Set as default: it writes that account id into WasabiCard Settings — the account a shared-mode (BUDGET_CARD) card draws its funds from — through the same validated, audited save as that page's own Save button, so the id is picked from the vendor's list instead of typed. It applies only to future card creations; existing cards keep the account they were issued under, and the setting is accepted only while the configured product is shared-mode. Last updated is when the balances beside it were read: they are Wasabi's own figures at that instant and go stale immediately, so they are here to identify an account, never to account for one. The one account id with no row here is the empty one, which means Wasabi's default wallet — set that from the settings page itself.

Watches the shared-mode (BUDGET_CARD) pool. The rule: the configured funding account must be able to cover the largest cards. Each run ranks the shared cards by available balance, sums the top N (the Largest cards to cover setting, 3 by default), and sends a Telegram message when the account's available balance is strictly below that sum; an account holding exactly that much covers them and stays quiet. The Top up figure is the gap to that sum — the amount that makes the alert stop. Coverage (all cards' balances over the account) is still shown for context but no longer decides anything. Each scheduled run reads the funding account live first — never the stored catalogue on the Account Id page, which only moves when someone presses Fetch — then reads the provider's product list and walks the card list of every shared-mode product that draws on that account — cards issued under an earlier product count too, because they keep drawing on the same account (ranked here; the provider's list has no sort) — and appends one row to the history. Refresh now takes a measurement on demand and never sends a message, so checking is always safe. The bot token and chat id are environment-only (QX_TELEGRAM_BOT_TOKEN, QX_TELEGRAM_CHAT_ID) and are never shown or stored here; with neither set the runs are still recorded but nothing can be delivered. Coverage is left blank rather than zero whenever it could not be measured — no shared-mode product on the account, no funding account configured, no cards, or a failed provider read — and the reason is shown with the run. The history is append-only and never pruned, so it is always filtered and paged: the newest five runs are shown here, and Show all opens the full filtered range.

Watches the Wasabi main wallet — the one WALLET-type account in the provider's funding account list (the balance the Wasabi portal headlines as "Main account total balance"). The rule: each scheduled run reads the account list live and sends a Telegram message when the wallet's available balance is strictly below the Minimum balance; a wallet holding exactly the minimum stays quiet. While it stays below, every scheduled run sends a message. Refresh now takes a measurement on demand and never sends a message. The bot token and chat id are environment-only (QX_TELEGRAM_BOT_TOKEN, QX_TELEGRAM_CHAT_ID). A run that could not read the wallet — a failed provider read, no WALLET account, or more than one — is recorded with the reason and never alerts. The history is append-only and never pruned: the newest five runs are shown here, and Show all opens the full filtered range.

The remittance programme's policy, and the entire commercial boundary of the product on our side — Wasabi supplies none of it. Their corridor list bounds one transfer in the payout currency and says nothing about what a user may spend in U9 or what we charge on top. Enabled is the master switch and defaults to off: remittance sends real money to real bank accounts, so it stays dark until it is deliberately opened. U9 to USD rate converts the U9 a user spends into the USD that leaves our Wasabi balance; it is operator-set for the same reason the card programme's rate is — this leg has no market and no vendor endpoint, because Wasabi never sees U9. Min and Max bound one payout in U9 and sit alongside the corridor's own limits, which are the vendor's to enforce; a max of 0 means no ceiling. The fee is QX's own charge on top of Wasabi's, and the entered amount is fee-inclusive, matching the card top-up: 100 U9 at a 1 U9 flat fee spends 100 and remits 99 U9 worth. Quote tolerance is how far the vendor's real cost may exceed our quote before a payout is refused rather than absorbed — it exists because Wasabi has no quote endpoint, so what we are actually debited is knowable only after the transfer already exists; 0 absorbs nothing. Changes apply to future payouts only.

Every remittance payout attempt, QXipher and Abelian alike, newest first. Sender is the account email of the user who sent it and App the app that account belongs to; the QXipher/Abelian switch at the top narrows the list to one app.Status is QX's view of the user's money, not the provider's view of their processing, and the two deliberately differ. Pending and awaiting documents are in flight with the user's U9 locked — taken out of their spendable balance but not yet spent. Completed means the lock cleared and the U9 was genuinely spent; failed means it cleared and the U9 went back. Two states need people. Unknown is an ambiguous send (a timeout, or a response we could not verify) where the payout may well have executed, so the U9 stays locked rather than being guessed either way — guessing pays twice or steals. Vendor failed is the provider saying fail, which their own documentation warns may later be revised to success; the U9 stays locked, the provider's reason is in Detail, and the payout waits for a later success or for Release & fail.

Detail opens the whole payout: the corridor, the full money stack — what the customer spent, what we quoted, what the provider actually charged — the provider's own error text, and the reason any payout released by hand was released. Sent as shows the sender and receiver details exactly as they went to the provider (the payee registry is editable, so this, not the payee, is the dispute record; identity data, every read audited). Sync re-reads a locked payout from the provider and applies its state as the webhook would — for a webhook that never arrived. Release & fail is explained where it is used; it appears only on a payout still holding locked U9, and the provider is re-checked live first.

The payout routes Wasabi's Global Remittance product offers our merchant account, stored here so nothing downstream depends on the vendor being reachable. One row is one corridor: a payout currency reachable by a single transfer type and payout method, so the same currency appears several times when several routes reach it. Both halves of each enum are shown — the label an operator reads, and the id a transfer call has to send back. Status is the vendor's own online/offline flag: a stored corridor is not necessarily open for business. Supported is ours rather than the vendor's — QX's decision to sell that currency, which is a commercial and compliance question, not a question of whether Wasabi can reach it. A corridor reaches the app only when both hold: unticking one hides it from the currency list and makes every other remittance endpoint refuse it, so a client holding a cached currency cannot send there either. It saves the moment you tick it, it defaults to off for every corridor a Fetch has newly discovered, and a Fetch never undoes it. Fee rate is a percentage charged alongside the fixed fee; whether an FX spread sits on top of these is still an open question with the vendor. Wasabi min and Wasabi max bound what the receiver gets on one transfer, in the payout currency. Our min and Our max are ours too: an optional tighter limit inside Wasabi's range, saved when you leave the box, and left blank to use Wasabi's own. A Fetch never changes them, but if it narrows Wasabi's range so that one falls outside, Wasabi's limit is used instead (the row says so) until the range widens again or you change it. Year quota is an annual ceiling whose subject (merchant, sender, or receiver) the vendor has not yet confirmed, so nothing is enforced off it. The rate is what the corridor showed at fetch time and nothing more — Wasabi refreshes it constantly, so it is here to describe the corridor, never to price a payout. Page loads read only the stored rows. Wasabi is called by Fetch from provider, and by the scheduled fetch below when it is on. Both replace the catalogue all-or-nothing, and only when Wasabi answered successfully and every corridor in its list is complete, so a failed fetch leaves every stored row untouched. Every fetch, either kind, starts the interval again; the last attempt and its outcome are shown under the switch.

What a transfer on each corridor must actually carry. The set is corridor-specific and vendor-controlled, which is why a payout form has to be built from these rows rather than from a fixed schema — a corridor can begin demanding a field nobody has written code for. For says which party a field describes (common, sender, or receiver), so this is also where we read how much personal data one payout needs from each side. Options holds an enumerated select's allowed values, which is where a corridor's bank list arrives — there is no separate bank endpoint — so expand it to see every option with the id we would send back. Regex and the length bounds are the vendor's own validation and are narrower than they look: the name patterns reject apostrophes and accented characters, so stored identity data has to be normalised before it will pass. Rows follow the vendor's display order where it gave one. Fetch from provider walks every stored corridor, one call each, so it is slower than the Corridors fetch; a failure on any single corridor aborts the whole replacement rather than storing a half-walked catalogue. Fetch Corridors first — the stored corridors are the walk's work list. The same walk also runs on the scheduled fetch below when it is on (it starts off); every fetch, either kind, starts the interval again, and the last attempt and its outcome are shown under the switch.

KYC Submissions

One row per applicant sitting on the public /kyc page, rather than one row per provider record. A single submission fans out into several legs — the face-scan leg (shown as tevau) plus one product leg per usable Wasabi card type in the stored catalogue at the moment that applicant submitted — and this page groups them back together; the Tevau Pool and Wasabi Pool pages show the same legs one row at a time, tied to this row by their Session column. The card types a session is judged against are frozen when it first submits, so fetching the catalogue later never changes what an older session was asked to complete. Status is derived here and never stored: Approved requires a vendor verdict on every leg — the face scan approved and each expected card type at pass_audit — so a leg still awaiting review, or one the snapshot expects but that has no row at all (missing, e.g. the applicant abandoned the retry), keeps the session Pending; a rejected face scan or any rejected product leg makes it Rejected. Because the verdicts are live, a Status can still move after the fact. Declined reason is the vendor's own wording, and only a leg that actually declined fills it — a passing leg's narration (the provider sends “SUCCESS”) is not a reason, so an approved session shows none. View detail opens what was submitted across the whole sitting (identity fields and images, audited). The Export carries the same identity values plus the derived Status for every matching session and is audited: if the audit record cannot be written, the download is refused. Local reads only.

Country Profiles

Contact and billing values sent to Tevau when a skip-KYC customer applies for a card: the assigned pool cardholder's country selects the matching record here (the billing country sent to Tevau is the country code itself). One record per country code. A skip-KYC application whose pool cardholder's country has no record is rejected until one is created.

Physical Cards

The fulfillment queue for QX-shipped physical cards: approve a request, ship the card (courier + tracking unlock the customer's bind step), or reject it. Binding and activation happen from the customer's app; QX never stores the card number or activation code.

Visa Card Transactions

The canonical unified Visa activity table: U9-to-Visa top-ups with their immutable snapshots and lifecycle (Reconcile stays available for pending/unknown rows) and normalized external card activity (AUTH, SETTLE, VOID, REFUND, … stay separate rows) — including valid external events for cards QX has no local record of. Card creation is not listed here. Loading, filtering, and paging read the local database only; the only provider call is the explicit Reconcile action (a status query — never a new INCREASE). Abelian-app top-ups show one row each, however often the deposit was retried (pick All retry attempts to see every attempt). A top-up the provider refunded reads pending while the customer's U9 sits on the internal balance the Abelian app cannot show, and finance decides beside Details: Retry deposit runs the top-up again with that deposit (on the executor's next pass, under a fresh idempotency key), Release & refund sends the U9 back on-chain to the Abelian wallet the app recorded (Edit sends it elsewhere, audited as an override) and the row then reads failed. Each action locks the intent and re-checks it, so only one of them, or one auto-retry, can ever act on it. Top-ups refused before they ran are handled on Abelian Top-ups, failed card applications on Abelian Applications.

Abelian Top-ups

The deposit-funded top-up queue for the Abelian mobile app. Each row is one customer's declaration that their next U9 deposit funds a specific card; the executor matches a credited deposit to it and drives the top-up. Failed rows are the ones that need attention: the deposit was claimed but the top-up was definitively refused, so the U9 is sitting on the customer's internal balance. Retry deposit returns such a row to pending and releases its deposit claim so the executor can match it again on its next pass, under a fresh idempotency key — it makes no provider call itself. Release & refund sends the U9 back on-chain to the Abelian wallet the app recorded instead. Both lock the intent and re-check it, so they can never both act on it or duplicate a top-up that already succeeded. A top-up the provider refunded is handled the same way from its row on Visa Card Transactions.

Abelian Withdrawals

The payout queue for Abelian-app card withdrawals: once the card debit settles, the credited U9 is sent on-chain to the customer's wallet address recorded on the row. A row is never failed — an obstacle (its latest reason shows on the row) keeps it retrying every 15 seconds, so fixing the cause self-heals it. A row stuck for good is processed manually: send the U9 amount to the receiver address (click it to copy in full), confirm no automatic send is still in flight, then use Mark completed — that stops the retry. Sent rows are done.

Abelian Applications

Deposit-funded Wasabi card applications from the Abelian app: the customer sends the quoted U9 to their deposit address and the server applies automatically once it credits. A pending row retries every 15 seconds with its latest obstacle shown; an unfunded intent expires after 60 minutes with any credited U9 staying on the customer's balance. Mark completed closes a pending row an operator resolved by hand — confirm the executor has not already applied first. When an application failed, or its deposit landed but it never ran, the customer's U9 is on the internal balance the Abelian app cannot show: Retry deposit applies again with that deposit (not offered for one that never ran — the executor already retries it), Release & refund sends the U9 back on-chain to the Abelian wallet the app recorded. Both lock the intent and re-check it, so only one of them can act on it.

Abelian Remittances

Deposit-funded remittances from the Abelian app: the customer sends the quoted U9 to their deposit address and the server creates the ordinary payout once it credits — the payout then lives on the Payouts page under the reference shown here. A pending row retries every 15 seconds with its latest obstacle shown (usually the deposit shortfall so far); an unfunded intent expires after 60 minutes with any credited U9 staying on the customer's balance. Each deposit an intent counts is reserved to it, so the same deposit can never also fund a top-up or an application. Mark completed closes a pending row an operator resolved by hand — confirm no payout reference is shown first.

Live scheduling controls for the leader worker's background loops. Changes apply within five seconds without a restart. Turning a control Off stops future iterations only — it never interrupts a poll, sweep broadcast, or withdrawal already in progress. Sensitive configuration (endpoints, keys, signers, wallet mnemonics, gas) stays environment-only and is never shown or stored here.

Rents TRON energy from getblock.io before TRC20 sweeps and withdrawals instead of burning TRX (mainnet only). On any rental failure the transfer automatically falls back to burning TRX — funds always keep moving. Changes apply to the next transaction without a restart. The provider API key stays environment-only (QX_TRON_ENERGY_API_KEY) and is never shown or stored here; with no key configured these toggles have no effect.

Risk-based sweep routing: a sweep whose risk score is at or above the threshold goes to the dirty wallet; below it, to the clean wallet (MistTrack bands: Low 0–30, Moderate 31–70, High 71–90, Severe 91–100). The threshold is used live by the manual score entered on a Wallet Management sweep. The two toggles control the MistTrack integration (phase 2): calls are paid (~USD 1 each), so both ship off and the API key stays environment-only (QX_MISTTRACK_API_KEY). Routing requires both Risk Wallets to be configured; while it is on, unscored sweeps are skipped, never sent to the main wallet.

The fee reserve, in whole coins, that each self-funded native gas-coin sweep (ETH, BNB, TRX) leaves behind on the deposit address so its transfer can always pay its own gas/bandwidth. Sweeps move min(on-chain balance − reserve, the user's credited liability), so raising a reserve sweeps less and setting one too low makes the send fail on-chain. Every reserve must be greater than 0. Changes apply to the next sweep without a restart — the scheduler picks them up within five seconds. Token (ERC-20/TRC-20) sweeps are unaffected: they are funded by the gas station, not by this reserve.

Each dashboard role is a set of pages it may view, and on which of those it may edit (every add, save, approve, delete or other mutating action). A page held at View can additionally be granted individual actions; Edit grants them all. A page absent from a role is hidden from it and its API answers 403, so a newly added page reaches nobody but admin until it is ticked here. Changes apply to every holder on their next request — no new sign-in needed. admin always holds everything and cannot be edited.

Nothing open

Every tab is closed. Pick a page from the menu to open it in a new tab.

No pages assigned

Your role has no dashboard pages yet. Ask an administrator to grant some on the Roles page; they apply on your next page load.