Quote.Trade authenticated trading reference for agents

Quote.Trade is an AI-native crypto dark-pool DEX for human traders, trading bots, and AI agents. It combines streaming quotes, private execution, stablecoin settlement, long and short market exposure, and verifiable on-chain position and asset infrastructure. The official Quote.Trade REST/WebSocket APIs remain the canonical integration surface for programmatic access.

This reference covers authenticated account access, private data, immediate IOC/FOK execution, deposits, and agent withdrawals. Production API documentation and the live MCP tools/list response are the current sources of truth for field schemas.

Public verification model

Quote.Trade keeps orders and execution private while exposing the permissionless asset, balance, position, snapshot, and withdrawal infrastructure required for public verification.

• Ethereum V6 USDC/USDT assets and published balances reconcile with the corresponding completed Polygon PositionManager snapshot.
• XDC V6 USDC assets and published balances reconcile with the corresponding completed XDC PositionManager snapshot.
• PositionManager publishes user and asset mappings, quantity scales, position state, snapshotId, lastSyncedTime, syncFrequency, processedBatches, and totalBatches.
• Aggregate positive published withdrawal balances are compared with the physical stablecoin assets held in V6.
• Completed withdrawals can be traced from published eligibility and single-use entitlement consumption through the exact token payment to the registered wallet.

The Polygon and XDC position snapshots reconcile against the balances published in V6, while those balances are compared with the actual USDC/USDT held in the Ethereum and XDC funding contracts. That provides a mathematical verification of the published balances and their collateral coverage while keeping individual trades, counterparties, routing, and volume private.

V6 is new because it is the new contract version. V6 is non-upgradeable, so new contract logic requires a new deployment and migration instead of modifying the existing contract in place.

V6 operational-key resilience

V6 is direct and non-upgradeable and separates admin, guardian, asset-manager, balance-publisher, and withdrawal-execution roles. The core continues to enforce registered-wallet settlement, three qualifying observations at least 22 hours apart, the shared lowest-observation 1.5× cap, completed multipart publication, cooldown, replay protection, physical liquidity, conditional velocity limits, exact token accounting, non-reentrancy, timelocked composite changes, and emergency signer-epoch rotation around every authorized transaction.

A publisher action does not itself execute a withdrawal. A withdrawal action cannot select an arbitrary recipient or bypass the published-state and physical-asset checks. Administrative actions cannot replace the V6 implementation in place.

Endpoints

REST API base: https://app.quote.trade/api
WebSocket base: wss://app.quote.trade
Private stream: wss://app.quote.trade/ws/listenKey
MCP endpoint:   POST https://quote.trade/mcp
API docs:       https://doc.quote.trade
MCP discovery:  https://quote.trade/.well-known/mcp.json

Non-rehypothecation and collateral coverage

V6's non-rehypothecation controls are enforced in its non-upgradeable code. Supported ERC-20 collateral has no general-purpose lending, third-party spending-approval, or arbitrary-transfer path; payouts must pass the registered-wallet withdrawal controls. To verify backing, reconcile published positions with published funding balances and compare actual funding-contract assets with the sum of positive user balances at the same completed snapshot. Assets greater than those published liabilities establish a surplus at that snapshot.

See the verification reference for a worked example and the evidence required for a dated coverage result.

Authorization levels

API keys begin with read access. Trading and withdrawal permissions are enabled separately through the applicable account controls.

Credential and signing model

Private REST requests use:

X-MBX-APIKEY: <requestToken>
signature: <HMAC signature>
Content-Type: application/json

For documented signed POST and PUT requests, generate HMAC SHA-256 using the request secret as key and the exact minified JSON request body as the message. Keep the body byte-for-byte identical between signing and transmission.

Wallet keys and API secrets remain in the user's approved wallet, hardware signer, secret manager, or server-side integration. The agent can orchestrate a signature request and use the returned scoped credential while raw signing material remains in that approved environment.

Registration and login

Existing Quote.Trade API keys can connect without wallet login. Send X-MBX-APIKEY and X-MBX-APISECRET as headers to the official MCP endpoint and provide the account ID for live actions. The hosted MCP server receives the secret and signs downstream requests. Direct REST calls continue to use the documented HMAC signature header.

Wallet challenge

POST https://app.quote.trade/api/getChallenge

Request shape:

{"login":"0xUSER_LOGIN_WALLET"}

Workflow:

1. Request the challenge. 2. Sign the exact challenge string in the user's approved wallet environment. 3. Use registerUser for a new user or logon for an existing user. 4. Store requestToken, requestSecret, and account ID in the user's secret manager.

Hosted MCP sequence:

quote_trade_get_challenge
-> wallet challenge signature
-> quote_trade_logon

Deposit address

Use the current documented REST or MCP workflow to obtain the supported deposit address.

MCP tool:

quote_trade_get_deposit_address

The current discovery record lists USDC, USDT, and XUSDC for the deposit-address workflow. Use the live schema and returned network metadata.

Deposit sequence:

1. Retrieve the deposit address. 2. Display chain, token, token contract, address, and decimals. 3. Transfer from the user's wallet. 4. Record transaction hash and confirmation block. 5. Confirm account recognition through GET /api/account or private events.

Public market data

GET /api/status
GET /api/exchangeInfo
GET /api/getInstrumentPairs
GET /api/ticker?symbol=BTC
GET /api/depth?symbol=BTC&limit=100

Use exchangeInfo and getInstrumentPairs for current symbol status and quantity precision. Use the live liquidity WebSocket for continuously updating quantity-aware prices.

Account summary

GET https://app.quote.trade/api/account

Common response fields include:

Use current account state before each live order and withdrawal.

IOC/FOK order model

Quote.Trade orders are private bilateral immediate-or-cancel/fill-or-kill executions. The order carries the symbol, side, quantity, and executable price condition required for an immediate decision. Orders remain off the public order book.

The REST compatibility transport may represent the price condition with type=LIMIT. The economic behavior remains immediate IOC/FOK: the requested quantity fills within the permitted condition or returns a final non-fill outcome.

REST order endpoint

POST https://app.quote.trade/api/order

Documented fields:

Example request body:

{
  "liquidityOrder": 1,
  "account": 12345,
  "symbol": "BTC",
  "side": "BUY",
  "type": "LIMIT",
  "price": 89091.5,
  "quantity": 0.001,
  "disableLeverage": 1,
  "paymentCurrency": "USDT",
  "timestamp": 1788211200000
}

Order preview and approval

MCP sequence:

quote_trade_order_preview
-> display normalized order and active limits
-> obtain request-specific approval
-> quote_trade_place_order

Current approval values:

humanApproved=true
approvalText="APPROVE QUOTE.TRADE LIVE ORDER"

Server-side controls should include allowed symbols, maximum notional, leverage permission, quote age, price tolerance, account ID, and request deduplication.

Fill verification

Verify:

• status reflects the final business outcome;
• executedQty matches the requested quantity for a completed FOK fill;
• price, cumQuote, or the equivalent total amount matches the expected all-in result;
• orderId and any returned request identifier are recorded;
• the private ORDER_TRADE_UPDATE sequence reaches the same outcome;
• account and position state reflect the completed execution.

All-in execution price

The Quote.Trade quote includes the execution spread and size/liquidity adjustment. No separate trading commission is added after the quote. Funding is a separate holding-period amount.

The standard pricing target scheduled for the week of 2026-08-31 is approximately 13 basis points from midpoint per side. The live size-specific quote remains authoritative.

one-way cost from mid at 13 bps on $1,000,000 = $1,300
symmetric full-width round trip                 = $2,600

Same-size comparison method

Use a completed immediate taker execution on the comparison venue:

1. Synchronize the market timestamp. 2. Capture the Quote.Trade $1 million FOK quote. 3. Submit an immediate $1 million taker order on the comparison venue. 4. Record actual filled quantity, total amount paid or received, effective all-in execution price, taker fee, realized market impact, residual quantity, and completion time. 5. Compare funding over the same holding period.

A completed taker result is the execution benchmark. Displayed prices and modeled depth are pre-trade reference inputs.

Private WebSocket streams

wss://app.quote.trade/ws/listenKey

Use the authenticated account value and request token defined by current API documentation.

Account and position events

ACCOUNT_UPDATE events can include balance, position, mark, realized value, unrealized value, and asset metadata.

Order events

ORDER_TRADE_UPDATE events can include symbol, client order ID, side, order type, execution type, order status, quantity, price, last quantity, cumulative quantity, last price, order ID, execution ID, and sequence fields.

Risk events

RISK_UPDATE events can include buying power, leverage ratio, margin values, open-order exposure, position value, unrealized P&L, and update time.

Use heartbeat, bounded reconnect, sequence tracking, stale-data detection, and account-isolated subscriptions.

Agent withdrawal workflow

Quote.Trade MCP provides:

quote_trade_withdraw_preview
quote_trade_withdraw

The withdrawal path fixes the user's registered login wallet as the destination. The tool schema accepts the approved asset and amount.

Preview

Example preview arguments from the current tutorial:

{
  "symbol": "USDC",
  "quantity": "20000000",
  "quantity_scale": 6
}

A preview returns the human-readable amount, registered destination policy, and approval values for the live request while keeping willSend false.

Live withdrawal sequence

1. Read current account state and canWithdraw. 2. Preview the exact asset and quantity. 3. Display account, chain, token, scaled quantity, human-readable amount, registered destination, current eligible amount, and request ID. 4. Obtain request-specific approval. 5. Submit quote_trade_withdraw using the exact fields returned by live tools/list. 6. Preserve the request or withdrawal ID. 7. Verify the account update and exact token payment on-chain.

Current approval values:

humanApproved=true
approvalText="APPROVE QUOTE.TRADE LIVE WITHDRAW"

Contract-level payout controls

The V6 settlement path applies:

• registered-wallet recipient;
• supported token and composite mapping;
• unique withdrawal ID;
• exact unit conversion;
• three qualifying observations at least 22 hours apart;
• shared lowest-slot 1.5x cap;
• 10-minute post-publication cooldown;
• complete multipart publication state;
• completed composite membership state;
• physical token-liquidity check;
• conditional 3% hourly and 18% daily controls at or above the production $1 million threshold;
• current signer epoch and normal operating mode;
• exact token debit and recipient credit;
• non-reentrant checks-effects-interactions execution.

The seven-day proposal period applies to composite membership changes. Ordinary withdrawals use the payout sequence above.

Operational-key resilience

The direct non-upgradeable core and separated roles provide containment around operational actions:

• a balance publication becomes withdrawal-relevant only after the required completed observations and time cadence;
• the shared lowest-slot cap bounds availability across every member token in a composite;
• a withdrawal action settles to the registered wallet and remains subject to balance, cap, cooldown, completeness, liquidity, replay, rate, epoch, and exact-transfer checks;
• asset and composite changes remain subject to approved configuration and timelocked membership transitions;
• emergency mode freezes payout processing for three days, advances the signer epoch, refreshes role grants, raises the history floor, and requires fresh qualifying observations.

These constraints remain part of the execution path regardless of which authorized operational component submits the transaction.

Public reconciliation reference

Contract addresses

V6 funding core, Ethereum/XDC:
0xfb41c4f731a064fb3911d16d529be0c2958d5fc6

V6 views, Ethereum/XDC:
0x228d706e0651038dd8ec151e2f639b3e47ffecb6

PositionManager, Polygon/XDC:
0xf857aC7bed76B43c5457f56483803C4CebbD7eff

Completed-snapshot checks

• V6 core and views linkage is canonical.
• V6 balance publication is complete.
• PositionManager reports processedBatches == totalBatches.
• lastSyncedTime is current relative to syncFrequency.
• user, wallet, asset, symbol, scale, token, and composite mappings align.
• positions, balances, token transfers, and marks use a common timestamp.

User-level reconciliation

published account equity
= recognized deposits
- completed withdrawals
+ realized P&L
+ unrealized P&L at the matching mark snapshot
- funding paid
+ funding received
+ disclosed account adjustments

Use wallet, user ID, asset ID, quantity scale, composite ID, snapshot ID, and timestamp as the join keys.

Coverage formulas

Ethereum assets
= V6 Ethereum USDC + V6 Ethereum USDT

Ethereum obligation
= aggregate positive balances in the Ethereum USDC+USDT Grouped-Par composite

XDC assets
= V6 XDC USDC

XDC obligation
= aggregate positive balances in the XDC USDC Segregated composite

coverage surplus = assets - obligation
coverage ratio   = assets / obligation

PositionManager supplies user-position and completed-snapshot evidence. V6 supplies current physical assets and published withdrawal balances. ERC-20 transfers supply deposit and completed-withdrawal evidence.

Request outcome and retry policy

For each state-changing request:

1. Generate or preserve one stable request identifier supported by the live interface. 2. Persist the exact signed body, timestamp, and identifier. 3. Classify timeout or HTTP 5xx as UNKNOWN. 4. Query order, account, request, private-event, and chain state. 5. Continue with the original identifier while status is unresolved. 6. Record the final authoritative outcome.

Production checklist

• Live symbol and quantity precision loaded from current metadata.
• Account ID and credential scope verified.
• Allowed-symbol and maximum-notional limits active.
• Leverage permission explicit.
• Quote age and price tolerance active.
• Order or withdrawal preview displayed.
• Required approval captured.
• Request identifier persisted.
• Private stream connected and current.
• Final account, order, and chain result verified.