Hedge Mode vs One-Way Mode on Binance Futures

One switch, whole account

The position mode is the first thing to check before reading any other number on a Binance Futures account. It determines how many positions a symbol can hold, what value every order must carry, and how the position risk response is shaped.

Binance exposes it as dualSidePosition. The query endpoint, GET /fapi/v1/positionSide/dual, returns a boolean, and the documentation is terse: "true": Hedge Mode; "false": One-way Mode. The same setting applies “on EVERY symbol,” which is the sentence that matters most. A trader who imagines hedge mode as a per-symbol toggle will misread the first account that has it switched on.

There is a second, newer detail in the Change Position Mode documentation: after the CM migration, USDⓈ-M and COIN-M futures share the same dualSidePosition setting. Calling the endpoint flips both at once. An account that trades both futures books cannot run hedge mode on one and one-way on the other.

One-way mode: one net position

One-way mode is the simpler model and the default for most accounts. A symbol has one position, and its size is the net of every fill on that symbol. Buy 1 BTC, sell 0.3 BTC, and the position is 0.7 BTC long. Sell 2 BTC, and the position is 1.3 BTC short — the same single position, now on the other side.

The API reflects that model in positionSide. In one-way mode the account returns BOTH, and the order endpoint treats positionSide as optional and defaulting to BOTH. There is no LONG row and no SHORT row, because there are no two rows to report.

This is the mode that matches how most directional traders think. A stop closes the position, a take-profit closes the position, and there is only one “position” to close. The reduceOnly flag is meaningful here: it tells the engine that the order may only reduce the existing exposure, never flip it.

Hedge mode: two positions, two sides

Hedge mode splits the symbol into two positions. A long and a short can coexist, and the account reports them separately. Binance’s account documentation puts it directly: one-way mode returns BOTH; hedge mode returns LONG and SHORT.

That structure is useful when the two sides are genuinely different strategies. A market-neutral desk may run a long leg and a short leg on the same perpetual, each with its own entry, its own exit rule, and its own risk budget. Netting them into one position would destroy the information the desk needs: the long’s entry price, the short’s entry price, and the size of each leg.

It is also useful when a trader wants to lock a price without closing a position — for example, hedging an existing long with a short on the same instrument rather than selling the long and rebuilding it later. Whether that is cheaper than closing depends on fees, funding and the spread, but hedge mode is the mechanism that makes it possible without changing the original position.

The cost is complexity. Every order now carries a side and a position side, and the two must agree. A BUY with positionSide=SHORT is not a contradiction in hedge mode; it is the instruction that reduces the short. A SELL with positionSide=LONG reduces the long. The same two fields that were almost decorative in one-way mode become the identity of the order.

What every order must send

Binance’s New Order documentation states the rule plainly: positionSide defaults to BOTH in one-way mode and must be LONG or SHORT in hedge mode. “It must be sent in Hedge Mode.”

The practical failure modes follow from that sentence.

• A one-way client pointed at a hedge account. The client omits positionSide, the venue defaults it to BOTH, and the order is rejected because BOTH is not a valid side in hedge mode.
• A hedge client pointed at a one-way account. The client sends LONG or SHORT, but the account expects BOTH or an omitted field. The order is rejected or, depending on the client’s error handling, silently retried with the wrong side.
• A shared client with a cached mode. The account switches mode, the client keeps its old assumption, and every order fails until the cache is refreshed. The mode is not carried on the order, so the client has to query it or read it from the error.

The fix is to treat the position mode as account state, not as a constant in the code. Read it at startup, re-read it after any mode error, and include it in the order-building path rather than in a comment.

reduceOnly is not available in hedge mode

The second rule is the one that catches position-closing logic. Binance’s New Order documentation says reduceOnly “Cannot be sent in Hedge Mode.”

That is not an arbitrary restriction. In one-way mode, the engine needs reduceOnly to know whether a sell is allowed to flip a long into a short. In hedge mode, the position side already carries that information: a SELL with positionSide=LONG can only reduce the long, because the long is the position it names. The flag would be redundant, and Binance rejects it rather than ignoring it.

The same logic appears in the close-position variant. For STOP_MARKET and TAKE_PROFIT_MARKET with closePosition=true, the documentation adds that in hedge mode the order cannot be used with BUY on the LONG side or SELL on the SHORT side. Those combinations would try to close a position by trading in the same direction as the position, which is not a close at all.

A stop-loss implementation therefore cannot be copied between modes. In one-way mode it is a SELL with reduceOnly=true. In hedge mode it is a SELL with positionSide=LONG and no reduceOnly. The Bybit TP/SL guide shows the same split on another venue, where reduce-only and hedge mode interact with trigger orders in a way that silently disables part of the order.

Switching modes requires a flat account

Change Position Mode is POST /fapi/v1/positionSide/dual with a required dualSidePosition string. The endpoint is signed and account-wide.

It is also blocked by open activity. Binance documents two errors for the change:

• -4067 — open orders exist.
• -4068 — open position exists.

Both have to be cleared before the switch. That is a risk control, not a inconvenience: converting a net long into a hedge-mode long while a working stop is attached would leave the stop pointing at a position identity that no longer exists. The venue forces the account flat so that the new mode starts from a known state.

The operational consequence is that position mode is a maintenance-window decision. A strategy cannot switch modes mid-trade, and a multi-strategy account cannot give one strategy hedge mode and another one-way mode. If two strategies need different position accounting, they need different accounts.

What changes in the risk numbers

Hedge mode changes the shape of the position data, and that shape is what every risk calculation reads.

In one-way mode there is one position amount. A long of 1 BTC and a short of 0.4 BTC is a net long of 0.6 BTC, and the account’s exposure is 0.6 BTC. In hedge mode there are two positions: a 1 BTC long and a 0.4 BTC short. The net exposure is still 0.6 BTC, but the account now has two entry prices, two position amounts, and two sets of unrealised PnL.

That distinction matters for three calculations.

Liquidation estimates. Each side has its own entry price and size, and the position risk response reports each side separately. A calculation that assumes one net entry price will be wrong for at least one of the two positions, and the error grows as the two entries diverge.

Stop placement. A stop attached to the long does not protect the short. In a hedge account, every protective order has to name the position side it belongs to, and a stop with the wrong side is a stop on the wrong position.

Margin usage. The margin mode still decides which collateral backs the positions. Cross margin pools collateral across the account; isolated margin confines it to the symbol. Hedge mode does not create a separate margin account per side, but it does create two positions that both draw on the same margin. A trader who expects the short to “free up” margin for the long may find that the two sides are competing for the same buffer. The mechanics of that buffer are covered in maintenance margin and margin calls and in cross versus isolated liquidation.

When each mode is the right choice

One-way mode is the better default for directional trading. It has one position, one entry price, one stop, and no field that can disagree with the order’s side. A trader who buys, holds, and sells does not need a second position on the same symbol, and the netting behaviour is what they already expect.

Hedge mode earns its complexity in three situations:

1. Two independent strategies on one symbol. A long-term long and a short-term short can coexist without one closing the other.
2. A deliberate hedge that should not disturb the original position. The hedge is a second position, not a modification of the first.
3. A desk that reports each leg separately. Entry, size and PnL per side are the reporting unit, and netting would destroy it.

It is the wrong choice when the second side exists only because the first side is losing. Adding a short to a long does not reduce the loss; it locks in the spread between the two entries and adds two sets of fees and funding. That is a strategy decision, not a position-mode decision, but the mode makes it easier to do without noticing.

A checklist before switching

• Query GET /fapi/v1/positionSide/dual and record the current value; do not assume it.
• Confirm there are no open orders (-4067) and no open position (-4068).
• Remember that the switch flips both USDⓈ-M and COIN-M futures.
• Update every order builder: positionSide becomes required in hedge mode, and reduceOnly becomes invalid.
• Re-check every stop and take-profit template, especially closePosition=true.
• Re-read the position risk response and confirm the code handles two rows per symbol instead of one.
• Tell every strategy that shares the account, because the mode is not per strategy.

Sources and what they support

• Binance USDⓈ-M Futures, Get Current Position Mode — states that dualSidePosition is true for hedge mode and false for one-way mode, applies to every symbol, and that one-way returns BOTH while hedge returns LONG/SHORT. Read 2026-11-03.
• Binance USDⓈ-M Futures, Change Position Mode — gives the POST /fapi/v1/positionSide/dual endpoint, the required dualSidePosition parameter, the -4067 and -4068 errors, and the shared UM/CM setting. Read 2026-11-03.
• Binance USDⓈ-M Futures, New Order — states that positionSide must be sent in hedge mode, that reduceOnly cannot be sent in hedge mode, and the closePosition restrictions on STOP_MARKET and TAKE_PROFIT_MARKET. Read 2026-11-03.

Risk note. Position-mode behaviour, error codes and field requirements were read from Binance’s futures API documentation on 2026-11-03. Leveraged futures can lose more than the margin posted, and a position mode does not change the direction or size of the risk. Nothing here is investment advice.