I had an "open" short position on a call option. When call prices rose sharply, my trading bot, as a stop loss, placed exit order with market protection at default "-1". But the prices jumped above and my exit order was not executed resulting onto losses( my exit order remained "open" as the prices never came back to my order limit price). Had there been facility of "MARKET" orders through API calls, this would not have happened. Don't you think this is dark side of "market protection"? Do you suggest any solutions for such eventualities? -DCK
If you are using the default market protection value (-1), the protection range is automatically calculated on the backend by Zerodha.
If you require more control over execution behavior, you may consider using a custom market protection value, where you can explicitly define the acceptable protection percentage (for example: 2%, 5%, 10%, etc.). You can refer to the market protection documentation for more details.
Under the hood, market protection behaves similarly to placing a limit order with a buffer, since both approaches effectively define an acceptable execution price range rather than functioning as unrestricted market orders.
Please note that increasing the protection range may improve the probability of execution during volatile conditions; however, execution is still not guaranteed and remains subject to market liquidity, exchange LPP (Limit Price Protection) checks, and price movement.
I had used default protection (-1) but still prices jumped and my exit order did not execute. This effectively means my stop loss did not work resulting into huge loss. How on the earth "market protection" is implemented by exchange to protect traders? It is in fact detrimental to algo traders who do not want to see the screen all the time and rely on their code to execute orders. Is exchange forcing small traders to abandon idea of algo trading and switch to manual trading? You guys need to take this up with NSE/SEBI and put across our point of view because in this specific case of my trade, your auto calculated (-1) range did not save me. Don't you think converting all API order calls to "LIMIT" orders is injustice to algo traders. Market protection in my case effectively nullified my intent to get out of trade on stop loss hit. Those who formulated idea of "market protection" did not foresee this injustice to lakhs of algo traders. I finally have a question, if I calculate Upper & Lower circuit limits of an instrument at a given point of time through code and decide % of market protection based on that, will that guarantee execution of orders?
The AUTO (-1) market protection setting applies a dynamic protection range based on the Last Traded Price (LTP). However, it is important to note that this does not guarantee execution. If the market moves beyond the protection range before the order is filled, the remaining quantity can continue to remain open.
If you require more control over execution behaviour, you may consider using a custom market protection value (for example, 2%, 5%, 10%, etc.) based on your strategy and the instrument’s volatility profile. Under the hood, this behaves similarly to placing a limit order with a price buffer, since both approaches define an acceptable execution range instead of functioning as a pure market order.
Exchanges have never allowed market orders for institutional algos either. Retail algos weren’t formally recognised until now. Now that they are, the same rule applies.
While planning the execution flow, it may help to keep the following points in mind:
Market protection works independently of exchange-defined circuit limits.
The configured protection range should remain within both the circuit limits and the applicable LPP (Limit Price Protection) range.
Monitoring market depth and modifying orders dynamically based on liquidity conditions can help improve execution reliability.
A more robust approach could be to track live ticks via WebSockets and implement fallback logic—for example, if an order remains unfilled for a few seconds despite the price moving beyond the intended level, the algo may modify the order accordingly.
Such handling may help improve execution probability in fast-moving markets, though execution cannot be guaranteed.
If you require more control over execution behavior, you may consider using a custom market protection value, where you can explicitly define the acceptable protection percentage (for example: 2%, 5%, 10%, etc.). You can refer to the market protection documentation for more details.
Under the hood, market protection behaves similarly to placing a limit order with a buffer, since both approaches effectively define an acceptable execution price range rather than functioning as unrestricted market orders.
Please note that increasing the protection range may improve the probability of execution during volatile conditions; however, execution is still not guaranteed and remains subject to market liquidity, exchange LPP (Limit Price Protection) checks, and price movement.
You can also check the tradingqna post for more details.
If you require more control over execution behaviour, you may consider using a custom market protection value (for example, 2%, 5%, 10%, etc.) based on your strategy and the instrument’s volatility profile. Under the hood, this behaves similarly to placing a limit order with a price buffer, since both approaches define an acceptable execution range instead of functioning as a pure market order.
Exchanges have never allowed market orders for institutional algos either. Retail algos weren’t formally recognised until now. Now that they are, the same rule applies.
While planning the execution flow, it may help to keep the following points in mind:
- Market protection works independently of exchange-defined circuit limits.
- The configured protection range should remain within both the circuit limits and the applicable LPP (Limit Price Protection) range.
- Monitoring market depth and modifying orders dynamically based on liquidity conditions can help improve execution reliability.
- A more robust approach could be to track live ticks via WebSockets and implement fallback logic—for example, if an order remains unfilled for a few seconds despite the price moving beyond the intended level, the algo may modify the order accordingly.
Such handling may help improve execution probability in fast-moving markets, though execution cannot be guaranteed.