Fat-fingered a limit price? Why it filled at once or got rejected

Your limit is a ceiling

Binance's help page on market and limit orders defines a limit order as one that will only be executed if the market price reaches your limit price "(or better)". For a buy, better means cheaper.

The page works through its own numbers. With the current price at 2,400, a buy limit at 3,000 fills immediately at around 2,400 rather than 3,000, and a sell limit at 1,500 fills straight away at around 2,400 rather than 1,500. The price you enter on a buy is the most you're willing to pay, so whatever part of the order the resting sells can cover trades on arrival instead of waiting in the queue. That part is a taker fill, and maker vs taker covers why that matters for cost.

How far "around the market price" can drift

The help page's "around 2,400" holds on a busy pair where sell orders are stacked tightly near the top. On a thin pair the fills can drift, because resting sells sit at several prices.

Illustrative numbers, not a real book: the last trade on a quiet pair was about 100, and you want 10 units with a limit you typed as 115. The resting sells look like this:

• 3 units resting at 101: you take all 3
• 5 units resting at 103: you take all 5
• 8 units resting at 110: you take the 2 you still need

Price priority fills the cheapest level first. Ten units cost (3 × 101 + 5 × 103 + 2 × 110) ÷ 10 = 103.8 on average, and the last two came from a level ten per cent above the last trade. The typo didn't set your fill price, but it let the order reach that far. If the book had run out before 115, the remainder would rest at 115 under GTC and you'd have a partial fill. The queue rules behind this are in the life of an order.

There's one more brake on how far a taker order can travel. Binance's spot API documentation describes a price range execution rule: on pairs that have it configured along with a valid reference price, a taker order that tries to execute outside the allowed range is expired, with the reason EXECUTION_RULE_PRICE_RANGE_EXCEEDED. The docs don't list which pairs use it, so your order history is the record of what happened.

Far enough off, and the order never lands

Type an extra zero and a different rule takes over. The Filters page of the spot API documentation lists the price checks an order has to pass before it's accepted. Two matter for typos:

• PRICE_FILTER sets a minimum and maximum price and a tick size. The price has to be a whole multiple of the tick.
• PERCENT_PRICE_BY_SIDE sets a valid range around a base price, with separate multipliers for buys and sells. The base is the pair's reference price when one exists, and otherwise the volume-weighted average over the last avgPriceMins minutes.

On 10 September 2026, Binance's public exchangeInfo endpoint returned identical settings for BTCUSDT, ETHUSDT, BNBUSDT, DOGEUSDT and PEPEUSDT: a buy could be priced between 0.5 and 1.2 times the base, a sell between 0.8 and 2 times, with the base averaged over the last 5 minutes. The stablecoin pair FDUSDUSDT was far tighter, 0.9 to 1.1 on both sides. These values can change and can differ by pair.

On those pairs, a buy more than 20 per cent above the base or a sell more than 20 per cent below it isn't accepted. Nothing appears in open orders and nothing trades. That catches an extra zero. It won't catch misreading 2,400 as 2,600, which is only about 8 per cent high and fills at once.

You won't see PRICE_FILTER or PERCENT_PRICE_BY_SIDE on screen; those are the API's names, and the rejection message is whatever your app shows. The help page on spot trading limits and parameters says each spot pair has its own parameters, such as minimum trade amount and minimum price movement, and gives the route to them: from the settings icon on the spot trading page, open Trading Parameters and choose View More; in the app, go to Trade, then Spot, then the menu, then Trading Parameters. It doesn't say whether the price bands appear there, so treat the API values above as a dated snapshot.

Reading what actually happened

Once the order is in, your records say which rule you met. Labels differ between web and app and across versions, so match the outcome rather than the exact words.

• Filled, with an average price closer to the market than to what you typed. The price crossed the book, and your limit was a ceiling you didn't need. How that fill feeds into your cost basis is covered in reading your average buy price and P&L.
• Partly filled, with the rest still open at your price. The book ran out before your limit. What to do with the remainder is in partial fills.
• In order history as cancelled or expired. A Post Only order that would have traded straight away is cancelled when you place it; IOC and FOK remainders expire; so does a taker order stopped by the price range execution rule. Time in force explains the Expired status.
• Nowhere at all, neither open nor in history. The order wasn't accepted. Check the digits and the pair's price band before trying again.

Where a fat-finger shows up before you submit

The total gives it away. An extra zero hides well in a price field and badly in price times quantity, so glance at the total before you confirm. Our order size calculator does the sum if you'd rather check it first.

The other tell is intent. If you meant to wait for your price, a buy priced at or above the lowest ask contradicts that, and Post Only is the setting that holds you to it. Binance describes it as ensuring your order is not executed immediately in the market; if the order would execute immediately, the system automatically cancels it on placement. It sits in the advanced order mode, which you switch on from the settings icon on the spot trading page, under Layout, by setting Order Mode to Advanced. How it relates to GTC, IOC and FOK is covered in the time in force article.