Binance Futures Bot Architecture: Notional Sizing and Protective Order State

한국어로 읽기

SYSTEM DESIGN / FUTURES

A futures bot needs a consistent view of both its exposure and the protective orders accepted by the exchange. If entry succeeds but a protective order is rejected, the interface must not report the whole operation as successful.

This article describes an order-handling design for Binance USDⓈ-M futures. The numbers below are invented to illustrate arithmetic; they are not account results or suggested leverage settings.

Design illustration. Order acceptance does not guarantee an exit price or a completed fill.

1. Fixed notional means fixed price exposure

With an entry price of 100 and notional of 125, quantity is 1.25. A long position's gross profit at 101 is therefore 1.25. Keeping notional fixed while changing configured leverage from 5 to 10 does not change that gross profit.

What changes in a simplified calculation is the initial margin estimate: notional divided by leverage is 25 at 5× and 12.5 at 10×. This omits fees, funding, maintenance margin and account-specific rules. It is not a liquidation-price or available-balance calculator.

from decimal import Decimal as D

notional = D("125")
entry_price = D("100")
exit_price = D("101")
quantity = notional / entry_price
gross_pnl = quantity * (exit_price - entry_price)

for leverage in (D("5"), D("10")):
    initial_margin_estimate = notional / leverage
    print(leverage, quantity, initial_margin_estimate, gross_pnl)

Output from Python 3.12, in the order leverage, quantity, estimated initial margin and gross P&L:

5 1.25 25 1.25
10 1.25 12.5 1.25

If instead you hold the margin budget fixed and increase notional with leverage, the P&L amount for the same price move grows. A setting named notional_per_entry makes the distinction explicit.

2. Check size rules and account mode first

A position-count cap alone does not cap total exposure. Track per-symbol and total notional, outstanding entry orders and available margin together. Multiple symbols can move in the same direction, so more symbols should not automatically be described as effective diversification.

Use the current symbol filters in the exchange-information documentation when adjusting quantity and price to permitted increments. Recheck order constraints after adjustment. Display precision alone is not a reliable substitute for the symbol's lot and price rules.

3. Verify protective-order acceptance

The USDⓈ-M trade documentation, checked on 2026-09-29, uses POST /fapi/v1/algoOrder for conditional orders. Hedge Mode requires positionSide and disallows reduceOnly. closePosition=true also has restrictions on combining it with quantity or reduceOnly. One generic “reduce-only stop” request does not fit every mode.

The application should reconcile actual entry fills, create the appropriate protection, and confirm acceptance. A log saying “request sent” is insufficient. Partial and subsequent fills must be considered when maintaining the protected quantity or a close-all policy.

4. A trigger price is not a guaranteed fill price

The condition that activates a market order and the prices where it executes are different concepts. Fast moves and limited liquidity can produce a worse exit than expected. Exchange-side orders reduce reliance on a running local process, but do not remove the need to monitor acceptance, conditions and account state.

Situation	Distinction to preserve
Entry filled; protection rejected	Exposure exists; protection is unconfirmed
Entry partly filled	Actual exposure differs from requested quantity
Take-profit executed; stop remains	Check whether the remaining conditional order needs cleanup
Restart after losing connectivity	Reconcile positions, ordinary orders and conditional orders

5. Indicator agreement is a hypothesis to test

Adding Supertrend, PSAR or Bollinger conditions can reduce the number of entries. It does not by itself prove better signals. Several indicators may recheck similar information, or the combination may fit historical data too closely.

Evaluate strategy performance separately, and design order handling so its state remains explainable when a strategy is wrong. Start with duplicate-event, lost-response and restart checks, then use development stages to validate the boundaries in local and paper environments.

Content and examples reviewed: 2026-09-29