For the time being the team does not believe this change provides enough value to be placed in high priority. However, we are aware of the demand and may be re-visited in the future.
@tantialex the activationPrice on the trailing stops is optional, right? You can send a trailing stop through and it will trigger immediately. That means that when users actually go through the trouble of explicitly specifying an activationPrice, then it must follow that it’s important to their trading strategy, right? Doesn’t it logically follow then that it would be valuable for them to be notified about when it gets hit? Doesn’t it also follow then that not notifying them is a bug?
@tantialex I have modified my entire system with a polling mechanism, where I had to start tracking each individual order I put through, modifying their state as I go. For every position that I’m in that has trailing stops that haven’t activated yet, I loop through all of those positions and actually send a request through the API for the candlestick data for that position. I had to start tracking the open_time for each trailing_stop I put through. I limit the query for the candlestick data to 99 candles, starting at the tracked open_time, and only take the 1d interval candles because I don’t really care about the actual candlestick information, and I want to minimize not only the amount of request weight resources that I’m using up, but also the actual computational resources that I’m using up in the process. I then retrieve the high values from those candles, sort them, and pick the highest one. I then make inferences for that position, which of the trailing stops have been activated, and I modify those ones’ states individually. I then also move my stop loss based on the findings and send myself notifications through my front-end.
As a client of this API, these are the things that I had to do to compensate for the incompleteness of the trailing stop activation notification in the way that I’ve detailed it to you:
- Add state tracking to my database’s representation of a trade and a follow-up-order
- Add a timer that does things every n seconds
- Track every trade with some state, so that I can loop through the relevant ones every n seconds
- Retrieve candlestick data for the positions that are relevant
- Parse them, sort them and retrieve the highest value
- Look through all the open trailing stops for the position, adjust their internal state manually if it’s found that the highest high is higher than the specified activation_price
- For each one that was adjusted to be activated, send a notification through
- Determine to which level the stop-loss now needs to be moved to, and move it
- When all the trailing_stops have been activated, update the original order to say that we should exclude this one from the loop now
- I still need to catch the
order_update_eventsthat are currently happening, so that I can know when they actually execute and make me money haha, I’ll probably implement that today, but essentially I need to also hook that in to the whole state tracking system too so that my polling mechanism knows to skip the ones that aren’t relevant anymore. There will be some details there that I wouldn’t have had to deal with if I was just notified about the activation_price being hit.
So yeah, I had to come up with a whole convoluted system just as a workaround, and it’s not even perfect because, now:
- I’m using up
rate limitresources that I did not need to use up before, and that I would not have had to use up if theactivation_pricenotification was in place - I’m using up computational resources on a system that would not be necessary if
activation_pricenotifications were in place - I’ve introduced an inherent delay into the system of up to n seconds, at any given time my local representation of what’s happening might be out of date by up to n seconds, which isn’t much of a problem but it’s a nick on the paint, yknow?
For the last issue there, you might argue, “just use websockets to stream the stuff then you’re always up to date”. The issue with that is one of tradeoffs. By using the websocket streams, I would now be using a metric firetruck-tonne of computational resources to keep track of something that a very simple order_update_event would have solved. Computational resources are not free. I’m running my system on a little laptop with a battery life, and each little computation that I need to make cuts into that battery life. If I was using a cloud computing service, each little computation would’ve cut into the computing costs.
Like, without this very simple thing, myself and a whole bunch of others need to go through a whole bunch of mission and make unnecessary tradeoffs that wouldn’t be necessary to go through or make if the order_update_event was sent through when an activation_price is hit, which is explicitly specified in the first place, and thus is important to the user of that feature.
I cannot make sense of how you can’t perceive the value here.
Hi,
Thanks for the well written request, however I failed to understand the value of this change.
- Are there any additional advantages for having an event sent when activationPrice is triggered apart from being able to “visualise” the state of the order better?
- In which scenario would a trader make a better decision knowing that their TRAILING_STOP_MARKET is “ACTIVATED” as opposed to not being aware? (Please provide scenarios and/or examples).
Just to elucidate a bit more on the previous bit - in the absence of a monkey-patch solution (or checking manually), it might theoretically take a very long time for the trailing_stop_market to actually execute (i.e. the rebound rate passes the callback rate). Right now there’s no easy feedback to know that it’s safe to proceed with other trades in the interrim 
From that perspective, it might even be categorized as a bug, tbh
Hi !
I’m having problems with TRAILING SHOP MARKET API !
I read all documentation !
This conditions :
- Activation Price > Latest price (short)
- Activation Price < Latest price ( long)
I’m using :
To determine AP value I’m calculating 1% of LP > or < for long or short !
That’s good ? Or 1% is a big value ?
This other conditions - if mandatory and aditional to first described , I can’t atend because I don’t know where obtain :
- lowest price
- highest price
- rebound rate
Can you help me ?
And please WHY ORDERS have a big delay until be positioned ?
The prices change and I having a lot of negative ROE !
“ To activate a trailing stop order, 2 conditions need to be fulfilled.
A buy trailing stop order will be placed if the following conditions are met:
- Activation Price ≥ Lowest Price
- Rebound Rate ≥ Callback Rate
A sell trailing stop order will be placed if the following conditions are met:
- Activation Price ≤ Highest Price
- Rebound Rate ≥ Callback Rate”
Hi,
- Being able to “visualize” the state of the order better is already valuable in and of itself. Having more, higher quality information about the state of affairs makes it easier to make better-informed decisions. When you implemented the websocket endpoint for streaming candlestick data, did you ask your clientbase what they’re gonna do with the information or did you just provide it, knowing that different people will use their own creativity in different ways in applying that information?
- In a nutshell, when the
trailing_stop_marketisACTIVATEDthen that portion of the trade is not at risk anymore. When traders are operating under strict risk management protocols, that means they can then proceed to enter into additional trades, since the risk exposure has lessened. TheACTIVATEDstate is a clear signal/indication that risk exposure has decreased.
I can provide what I’m going to be using it for in my own strategy, but not on a public forum 
When you implemented the websocket endpoint for streaming candlestick data, did you ask your clientbase what they’re gonna do with the information or did you just provide it, knowing that different people will use their own creativity in different ways in applying that information?
It is important to understand that any additions to a public interface will affect all users, therefore, even a slight addition such as RSI will affect all connected clients, even the ones who do not require such an addition. With that said, the fundamental properties are provided via the stream for users to perform their own calculations with as little latency as possible.
When traders are operating under strict risk management protocols, that means they can then proceed to enter into additional trades, since the risk exposure has lessened. The
ACTIVATEDstate is a clear signal/indication that risk exposure has decreased.
While this is true, traders should gain no advantage receiving an event on ACTIVATION_PRICE triggering as risk exposure decisions should be taken against real-time changes of the market, thus implying the trader already has an open connection with a websocket market stream allowing them to evaluate if the order hit the activation price or not.
Right now there’s no easy feedback to know that it’s safe to proceed with other trades in the interrim
In theory, a trailing_stop_market order’s risk does not change if the activation price has been hit or not, assuming the same market price is applied to both scenarios. As mentioned previously, this type of risk assessment should be done by listening directly to market changes and not order changes.
With all that said, I will push this feedback to the respective team for awareness sake and so that they can evaluate the importance and value of such a change.
traders should gain no advantage receiving an event on ACTIVATION_PRICE triggering as risk exposure decisions should be taken against real-time changes of the market, thus implying the trader already has an open connection with a websocket market stream allowing them to evaluate if the order hit the activation price or not.
thus implying the trader already has an open connection with a websocket market stream
Not at all. I don’t use the websocket market streams. I rely fully on the OrderUpdateEvents getting passed through the UserDataStream.
even a slight addition such as RSI will affect all connected clients
Only if you push it through an existing endpoint, if you push it through a new endpoint then nobody’s touching it and so it won’t affect anyone. Pushing this event through the stream won’t affect anyone that isn’t explicitly listening for that particular event, but it definitely will bring clarity to the way that type of order works, and also to the state of things happening in real-time.
In theory, a
trailing_stop_marketorder’s risk does not change if the activation price has been hit or not,
The trailing_stop_market's risk does not change, no, but the position taken for that particular trailing_stop_market does. If you’re running, for example, a long position on something with a stop-loss at the bottom and a trailing-stop at the top, then the position is at risk up until the moment the price hits activationPrice. The moment that threshold is crossed, the position is no longer at risk, but until it is crossed, the position is still at risk.
While this is true, traders should gain no advantage receiving an event on ACTIVATION_PRICE triggering
And yet here I am, trading the markets, in a position where I will gain advantage from receiving an event on ACTIVATION_PRICE triggering.
As mentioned previously, this type of risk assessment should be done by listening directly to market changes and not order changes.
There’s a cognitive bias going on here. Your own personal framework/lens/perspective/model of how the markets ought to be traded, is impeding your ability to perceive the value that the API’s clientbase will derive from this feature. A million traders will trade the markets in a million different ways. As one of those million traders, I’m asking for a direct improvement that shouldn’t be a lot of work and that will also provide a lot of general clarity to how the order works, and also clarity into what the order’s state of affairs is - something that will improve the quality of the UserDataStream. It’ll make the UserDataStream better.
The existence of an event being passed through the UserDataStream when activationPrice gets hit on a trailing_stop_market order, will make this world a better place, at least for me, and I’m sure for others too 
1 Like
@Sparkelor
@tantialex
Do You can tell me HOW I know When ACTIVATION PRICE was HIT ?
Nothing help on the screen !
And TS order remains there até OPEN ORDERS
I don’t know if price is hit !
Or if has a bug and TS is not activated
TKS
If the trailing stop order was activated, you should received two events from the websocket. An event for the expiration of the trailing stop order, and an event for the creation of the underlying order (aMARKET order for trailing stop market orders or a LIMIT order for trailing stop limit orders).
Tks !
What is EXPIRED status ? All situations included ?
Expired order status means that ORDER was executed and callback have protected the GAINS ?
If not , how can I know that my gains was protected by trailing stop ?
And where this information can be obtained ? ( API )
Thank you for instance
What is EXPIRED status ? All situations included ?
Expired order status means that ORDER was executed and callback have protected the GAINS ?
For stop orders, trailing stop orders included, the expired status means the order’s activation was triggered. This does not mean that the underlying order has filled, nor does it mean that the underlying order was placed.
how can I know that my gains was protected by trailing stop ?
And where this information can be obtained ? ( API )
The underlying order “protects” your position. Once the trailing stop order is activated (expired), the underlying order is placed on the order book and filled respectfully.
The underlying order shares the same order id as the stop order, therefore you can query the GET /fapi/v1/order endpoint to obtain relevant information.
https://binance-docs.github.io/apidocs/futures/en/#query-order-user_data
Tks very much !
is that in my Brazilian Portuguese language, EXPIRED means something that didn’t perform and needs to be redone! It was of no use!
What about the CANCELED status, what does it mean in practice? a CANCELED TS order I mean
And please , it has an API that show me the LIQUIDATION PRICE for an ORDER ? I want close position before this event
An order with the CANCELED status means that the engine has removed your order. There are a number of reasons why the engine may cancel your order, however it is rare case. The most common reason for an order to have a CANCELED status is when the respective symbol is decommissioned from the exchange.
Ok ! Tks
And please , it has an API that show me the LIQUIDATION PRICE for an ORDER ? I want close position before this event