The call went out, your order went in, and only part of it filled. The position you own is not the one the message described, the unfilled remainder is still a live order you can be handed back later, and the average price you actually paid is the entry that decides your result.

What actually happened when only part of it filled?

The message said long, gave a price, gave a stop. You put in a limit order for the size you had planned, watched it go green in the order list, and moved on. Later you look properly: the order says partially filled, and the quantity next to it is a fraction of what you typed.

Nothing malfunctioned. A limit order is an offer that sits in the book until somebody trades against it, so it fills for exactly as much size as arrives at your price and no more. Binance's own explanation of why limit orders sit unfilled puts the mechanic plainly: "an order can also be partially filled if the liquidity satisfies part of the order," and it adds the case that catches followers of fast calls, that "during periods of high volatility, your order may not be able to reach the end of the order book for execution, even if the market price reaches your limit price" (Binance Support).

The exchange treats this as an ordinary, named state rather than an error. In Binance's spot API reference the order status NEW means "The order has been accepted by the engine," PARTIALLY_FILLED means "A part of the order has been filled," and FILLED means "The order has been completed" (Binance Spot API documentation). Bybit exposes the same idea as a number you can read off the order: leavesQty is "The remaining qty not executed," alongside cumExecQty, the "Cumulative executed order qty," and avgPrice, the "Average filled price" (Bybit V5 API documentation). Field names and exact behaviour differ between venues and change over time, so read your own exchange's page rather than assuming these carry across.

So there are two objects now, not one. A position that is smaller than planned, and a live order for the difference that you still own. Almost every problem below comes from treating the second one as if it were gone.

This is not the same failure as a market order getting a worse price than the screen showed. That one is covered in what fees and slippage do to a 2% target. This piece is about size you never got.

Why is the channel's risk instruction no longer true?

Channels publish risk as a rule of thumb: risk 2% of the account, use 3x, use a tenth of your balance. That instruction is arithmetic tying three things together, position size, stop distance and the money you lose if the stop hits. Change one and the other two stop matching.

A partial fill changes one. Suppose you sized the trade so that the distance from entry to the published stop was worth 2% of your account. You get 40% of the size. The stop is in the same place, but the money at risk behind it is now 0.8% of the account. The channel's number quietly stopped describing your trade the moment the fill came back short.

Under-risking is the harmless direction, and it is the one most followers land in without noticing. The harmful direction is the correction: seeing a small position, deciding to top it up at whatever price is now on the screen, and ending up with the full size at a worse average and a stop that is now much closer than the plan assumed. That is the same trade as chasing, arrived at sideways. The safer habit is to treat the fill you got as the whole trade and adjust the exit sizing to it, which is the mechanical part of position sizing for signal followers.

There is a second-order version of this that costs people real money. If your take-profit and stop-loss orders were placed for the full intended quantity rather than the quantity that actually filled, then a stop sized for one BTC sitting under a position of 0.4 BTC is not a stop. It is a stop for 0.4 and a fresh short for 0.6, entered automatically at the worst moment you could pick. Which is exactly the problem the next flag exists to solve.

What is reduce-only for, and why does it matter here?

Reduce-only is a per-order flag that tells the exchange this order may shrink a position and may not open one. Bybit's API documentation describes it as: "true means your position can only reduce in size if this order is triggered," and instructs that "You must specify it as true when you are about to close/reduce the position" (Bybit V5 API documentation). Binance carries an equivalent parameter on USD-margined futures with its own constraints, including that it "Cannot be sent in Hedge Mode" (Binance derivatives API documentation). Availability, naming and restrictions vary by venue and by product, and they get revised, so check the flag on the ticket you are actually using.

The reason a follower needs it is the leftover. Picture the ordinary sequence: you get a partial fill, the trade works, you close the position manually or the take-profit fires. You are flat and you stop paying attention. Hours later price comes back down through your original entry, and the remainder of that first order, still resting in the book, still yours, finds a counterparty. You now hold a position you did not decide to open, in a trade you consider finished, with no stop attached because you took the stop off when you closed.

Two habits close that hole. Mark exit orders reduce-only so they can never flip you into a new position. And treat cancelling the unfilled remainder as part of closing a trade, not as tidying up afterwards. A trade is not closed while an order belonging to it is still live.

Does a fill in five pieces cost more than a fill in one?

Sometimes, and it is never cheaper. A fee is charged against execution, not against the order you typed. Binance tells users they can see "the fees charged for each trade via Trade History" (Binance Support) — each trade, not each order. Five pieces is five rows.

If the venue charged one flat rate, splitting a fill across five executions would cost the same as one, because the fee is proportional to the size that executed. Venues that price maker and taker differently break that symmetry. Binance.US states it directly for a single split order: "In instances where an order fills partially, the portion of an order that fills immediately is subject to a taker fee, while the portion of an order that makes it onto the order book will be subject to a maker fee" (Binance.US Help Center). One order, two fee rates, decided by which side of the book each piece landed on.

The practical consequence is that you cannot compute your cost from the order screen. The channel's published entry and target imply a certain gross move. Your actual cost is the sum of what each execution was charged, and a call that reaches you on a limit order sometimes pays taker on the aggressive part and maker on the rest. Small per trade, and the same size as the edge being claimed once you have done it two hundred times. The full arithmetic of how that eats a modest target is in what fees and slippage do to a 2% target.

What is a channel really asking for when it publishes an entry range?

A range is a plan that assumes several fills. When a message says enter between two prices, the author is describing a position built in pieces as price moves through the band, and every piece is its own execution at its own price. That is not a defect of the format; it is the format working as intended.

It does change what "the entry" means. Your result is decided by the average of what you actually paid, not by the number at the top of the message, and screenshots of results tend to be computed from the friendlier end of the band. Exchanges will show you the true figure: Bybit's avgPrice field is literally the "Average filled price" of the order. Read that number before you judge whether a call worked, and read it before you post a review. A more complete treatment of what those bands ask of a follower is in what a channel's entry range really asks.

There is a quieter version of the same issue. If you only fill the first slice of a three-slice range, you own a position sized for one third of the plan at an average equal to the worst end of it, because the good prices were the ones that never traded. Nothing was mis-specified. You simply got the part of the plan that the market handed out.

What is actually in your control here?

Four things, and none of them require an opinion about the market.

The order type. How long the order lives and whether partials are acceptable is a field you fill in, not the channel. Binance defines its time-in-force options as GTC, where "An order will be on the book unless the order is canceled"; IOC, where "An order will try to fill the order as much as it can before the order expires"; and FOK, where "An order will expire if the full order cannot be filled upon execution" (Binance Spot API documentation). Fill-or-kill removes partial fills by refusing everything, which trades one problem for a different one. Immediate-or-cancel takes what is there and leaves nothing resting, which removes the leftover but not the short size. There is no free option, only a choice about which failure you would rather have, and the trade-offs across the whole ticket are laid out in which order type turns a published entry into a position.

Reading the filled quantity instead of assuming it. Look at the executed quantity and the average price on every entry, before you place exits. This is ten seconds and it removes the entire class of problems above.

Sizing the exits to what you own. Stop and take-profit quantities should match the filled quantity, and should be reduce-only where the venue offers it.

Cancelling what is left before you walk away. Flat means no position and no live orders attached to that trade.

None of this improves a channel's calls. It only stops a follower from ending up in a different trade from the one they agreed to take, and that gap is where a surprising amount of avoidable loss sits. In our replay archive, as of August 2026, the single largest outcome for a published call is that it never became a fillable trade at all. A partial fill is the same problem in miniature: not a wrong call, just less of it than you were told you had.