Bitmart is in reduce-only mode for reviewing and closing positions

Bitmart is operating its futures accounts in reduce-only mode during the platform wind-down, so an eligible order shrinks or closes existing exposure without opening a new position. The first task is to match the order side to the position direction, then cap the order size at the remaining number of contracts. A long closes with a sell instruction; a short closes with a buy instruction. Position mode changes the code and wording that represent that action. Limit, market, take-profit, stop-loss, and trailing exits also behave differently after submission. This field manual follows the lifecycle from reading the position record through confirming zero exposure and preserving the final order history.

It is a centralized crypto exchange where reduce-only futures orders can shrink or close an open position without increasing or reversing exposure, subject to available position size.

An oversized close order can leave the intended exit incomplete

An oversized reduce-only order is a closing instruction whose requested contracts exceed the open position available to reduce.

Reduce-only protects the exposure boundary, not execution completeness. A limit order remains open when the book never reaches its price, while a market order fills only against available bids or asks. Another take-profit, stop-loss, or manual close may reduce the position before the first order finishes. The original quantity then exceeds the contracts still available. Bitmart records the fill and remainder separately, so the submitted size does not prove a zero position. Read the live position after every fill, then cancel or resize any leftover exit instruction before placing another order.

The opposite mistake is undersizing the close. That action deliberately leaves residual exposure, which continues moving with the contract. A refreshed position record provides stronger evidence than an accepted order notification.

Review the position record before choosing the exit side

The futures position record is the account state that supplies direction, size, margin mode, and unrealized profit or loss. Read it before opening the order ticket, because direction determines whether the exit uses buy or sell.

Read direction and contracts

Position type 1 denotes long, and position type 2 denotes short in the position data. The current_amount and position_amount fields report contract quantities; they are not coin balances. A BTCUSDT or ETHUSDT symbol identifies the contract, while the size field accepts an integer number of contracts. Copying a USDT balance into that field would confuse collateral with exposure.

Separate account equity from position size

Available balance, equity, frozen balance, and position margin describe account funding. They do not replace the open-contract count. Bitcoin, Ether, and Tether's USDT can appear in futures account records, yet a close decision begins with the matching symbol and its position direction. A client order identifier may contain up to 32 case-sensitive alphanumeric characters, which helps reconcile a submitted close with its later order record.

One-way mode and hedge mode encode the close differently

The position mode is the contract setting that controls how Bitmart represents long, short, open, and close instructions. Two modes appear in the position record: one_way_mode and hedge_mode.

In one-way mode, side 2 is buy reduce-only, while side 3 is sell reduce-only. Hedge mode also uses side 2 to close a short and side 3 to close a long, but its labels explicitly describe the position being closed.

The number has no independent meaning outside the active position mode. Read position_mode first, then construct the side value; reversing that sequence creates an instruction with the wrong position intent.

Venue schemas are not portable. Binance Futures exposes a reduceOnly parameter on eligible orders. OKX combines reduceOnly with position-side fields, Bybit provides a reduce-only control, and Deribit accepts a reduce_only field. Bitmart instead encodes the intention directly in one-way side values, making its numeric mapping more specific than the similar labels used elsewhere.

Order type decides whether the exit waits or fills immediately

The order type is the execution instruction that decides whether price certainty or immediate reduction receives priority. Bitmart supports two basic contract order types, limit and market, while size remains an integer contract count.

Limit orders preserve price control

A reduce-only limit order waits at its stated price or better. Mode 1 means good-till-canceled and is the default. Mode 4 means Maker Only, so an instruction that would immediately take liquidity does not proceed as a maker order. Neither setting guarantees that the market reaches the limit before the closing deadline.

Market orders prioritize immediacy

A reduce-only market order trades against the available order book. It removes the need to select a limit price, although several fills may produce one average deal price. The position amount changes only for contracts that actually execute, so the post-trade record remains the decisive status.

Time-in-force changes the remainder

Four time-in-force codes exist in the order model: mode 1 is GTC, mode 2 is FOK, mode 3 is IOC, and mode 4 is Maker Only. FOK requires the entire quantity to execute together. IOC accepts immediate fills and cancels the rest. A waiting GTC limit offers greater price control than an immediate market close. The same ground is broken down in Bitmart about support fundamentals.

Partial fills change the position before the order finishes

The fill record is the execution state that shows how much of the closing order actually traded. A partial fill reduces exposure immediately, even while an unfilled GTC remainder stays open.

Order detail reports deal_size, average deal price, and state, while the position record reports the contracts still exposed. Those records answer different questions. A GTC remainder stays live until it fills or is canceled; an IOC remainder cancels immediately, and a FOK order either fills completely or does not fill. For API automation, the timed-cancel setting accepts a minimum of 5 seconds, while a timeout of 0 removes that setting. During the wind-down, API trading is being discontinued, so the interface and final account history remain the practical recovery path. Reading both records is more precise than treating the first fill as the entire close.

Trigger orders need an active position and a matching side

The trigger order is a conditional exit that activates only while a matching futures position exists. Take-profit and stop-loss instructions therefore belong to an active position, not a future entry.

The API limits these closing sides to code 2 for buying against a short and code 3 for selling against a long. The API assigns trigger price type 1 to last price and type 2 to fair price. Plan category 2 is the default position-level TP/SL setting, while category 1 represents the general TP/SL form. The execution category has two choices, limit and market. Trailing orders may also carry reduce-only sides, but their activation and callback logic leaves a live remainder until execution completes. A manual market close is more direct than a trigger when the objective is an immediate, fully reviewed exit.

The wind-down timeline makes position review time-sensitive

The wind-down schedule is the fixed operating timeline that now governs every remaining Bitmart futures position. Futures accounts entered reduce-only operation from 01:30 UTC on July 26, 2026.

Bitmart scheduled all trading services to stop at 01:00 UTC on August 26, 2026. That moment is the decisive closing boundary, not the broader corporate termination date. Positions still open then may be settled by the platform under the applicable mark price, index price, or settlement rules. Users were asked to close every trading position before that cutoff and submit withdrawal requests before 05:00 UTC the same day. The two times differ by 4 hours, so a position review and withdrawal submission belong to separate account states. An accepted close order still requires a final fill check before the later withdrawal step.

In the version most people meet, Bitmart plans to cease platform operations at 15:59 UTC on January 31, 2027, with account access continuing for a specified period under later procedures. That termination point sits about 5 months after the trading stop, but it is not additional trading time. Closing and recording each position ahead of the earlier cutoff leaves greater control than platform settlement.

The final record should show zero remaining exposure

The final position record is the account evidence that proves the futures exposure has reached zero. Zero open orders only means no instructions are waiting; it does not show that a position disappeared.

Match the position record

Match the same contract symbol in the position and order records. For BTCUSDT, a completed close should reduce the relevant amount until the position record shows zero. Also confirm that no take-profit, stop-loss, trailing, or GTC limit order remains attached to that symbol. A flat account may still show realized entries in transaction history because closing exposure does not erase the execution trail.

Preserve the execution trail

The REST position query, order-detail response, trade-detail list, and WebSocket order updates form a useful sequence. The client order ID links the instruction to the platform order ID, while trade IDs identify individual fills. Save the direction, size, average deal price, timestamps, and final state. When the interface and API disagree briefly, the settled position record and completed trade details provide a stronger pair than a notification alone.

After the amount reaches zero, review futures assets separately from spot assets or a personal wallet. A confirmed zero position provides stronger evidence than an empty open-order list.

Helpful answers about Bitmart