Push an OrderUpdateEvent through the UserDataStream when activationPrice is hit for a trailing_stop_market order

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 :nerd_face:

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”

@RalphAraujo Please open a separate topic in the forum.

1 Like

Hi,

  1. 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?
  2. In a nutshell, when the trailing_stop_market is ACTIVATED then 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. The ACTIVATED state 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 :slight_smile:

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 ACTIVATED state 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 :nerd_face:

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_market order’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 :smiley:

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

Liquidation is not directly related with an order, but with the entire futures account.

I suggest going over this article for more information regarding account Liquidation.

Tks once more !

I’m testing the behavior of trailing stop market in testnet futures UI interface.

I did 3 tests. I will describe each one separated

Test 1- I opened a TS market order - SHORT direction, without specifying the ACTIVATION PRICE.

ETHUSDT , yesterday 3 PM .

It is yet at OPEN ORDERS Up to now, almost 24 hours later.

It was placed with an ACTIVATION PRICE of >= $1,651.11.

It is in OPEN ORDERS as : Type : Trailing Stop / SIDE : OPEN SHORT Activation Price : $ 1,651.11 . Current Price: $1,724.88

Why not creat an ORDER and not is at POSITIONS ?

Not determine ACTIVATION PRICE may be a problem ? I already test putting AP and have same not good result

TEST 2 - I change the model and made :
A - create an MARKET ORDER - BTC , LONG . Made yesterday 15:30 PM

B - Create a TS market order without determine the ACTIVATION PRICE and direction SHORT ;

C- Create a STOP LOSS MARKET to protect if the prices goes OPOSIT of principal order

What is happening right now:

First the market order was posicioned imediately and at screen POSITIONS appear :

BTCUSDT 5x
Entry price : $19,235.70
Mark price: $20,984.54
PNL / ROE: + 33.06 / (+41.35%)

The Trailing stop is at OPEN ORDERS :

  • type : trailing stop
  • side : open SHORT ( in opposition of LONG of principal order )
  • Activstion price : >= $19,181.18
  • reduce only = No

This mean that the principal order opened is working without protection of the TS ?

Why TS is not activate and EXPIRED status ?

THIS IS MY KEY QUESTION !! Because it put in check if TS works EVERY TIME or can fail and put in risk my positions !

Test 3 : I made the same process of test 2 and TRAILING STOP was activated and is EXPIRED

Same process and different performance of TS

This process of create several orders for same contract / pair can cause any problem ?

I’m sorry the long question

without specifying the ACTIVATION PRICE.

If activation price is not defined, the latest market price is set as the activation price.

It was placed with an ACTIVATION PRICE of >= $1,651.11.

The threshold direction of the activation price is determined by the position direction (LONG or SHORT) and the order side (BUY or SELL), Therefore I believe that the following example, Test 1, was a BUY order.

Please consider the order side also. The threshold direction of a BUY SHORT order is not the same as the threshold direction of a SELL SHORT order.

Thanks.

Do you know if there are APIs to obtain information about the ALREADY PLACED order?

Entry Price , PnL , ROE etc ?

I mean , Data After order left OPEN ORDERs situation and appear at POSITIONs

What are these APIs

Tks

The Query Order endpoint

https://binance-docs.github.io/apidocs/futures/en/#query-order-user_data