Field-level execution audit | 11 July 2026
Crypto Signal to Exchange Order Translation: 5-Venue USDT Perpetuals Audit
Compare how one signal maps to 12 order fields across five USDT perpetual venues, with current documentation conflicts kept visible.
This is an API-contract comparison, not an exchange recommendation, eligibility decision, UI guide, executable payload, or proof that an order would be accepted or filled.
No account, API key, order, cancellation, position change, or funds movement was used.
- Venues
- 5
- Field-level facts
- 60
- First-party sources
- 34
- Thin child routes retired
- 600
Research owner: CryptoSignalsReview. Dataset ID: csr-crypto-signal-exchange-order-translation-2026-07-11.
Translate the signal before touching an order ticket
A provider signal can describe direction and price intent while still omitting the exchange fields that determine whether an order opens, closes, reduces, triggers, or sizes the intended exposure. The safest sequence is mechanical:
- 1
Normalize the signal
Separate pair, direction, sizing intent, entries, targets, stop, leverage, and margin intent before choosing venue fields.
- 2
Select the product
Resolve the exact perpetual product and symbol before translating price or quantity.
- 3
Translate 12 fields
Map side, mode, quantity, orders, triggers, exits, and partial-close behavior without borrowing another endpoint's enums.
- 4
Revalidate at runtime
Refresh instrument limits and account eligibility immediately before any private validation or order construction.
The normalized signal is an editorial bridge, not an API payload
The comparison starts with fields documented by Cornix signal-posting and lifecycle guidance. Normalizing them makes the translation problem comparable without pretending that Cornix publishes one universal exchange request.
venues
One or more named execution venues.
A venue label does not establish product availability or account eligibility.symbol
A base and quote pair such as BTC/USDT.
The pair must be transformed into each venue's product-specific instrument identifier.signalType
Regular entry, entry zone, breakout above, or breakout below.
A signal condition is not automatically an exchange order type.direction
Long or short exposure intent.
Open and close side fields also depend on the account's position mode.leverage
Cross or isolated margin intent plus a leverage multiple.
The venue and account can reject or cap the requested setting.sizing
Portfolio percentage, risk percentage, or another sizing intent.
A percentage is not an exchange quantity. Balance, price, contract value, leverage, minimums, and rounding are still required.entries
One or more entry prices or an entry zone, optionally with allocation ratios.
The translation must choose supported order and time-in-force behavior without inventing missing instructions.takeProfits
One or more take-profit prices, optionally with allocation ratios.
Targets must be converted into venue-specific attached or separate close orders and valid quantities.stopLoss
One stop-loss price.
Trigger source, execution price, close size, and reduce semantics remain venue-specific.trailing
Optional trailing behavior and activation condition.
Trailing semantics are not normalized here because the five endpoints do not expose one interchangeable contract.trackingStart
The signal lifecycle timestamp or tracking boundary.
A tracking timestamp does not prove order submission, fill time, or realized return.One matrix shows where the five contracts diverge
Read across a field before reading down a venue. A current conflict is not a failure of the audit; it is a warning that the public contracts cannot be safely collapsed into one generic instruction.
| Required field | Binance BTCUSDT | Bybit BTCUSDT | OKX BTC-USDT-SWAP | Bitget BTCUSDT | MEXC BTC_USDT |
|---|---|---|---|---|---|
| Symbol | Confirmed current Use the concatenated futures symbol, for example symbol=BTCUSDT. Validate it against USD-M exchangeInfo before constructing an order. | Confirmed current Use the uppercase concatenated symbol BTCUSDT. Instrument rules must be refreshed from instruments-info before validation. | Confirmed current Use the hyphenated product identifier BTC-USDT-SWAP. The current record reports a linear contract settled in USDT and state=live. | Confirmed current Use the concatenated symbol BTCUSDT. The current UTA instrument record reports type=perpetual and status=online. | Confirmed current Use the underscore-form contract symbol BTC_USDT. The current public response identifies BTC_USDT PERPETUAL, settled in USDT. |
| Product selector | Confirmed current The USD-M Futures REST route selects the derivatives product family; there is no separate productType field on New Order. | Confirmed current category=linear selects the USDT or USDC linear contract family for the V5 order endpoint. | Confirmed current The instrument is classified as instType=SWAP. Place Order uses instId plus the account and trading-mode fields rather than a separate productType parameter. | Confirmed current category=USDT-FUTURES selects the UTA product family. Do not combine this v3 payload with Classic v2 productType or tradeSide fields. | Confirmed current The futures API route and contract symbol select the product. Current metadata reports futureType=1, while the order request itself does not use a generic productType field. |
| Quantity unit | Documentation only New Order uses quantity. Precision and minimums must be read from the symbol filters in exchangeInfo; the dated runtime request was location-blocked, so no current BTCUSDT limits are asserted here. | Documentation only qty is the order quantity for perpetuals and futures. Its minimum, step, and maximum must come from current instrument metadata; no current BTCUSDT values are asserted because the runtime request was blocked. | Confirmed current sz is contracts for futures and swaps. The dated BTC-USDT-SWAP snapshot reports ctVal=0.01 BTC, lotSz=0.01 contracts, and minSz=0.01 contracts. | Current conflict UTA qty is base coin for USDT and USDC futures. The current BTCUSDT record reports quantityMultiplier=0.0001 BTC, minOrderQty=0.0001 BTC, and minOrderAmount=5 USDT, while some place-order prose uses different field names; requery the instrument schema. | Confirmed current vol is contracts. The dated BTC_USDT response reports contractSize=0.0001 BTC, volUnit=1 contract, and minVol=1 contract. |
| Side mapping | Confirmed current side is BUY or SELL. In one-way mode, BUY opens or reduces according to existing exposure; in hedge mode positionSide disambiguates LONG and SHORT legs. | Confirmed current side is Buy or Sell. positionIdx is needed to distinguish one-way from hedge legs and therefore changes how an intended close is represented. | Confirmed current Net mode uses buy or sell with posSide=net or omitted. Long/short mode maps open long to buy+long, open short to sell+short, close long to sell+long, and close short to buy+short. | Confirmed current One-way mode uses buy or sell, with reduceOnly for closes. Hedge mode uses side plus posSide: buy+long, sell+short, sell+long, and buy+short for the four open and close actions. | Confirmed current side=1 opens long, 2 closes short, 3 opens short, and 4 closes long. These are not interchangeable with the buy/sell strings used by the other four venues. |
| Position mode | Confirmed current positionSide defaults to BOTH in one-way mode. Hedge mode requires LONG or SHORT; the signal direction alone does not reveal the account mode. | Confirmed current positionIdx=0 represents one-way mode, 1 the hedge-mode buy side, and 2 the hedge-mode sell side. | Confirmed current Account posMode is net_mode or long_short_mode. posSide is required in long/short mode; portfolio margin supports net mode only. | Confirmed current holdMode is one_way_mode or hedge_mode. posSide=long or short is required in hedge mode. | Confirmed current positionMode=1 is hedge and 2 is one-way. Place Order documents hedge as its default, but the account's actual mode must be read rather than inferred from the signal. |
| Margin mode | Confirmed current New Order does not contain a cross-or-isolated selector. Margin type is managed separately per symbol with ISOLATED or CROSSED, so a signal's margin label cannot be copied into the order payload. | Not found The V5 Place Order request does not expose a cross-or-isolated field. Margin mode is account or position configuration outside this payload. | Confirmed current tdMode=cross or isolated is selected on the order. Actual availability still depends on account mode and current venue rules. | Confirmed current marginMode is crossed or isolated and defaults to crossed according to the UTA place-order documentation. The field was added to that endpoint in the 2026-05-19 change log. | Confirmed current openType=1 selects isolated and 2 cross. Leverage is supplied when opening and remains subject to account and instrument controls. |
| Entry orders | Current conflict Use the normal order route for current LIMIT or MARKET entries. Although parts of the New Order schema still display conditional enums, Binance's controlling change log says STOP-family and trailing orders migrated to /fapi/v1/algoOrder on 2025-12-09 and are rejected on /fapi/v1/order with error -4120. | Confirmed current orderType is Limit or Market. triggerPrice plus triggerDirection converts an order into a conditional order; limit orders additionally require price. | Confirmed current ordType supports market, limit, post_only, fok, ioc, and optimal_limit_ioc for this comparison. Trigger and trailing behavior use the separate algo-order route. | Confirmed current orderType is market or limit. Conditional entries use the separate strategy-order contract rather than borrowing Classic plan-order fields. | Confirmed current type=1 limit, 2 post-only, 3 IOC, 4 FOK, and 5 market. Plan orders support the same five execution types after their trigger condition. |
| Time in force | Confirmed current timeInForce supports GTC, IOC, FOK, GTX, GTD, and permissioned RPI. A normalized signal does not specify which one to choose. | Confirmed current timeInForce supports GTC, IOC, FOK, PostOnly, and permissioned RPI. A signal entry does not select among them. | Confirmed current There is no separate TIF field on Place Order. IOC, FOK, and post-only behavior is encoded in ordType; no GTC enum is exposed there. | Confirmed current timeInForce supports gtc, post_only, fok, and ioc; rpi requires market-maker permission. Limit orders default to gtc if omitted. | Confirmed current There is no standalone timeInForce field. Post-only, IOC, and FOK behavior is encoded in type; the reviewed page does not label an ordinary limit as GTC. |
| Take profit / stop loss | Confirmed current Create separate conditional algo orders for STOP, STOP_MARKET, TAKE_PROFIT, or TAKE_PROFIT_MARKET exits. No bracket or OCO pairing field is documented. closePosition is available only for STOP_MARKET or TAKE_PROFIT_MARKET and carries mode-specific restrictions. | Confirmed current takeProfit and stopLoss can be supplied with tpOrderType, slOrderType, and tpslMode. Full and Partial modes have different price and sizing constraints. | Confirmed current attachAlgoOrds can add TP and SL instructions that activate after the parent fills. Split TPs use per-attachment sz; up to 10 TP attachments and at most one SL are documented. | Confirmed current Direct order fields include takeProfit, stopLoss, trigger-source fields, order-type fields, and optional limit prices. Separate strategy orders expose full and partial TP/SL modes. | Confirmed current Entry and plan orders expose takeProfitPrice, stopLossPrice, profitTrend, lossTrend, and priceProtect. A separate position TP/SL route controls partial or whole-position exits. |
| Trigger price source | Confirmed current On the conditional algo route, workingType selects MARK_PRICE or CONTRACT_PRICE; no INDEX_PRICE value is documented. priceProtect can add the documented trigger-protection constraint. | Confirmed current triggerBy, tpTriggerBy, and slTriggerBy select LastPrice, IndexPrice, or MarkPrice where documented. triggerDirection states whether the market must rise to or fall to the trigger. | Current conflict Attached TP/SL orders document last, index, or mark trigger sources, while initial standalone algo-order support is endpoint-specific. Do not transfer a trigger-source enum between endpoints without checking that route. | Confirmed current tpTriggerBy and slTriggerBy accept market or mark, with market documented as default. No index-price option is documented on the reviewed UTA route. | Confirmed current triggerType=1 means greater-than-or-equal and 2 less-than-or-equal. trend, profitTrend, and lossTrend select latest, fair, or index price with values 1, 2, and 3. |
| Reduce-only / close | Current conflict reduceOnly is supported in one-way mode but cannot be sent in Hedge Mode. closePosition has separate constraints and must not be treated as a universal substitute. | Confirmed current reduceOnly marks a reducing order. closeOnTrigger adds a close safeguard for conditional orders; reduce-only orders cannot carry take-profit and stop-loss fields in the same request. | Confirmed current reduceOnly is a Boolean for net-mode futures and swaps. Long/short mode closing orders are inherently reducing; oversized net reduce-only size is documented as rejected rather than automatically trimmed. | Confirmed current reduceOnly=yes or no controls one-way closes. Hedge-mode close direction is represented with opposite side plus the retained posSide. | Confirmed current reduceOnly applies in one-way mode. Hedge closes instead use side=2 or side=4, a close volume, and normally a positionId. A platform-level Close Signal action must not be mapped blindly to close_all. |
| Partial close | Documentation only A partial close requires an explicitly calculated close quantity that passes the current symbol filters. The signal target ratio is not itself an exchange quantity. | Confirmed current Use an explicitly calculated qty for the close. Partial TP/SL mode can create sized partial exits, but target ratios still require balance-aware conversion and valid instrument rounding. | Confirmed current A normal partial close uses sz in contracts. Split attached TP sizes must add up to the parent size. Algo closeFraction accepts only 1, which represents a full close rather than arbitrary fractions. | Confirmed current A normal partial close uses an explicit qty in base coin. The strategy route supports tpslMode=partial with required qty; direct parent TP/SL fields do not expose a separate partial quantity. | Confirmed current A normal partial close uses vol in contracts. Position TP/SL uses volType=1 for partial and 2 for whole-position behavior, with separate takeProfitVol and stopLossVol fields where applicable. |
Runtime snapshots were captured only from public endpoints. Binance and Bybit location blocks are reported as blocked observations, not global outages.
Venue evidence records keep every parameter and boundary visible
Binance: USD-M Futures perpetualBTCUSDT | documentation: Confirmed current | runtime: Runtime blockedReview 12 fields
Research route: Public developer documentation was readable; the public BTCUSDT exchangeInfo request returned HTTP 451 from the research location.
Decision boundary: No current BTCUSDT filter values were captured because the public endpoint returned 451 from this location. No regional or account eligibility conclusion follows from that response.
Symbol
Confirmed currentUse the concatenated futures symbol, for example symbol=BTCUSDT. Validate it against USD-M exchangeInfo before constructing an order.
Fields: symbol
Sources: Binance USD-M Futures New Order; Binance USD-M Futures Exchange Information
Product selector
Confirmed currentThe USD-M Futures REST route selects the derivatives product family; there is no separate productType field on New Order.
Fields: /fapi/v1/order
Sources: Binance USD-M Futures New Order
Quantity unit
Documentation onlyNew Order uses quantity. Precision and minimums must be read from the symbol filters in exchangeInfo; the dated runtime request was location-blocked, so no current BTCUSDT limits are asserted here.
Fields: quantity, filters, LOT_SIZE, MARKET_LOT_SIZE, MIN_NOTIONAL
Sources: Binance USD-M Futures New Order; Binance USD-M Futures Exchange Information; Binance BTCUSDT USD-M Exchange Information Runtime Request
Side mapping
Confirmed currentside is BUY or SELL. In one-way mode, BUY opens or reduces according to existing exposure; in hedge mode positionSide disambiguates LONG and SHORT legs.
Fields: side, positionSide
Sources: Binance USD-M Futures New Order
Position mode
Confirmed currentpositionSide defaults to BOTH in one-way mode. Hedge mode requires LONG or SHORT; the signal direction alone does not reveal the account mode.
Fields: positionSide, BOTH, LONG, SHORT
Sources: Binance USD-M Futures New Order
Margin mode
Confirmed currentNew Order does not contain a cross-or-isolated selector. Margin type is managed separately per symbol with ISOLATED or CROSSED, so a signal's margin label cannot be copied into the order payload.
Fields: marginType, ISOLATED, CROSSED
Entry orders
Current conflictUse the normal order route for current LIMIT or MARKET entries. Although parts of the New Order schema still display conditional enums, Binance's controlling change log says STOP-family and trailing orders migrated to /fapi/v1/algoOrder on 2025-12-09 and are rejected on /fapi/v1/order with error -4120.
Fields: /fapi/v1/order, /fapi/v1/algoOrder, algoType, CONDITIONAL, type, LIMIT, MARKET, STOP, STOP_MARKET, TAKE_PROFIT, TAKE_PROFIT_MARKET, TRAILING_STOP_MARKET
Sources: Binance USD-M Futures New Order; Binance USD-M Futures Trade REST API; Binance USD-M Futures Change Log
Time in force
Confirmed currenttimeInForce supports GTC, IOC, FOK, GTX, GTD, and permissioned RPI. A normalized signal does not specify which one to choose.
Fields: timeInForce, GTC, IOC, FOK, GTX, GTD, RPI
Sources: Binance USD-M Futures New Order
Take profit / stop loss
Confirmed currentCreate separate conditional algo orders for STOP, STOP_MARKET, TAKE_PROFIT, or TAKE_PROFIT_MARKET exits. No bracket or OCO pairing field is documented. closePosition is available only for STOP_MARKET or TAKE_PROFIT_MARKET and carries mode-specific restrictions.
Fields: /fapi/v1/algoOrder, algoType, type, triggerPrice, price, quantity, closePosition
Sources: Binance USD-M Futures Trade REST API; Binance USD-M Futures Change Log
Trigger price source
Confirmed currentOn the conditional algo route, workingType selects MARK_PRICE or CONTRACT_PRICE; no INDEX_PRICE value is documented. priceProtect can add the documented trigger-protection constraint.
Fields: triggerPrice, workingType, MARK_PRICE, CONTRACT_PRICE, priceProtect
Sources: Binance USD-M Futures Trade REST API; Binance USD-M Futures Change Log
Reduce-only / close
Current conflictreduceOnly is supported in one-way mode but cannot be sent in Hedge Mode. closePosition has separate constraints and must not be treated as a universal substitute.
Fields: reduceOnly, closePosition
Sources: Binance USD-M Futures New Order
Partial close
Documentation onlyA partial close requires an explicitly calculated close quantity that passes the current symbol filters. The signal target ratio is not itself an exchange quantity.
Fields: quantity, reduceOnly
Sources: Binance USD-M Futures New Order; Binance USD-M Futures Exchange Information
Bybit: Linear perpetualBTCUSDT | documentation: Confirmed current | runtime: Runtime blockedReview 12 fields
Research route: Public developer documentation was readable; the public BTCUSDT instruments request returned HTTP 403 from the research location.
Decision boundary: The public instruments request returned 403 from this research location. That does not establish a global API outage, instrument delisting, or account eligibility.
Symbol
Confirmed currentUse the uppercase concatenated symbol BTCUSDT. Instrument rules must be refreshed from instruments-info before validation.
Fields: symbol
Sources: Bybit V5 Place Order; Bybit V5 Get Instruments Info
Product selector
Confirmed currentcategory=linear selects the USDT or USDC linear contract family for the V5 order endpoint.
Fields: category, linear
Sources: Bybit V5 Place Order
Quantity unit
Documentation onlyqty is the order quantity for perpetuals and futures. Its minimum, step, and maximum must come from current instrument metadata; no current BTCUSDT values are asserted because the runtime request was blocked.
Fields: qty, lotSizeFilter
Sources: Bybit V5 Place Order; Bybit V5 Get Instruments Info; Bybit BTCUSDT Linear Instrument Runtime Request
Side mapping
Confirmed currentside is Buy or Sell. positionIdx is needed to distinguish one-way from hedge legs and therefore changes how an intended close is represented.
Fields: side, Buy, Sell, positionIdx
Sources: Bybit V5 Place Order
Position mode
Confirmed currentpositionIdx=0 represents one-way mode, 1 the hedge-mode buy side, and 2 the hedge-mode sell side.
Fields: positionIdx, 0, 1, 2
Sources: Bybit V5 Place Order; Bybit V5 Switch Position Mode
Margin mode
Not foundThe V5 Place Order request does not expose a cross-or-isolated field. Margin mode is account or position configuration outside this payload.
Fields: No order-payload parameter.
Sources: Bybit V5 Place Order
Entry orders
Confirmed currentorderType is Limit or Market. triggerPrice plus triggerDirection converts an order into a conditional order; limit orders additionally require price.
Fields: orderType, Limit, Market, price, triggerPrice, triggerDirection
Sources: Bybit V5 Place Order
Time in force
Confirmed currenttimeInForce supports GTC, IOC, FOK, PostOnly, and permissioned RPI. A signal entry does not select among them.
Fields: timeInForce, GTC, IOC, FOK, PostOnly, RPI
Sources: Bybit V5 Place Order
Take profit / stop loss
Confirmed currenttakeProfit and stopLoss can be supplied with tpOrderType, slOrderType, and tpslMode. Full and Partial modes have different price and sizing constraints.
Fields: takeProfit, stopLoss, tpOrderType, slOrderType, tpslMode
Sources: Bybit V5 Place Order
Trigger price source
Confirmed currenttriggerBy, tpTriggerBy, and slTriggerBy select LastPrice, IndexPrice, or MarkPrice where documented. triggerDirection states whether the market must rise to or fall to the trigger.
Fields: triggerBy, tpTriggerBy, slTriggerBy, triggerDirection
Sources: Bybit V5 Place Order
Reduce-only / close
Confirmed currentreduceOnly marks a reducing order. closeOnTrigger adds a close safeguard for conditional orders; reduce-only orders cannot carry take-profit and stop-loss fields in the same request.
Fields: reduceOnly, closeOnTrigger
Sources: Bybit V5 Place Order
Partial close
Confirmed currentUse an explicitly calculated qty for the close. Partial TP/SL mode can create sized partial exits, but target ratios still require balance-aware conversion and valid instrument rounding.
Fields: qty, tpslMode, Partial, tpSize, slSize
Sources: Bybit V5 Place Order; Bybit V5 Get Instruments Info
OKX: Linear USDT-margined perpetual swapBTC-USDT-SWAP | documentation: Confirmed current | runtime: Confirmed currentReview 12 fields
Research route: The public documentation and BTC-USDT-SWAP instruments endpoint returned HTTP 200 from the research location.
Decision boundary: The instrument snapshot is dated and must be refreshed before validation. It does not establish account permissions, price-band acceptance, available balance, fill behavior, fees, funding, or liquidation outcome.
Symbol
Confirmed currentUse the hyphenated product identifier BTC-USDT-SWAP. The current record reports a linear contract settled in USDT and state=live.
Fields: instId
Sources: OKX API V5 Place Order; OKX BTC-USDT-SWAP Runtime Instrument Snapshot
Product selector
Confirmed currentThe instrument is classified as instType=SWAP. Place Order uses instId plus the account and trading-mode fields rather than a separate productType parameter.
Fields: instType, SWAP, instId
Quantity unit
Confirmed currentsz is contracts for futures and swaps. The dated BTC-USDT-SWAP snapshot reports ctVal=0.01 BTC, lotSz=0.01 contracts, and minSz=0.01 contracts.
Fields: sz, ctVal, ctValCcy, lotSz, minSz
Sources: OKX API V5 Place Order; OKX API V5 Get Instruments; OKX BTC-USDT-SWAP Runtime Instrument Snapshot
Side mapping
Confirmed currentNet mode uses buy or sell with posSide=net or omitted. Long/short mode maps open long to buy+long, open short to sell+short, close long to sell+long, and close short to buy+short.
Fields: side, posSide
Sources: OKX API V5 Place Order
Position mode
Confirmed currentAccount posMode is net_mode or long_short_mode. posSide is required in long/short mode; portfolio margin supports net mode only.
Fields: posMode, net_mode, long_short_mode, posSide
Sources: OKX API V5 Set Position Mode; OKX API V5 Place Order
Margin mode
Confirmed currenttdMode=cross or isolated is selected on the order. Actual availability still depends on account mode and current venue rules.
Fields: tdMode, cross, isolated
Sources: OKX API V5 Place Order
Entry orders
Confirmed currentordType supports market, limit, post_only, fok, ioc, and optimal_limit_ioc for this comparison. Trigger and trailing behavior use the separate algo-order route.
Fields: ordType, market, limit, post_only, fok, ioc, optimal_limit_ioc
Sources: OKX API V5 Place Order; OKX API V5 Place Algo Order
Time in force
Confirmed currentThere is no separate TIF field on Place Order. IOC, FOK, and post-only behavior is encoded in ordType; no GTC enum is exposed there.
Fields: ordType, ioc, fok, post_only
Sources: OKX API V5 Place Order
Take profit / stop loss
Confirmed currentattachAlgoOrds can add TP and SL instructions that activate after the parent fills. Split TPs use per-attachment sz; up to 10 TP attachments and at most one SL are documented.
Fields: attachAlgoOrds, tpTriggerPx, tpOrdPx, slTriggerPx, slOrdPx, sz
Sources: OKX API V5 Place Order; OKX API V5 Place Algo Order
Trigger price source
Current conflictAttached TP/SL orders document last, index, or mark trigger sources, while initial standalone algo-order support is endpoint-specific. Do not transfer a trigger-source enum between endpoints without checking that route.
Fields: tpTriggerPxType, slTriggerPxType, last, index, mark
Sources: OKX API V5 Place Order; OKX API V5 Place Algo Order
Reduce-only / close
Confirmed currentreduceOnly is a Boolean for net-mode futures and swaps. Long/short mode closing orders are inherently reducing; oversized net reduce-only size is documented as rejected rather than automatically trimmed.
Fields: reduceOnly, posSide, sz
Sources: OKX API V5 Place Order
Partial close
Confirmed currentA normal partial close uses sz in contracts. Split attached TP sizes must add up to the parent size. Algo closeFraction accepts only 1, which represents a full close rather than arbitrary fractions.
Fields: sz, attachAlgoOrds, closeFraction
Sources: OKX API V5 Place Order; OKX API V5 Place Algo Order
Bitget: UTA v3 USDT Futures perpetualBTCUSDT | documentation: Current conflict | runtime: Confirmed currentReview 12 fields
Research route: The UTA documentation and public BTCUSDT instrument endpoint returned HTTP 200 from the research location. Classic v2 remains a separate, incompatible parameter contract.
Decision boundary: Bitget UTA v3 and Classic v2 field names and hedge semantics are not interchangeable. The public docs also contain a quantity-field naming inconsistency, so current instrument metadata controls validation.
Symbol
Confirmed currentUse the concatenated symbol BTCUSDT. The current UTA instrument record reports type=perpetual and status=online.
Fields: symbol
Sources: Bitget UTA V3 Place Order; Bitget UTA BTCUSDT Runtime Instrument Snapshot
Product selector
Confirmed currentcategory=USDT-FUTURES selects the UTA product family. Do not combine this v3 payload with Classic v2 productType or tradeSide fields.
Fields: category, USDT-FUTURES
Sources: Bitget UTA V3 Place Order; Bitget Classic V2 Futures Place Order
Quantity unit
Current conflictUTA qty is base coin for USDT and USDC futures. The current BTCUSDT record reports quantityMultiplier=0.0001 BTC, minOrderQty=0.0001 BTC, and minOrderAmount=5 USDT, while some place-order prose uses different field names; requery the instrument schema.
Fields: qty, quantityMultiplier, minOrderQty, minOrderAmount
Sources: Bitget UTA V3 Place Order; Bitget UTA V3 Get Instruments; Bitget UTA BTCUSDT Runtime Instrument Snapshot
Side mapping
Confirmed currentOne-way mode uses buy or sell, with reduceOnly for closes. Hedge mode uses side plus posSide: buy+long, sell+short, sell+long, and buy+short for the four open and close actions.
Fields: side, posSide, reduceOnly
Sources: Bitget UTA V3 Place Order
Position mode
Confirmed currentholdMode is one_way_mode or hedge_mode. posSide=long or short is required in hedge mode.
Fields: holdMode, one_way_mode, hedge_mode, posSide
Sources: Bitget UTA V3 Set Holding Mode; Bitget UTA V3 Place Order
Margin mode
Confirmed currentmarginMode is crossed or isolated and defaults to crossed according to the UTA place-order documentation. The field was added to that endpoint in the 2026-05-19 change log.
Fields: marginMode, crossed, isolated
Sources: Bitget UTA V3 Place Order; Bitget UTA API Change Log
Entry orders
Confirmed currentorderType is market or limit. Conditional entries use the separate strategy-order contract rather than borrowing Classic plan-order fields.
Fields: orderType, market, limit
Sources: Bitget UTA V3 Place Order; Bitget UTA V3 Place Strategy Order
Time in force
Confirmed currenttimeInForce supports gtc, post_only, fok, and ioc; rpi requires market-maker permission. Limit orders default to gtc if omitted.
Fields: timeInForce, gtc, post_only, fok, ioc, rpi
Sources: Bitget UTA V3 Place Order
Take profit / stop loss
Confirmed currentDirect order fields include takeProfit, stopLoss, trigger-source fields, order-type fields, and optional limit prices. Separate strategy orders expose full and partial TP/SL modes.
Fields: takeProfit, stopLoss, tpTriggerBy, slTriggerBy, tpOrderType, slOrderType, tpLimitPrice, slLimitPrice, tpslMode
Sources: Bitget UTA V3 Place Order; Bitget UTA V3 Place Strategy Order
Trigger price source
Confirmed currenttpTriggerBy and slTriggerBy accept market or mark, with market documented as default. No index-price option is documented on the reviewed UTA route.
Fields: tpTriggerBy, slTriggerBy, market, mark
Sources: Bitget UTA V3 Place Order
Reduce-only / close
Confirmed currentreduceOnly=yes or no controls one-way closes. Hedge-mode close direction is represented with opposite side plus the retained posSide.
Fields: reduceOnly, yes, no, side, posSide
Sources: Bitget UTA V3 Place Order
Partial close
Confirmed currentA normal partial close uses an explicit qty in base coin. The strategy route supports tpslMode=partial with required qty; direct parent TP/SL fields do not expose a separate partial quantity.
Fields: qty, tpslMode, partial
Sources: Bitget UTA V3 Place Order; Bitget UTA V3 Place Strategy Order
MEXC: USDT perpetual futuresBTC_USDT | documentation: Confirmed current | runtime: Confirmed currentReview 12 fields
Research route: Current futures API documentation and the public BTC_USDT contract endpoint were readable. Private futures API access remains subject to application, KYC, region, permissions, and risk controls.
Decision boundary: MEXC's current change log says futures API trading reopened on 2026-03-31 and the current contract record says apiAllowed=true, superseding legacy maintenance labels. That still does not prove that a particular retail, regional, or institutional account can obtain private trading access.
Symbol
Confirmed currentUse the underscore-form contract symbol BTC_USDT. The current public response identifies BTC_USDT PERPETUAL, settled in USDT.
Fields: symbol
Sources: MEXC Futures Place Order; MEXC BTC_USDT Runtime Contract Snapshot
Product selector
Confirmed currentThe futures API route and contract symbol select the product. Current metadata reports futureType=1, while the order request itself does not use a generic productType field.
Fields: futureType, symbol
Sources: MEXC Futures Get Contract Info; MEXC Futures Place Order; MEXC BTC_USDT Runtime Contract Snapshot
Quantity unit
Confirmed currentvol is contracts. The dated BTC_USDT response reports contractSize=0.0001 BTC, volUnit=1 contract, and minVol=1 contract.
Fields: vol, contractSize, volUnit, minVol
Sources: MEXC Futures Place Order; MEXC Futures Get Contract Info; MEXC BTC_USDT Runtime Contract Snapshot
Side mapping
Confirmed currentside=1 opens long, 2 closes short, 3 opens short, and 4 closes long. These are not interchangeable with the buy/sell strings used by the other four venues.
Fields: side, 1, 2, 3, 4
Sources: MEXC Futures Place Order
Position mode
Confirmed currentpositionMode=1 is hedge and 2 is one-way. Place Order documents hedge as its default, but the account's actual mode must be read rather than inferred from the signal.
Fields: positionMode, 1, 2
Sources: MEXC Futures Place Order
Margin mode
Confirmed currentopenType=1 selects isolated and 2 cross. Leverage is supplied when opening and remains subject to account and instrument controls.
Fields: openType, 1, 2, leverage
Sources: MEXC Futures Place Order
Entry orders
Confirmed currenttype=1 limit, 2 post-only, 3 IOC, 4 FOK, and 5 market. Plan orders support the same five execution types after their trigger condition.
Fields: type, 1, 2, 3, 4, 5
Sources: MEXC Futures Place Order; MEXC Futures Place Plan Order
Time in force
Confirmed currentThere is no standalone timeInForce field. Post-only, IOC, and FOK behavior is encoded in type; the reviewed page does not label an ordinary limit as GTC.
Fields: type
Sources: MEXC Futures Place Order
Take profit / stop loss
Confirmed currentEntry and plan orders expose takeProfitPrice, stopLossPrice, profitTrend, lossTrend, and priceProtect. A separate position TP/SL route controls partial or whole-position exits.
Fields: takeProfitPrice, stopLossPrice, profitTrend, lossTrend, priceProtect
Sources: MEXC Futures Place Order; MEXC Futures Place Plan Order; MEXC Futures Place Position TP/SL
Trigger price source
Confirmed currenttriggerType=1 means greater-than-or-equal and 2 less-than-or-equal. trend, profitTrend, and lossTrend select latest, fair, or index price with values 1, 2, and 3.
Fields: triggerType, trend, profitTrend, lossTrend
Sources: MEXC Futures Place Plan Order; MEXC Futures Place Order
Reduce-only / close
Confirmed currentreduceOnly applies in one-way mode. Hedge closes instead use side=2 or side=4, a close volume, and normally a positionId. A platform-level Close Signal action must not be mapped blindly to close_all.
Fields: reduceOnly, side, positionId, close_all
Partial close
Confirmed currentA normal partial close uses vol in contracts. Position TP/SL uses volType=1 for partial and 2 for whole-position behavior, with separate takeProfitVol and stopLossVol fields where applicable.
Fields: vol, volType, takeProfitVol, stopLossVol
Sources: MEXC Futures Place Order; MEXC Futures Place Position TP/SL
Cornix can bridge a signal lifecycle, but its private translation remains undisclosed
Documented input
A signal can name a pair, entry or buy prices, up to 10 entries, up to 10 take-profit targets, one stop loss, direction, leverage, and cross or isolated margin intent. Prices are posted as prices rather than percentages.
Undisclosed layer
Cornix documents signal text fields and lifecycle behavior that can bridge a posted signal into associated automated trades. Its public help pages do not publish the exact exchange payload, rounding algorithm, time-in-force choice, trigger-source choice, or multi-target order construction used for each venue.
Edit and close boundary
Edits and closures can propagate to Signals Bot auto-trades, while manual or Follow-button trades can require a manual update or close. Closing a signal is a platform lifecycle action and must not be equated directly with an exchange reduce-only flag or close-all endpoint.
Result boundary
The CSV export records theoretical signal data and selected target or entry hits. It is not an exchange fill ledger or realized PnL statement.
Six conflicts must remain visible in any summary
- Binance route migrationConditional STOP-family and trailing orders moved to the algo-order route even though the normal New Order schema still exposes stale-looking enums.
- Bitget API generationUTA v3 and Classic v2 use incompatible quantity, product, position, and TP/SL field contracts; they must never be blended.
- MEXC accessCurrent trading documentation and public metadata supersede old maintenance labels, but public pages conflict on who can obtain private futures API access.
- Location-blocked metadataBinance returned 451 and Bybit returned 403 from the research location, so no current production BTC limits are published for those two venues.
- Signal percentage to quantityNo venue accepts a provider's portfolio or risk percentage as a complete order quantity. Balance, price, leverage, contract value, minimums, and rounding are still required.
- Platform close versus exchange closeClosing a Cornix signal is a lifecycle action and is not interchangeable with reduce-only, closePosition, closeOnTrigger, position-side closes, or a venue close-all route.
Method and retirement boundary
Source policy
Use first-party API documentation and public instrument endpoints. Keep endpoint-specific semantics separate. Do not infer UI labels, account defaults, regional availability, rounding behavior, or successful order acceptance.
Runtime policy
A public instrument response is a dated snapshot, not a permanent rule. A 403 or 451 response from the research location is a blocked observation, not evidence of a global outage.
Execution policy
No account login, API key, private endpoint, order placement, cancellation, position change, or funds movement was used.
Consolidation policy
The former 600-page audience-by-venue-by-task matrix is replaced by one evidence-backed canonical. Former child paths must permanently redirect to the canonical and must not remain in sitemaps or IndexNow submissions.
Permanent route change: 600 former child pages now resolve by HTTP 301 to this exact canonical. They are removed from the generated manifest, sitemap, WordPress child inventory, and IndexNow payload.
Related due-diligence routes
First-party source register
Every field-level statement points back to an exchange or platform source. Runtime hashes identify the exact dated response used; they do not freeze future instrument rules.
- Documents pair, entry, target, stop, leverage, margin, direction, and multi-entry or multi-target signal fields. Accessed 2026-07-11; updated: 2026-04-21; state: live; confidence: high.
- Distinguishes automatic signal-to-trade propagation from manual update and close workflows. Accessed 2026-07-11; updated: 2026-03-26; state: live; confidence: high.
- Documents exported signal fields and the theoretical signal-return calculation boundary. Accessed 2026-07-11; updated: 2026-04-21; state: live; confidence: high.
- Identifies the venue families Cornix says it supports; it does not disclose the private translation payload. Accessed 2026-07-11; updated: 2026-06-08; state: live; confidence: high.
- Documents USD-M order side, position side, order type, TIF, quantity, trigger, closePosition, and reduceOnly fields. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Defines the public symbol and filter lookup required before quantity and price validation. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Separates normal order placement from the current conditional algo-order contract and documents its trigger and close fields. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Documents position mode and per-symbol cross or isolated margin configuration outside the order payload. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- States that conditional order types moved to /fapi/v1/algoOrder and that the normal order route rejects them with error -4120. Accessed 2026-07-11; updated: 2026-07-10; state: live; confidence: high.
- The endpoint returned HTTP 451 from the research location; no global availability inference is made. Accessed 2026-07-11; updated: request-time; state: runtime_blocked; confidence: high.
- Documents category, symbol, side, order type, quantity, position index, TIF, trigger, TP/SL, closeOnTrigger, and reduceOnly fields. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Defines the instrument metadata lookup required before price and quantity validation. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Documents one-way and hedge position-mode configuration outside the order payload. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- The endpoint returned HTTP 403 from the research location; no global availability inference is made. Accessed 2026-07-11; updated: request-time; state: runtime_blocked; confidence: high.
- Documents instrument, trade mode, side, position side, order type, contract size, attached TP/SL, and reduce-only fields. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Documents net and long-short position modes and their account constraints. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Documents standalone trigger, trailing, TP/SL, trigger-source, and close-fraction behavior. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Defines contract value, tick, lot, minimum size, settlement, and state metadata. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Returned state=live, ctVal=0.01 BTC, lotSz=0.01 contracts, minSz=0.01 contracts, and tickSz=0.1. Accessed 2026-07-11; updated: request-time; state: live; confidence: high.
- Documents UTA category, quantity, side, position side, margin mode, TIF, TP/SL, trigger, and reduce-only fields. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Documents one-way and hedge holding modes for UTA contracts. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Documents conditional and full or partial TP/SL strategy fields. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Defines UTA quantity and price multipliers, minimum order quantity, minimum amount, type, and status. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Dates the addition of marginMode to the UTA place-order contract. Accessed 2026-07-11; updated: 2026-05-19; state: live; confidence: high.
- Establishes that Classic productType, size, force, tradeSide, and preset TP/SL fields belong to a separate API contract. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Returned status=online, quantityMultiplier=0.0001 BTC, minOrderQty=0.0001 BTC, minOrderAmount=5 USDT, and priceMultiplier=0.1. Accessed 2026-07-11; updated: request-time; state: live; confidence: high.
- States that futures API maintenance ended and trading reopened on 2026-03-31, superseding legacy maintenance labels. Accessed 2026-07-11; updated: 2026-06-18; state: live; confidence: high.
- Documents contract symbol, size, price unit, volume unit, minimum volume, and API-availability metadata. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Documents contract quantity, four side codes, position mode, margin mode, order type, leverage, attached TP/SL, and reduce-only fields. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Documents trigger direction, trigger price source, and execution order type for plan orders. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Documents partial and whole-position TP/SL volume controls. Accessed 2026-07-11; updated: unresolved; state: live; confidence: high.
- Describes the 2026 futures API launch, KYC application path, regional restrictions, and excluded instrument boundary. Accessed 2026-07-11; updated: 2026-03-30; state: live; confidence: high.
- Says futures API applications are primarily available to institutional users, creating an access boundary that public metadata cannot resolve. Accessed 2026-07-11; updated: 2026-05-26; state: live; confidence: high.
- Returned success=true, apiAllowed=true, contractSize=0.0001 BTC, priceUnit=0.1, volUnit=1, minVol=1, and raw state=0. Accessed 2026-07-11; updated: request-time; state: live; confidence: high.
Questions this audit answers
Can one crypto signal be copied into every exchange order form?
No. The five venues differ in symbol format, quantity unit, side and position-mode mapping, margin fields, time in force, trigger sources, reduce behavior, and partial-close controls.
Does this audit recommend an exchange or trade?
No. It compares public API contracts and dated public metadata. It does not decide exchange safety, regional eligibility, account permissions, signal quality, or whether any trade should be placed.
Why were 600 child pages retired?
The old audience-by-venue-by-task matrix repeated generic advice without enough page-specific evidence. This canonical consolidates the useful question into one field-level comparison and permanently redirects the former children here.
Are the current instrument values permanent?
No. OKX, Bitget, and MEXC values are dated snapshots. They must be refreshed before validation or order construction. Binance and Bybit values were not captured because their public production endpoints were location-blocked.
Reuse and citation
You may quote or reuse the field-level findings with attribution to CryptoSignalsReview, this canonical URL, dataset ID csr-crypto-signal-exchange-order-translation-2026-07-11, and research date 2026-07-11. Preserve current conflicts, runtime blocks, and decision boundaries beside any extracted fact.
Immutable public release: release page; source JSON; derived summary JSON. Frozen repository source: e411b178f2ea5d8b5ed62d3c05ef4bd818b6c3be.