executedQty / cummulativeQuoteQty when not paying fees via BNB


I am trying to understand executedQty, no matter from which call (order create, query, cancel, …) if the user is NOT paying fees using BNB.

The use case is this:

  1. I execute a BUY LIMIT order on TRXUSDT pair for a quantity of 5.
  2. I check executedQty from the POST response or when querying the order via GET.

If the user is NOT paying the fees via BNB, will the executedQty be equal to 5, or let’s say 4.995?

I need to find the exact quantity available after non-bnb fees. So if I request to buy 5 but end up with 4.995 I need to know that, so I can sell 4.995 and not 5 and get API failure (assuming my TRX balance was 0 to begin with).

Also when I sell, I need to know exact USDT received, after USDT fees (when not paying with BNB). In this case I expect cummulativeQuoteQty to be AFTER paid USDT fees, e.g. usable USDT balance recived, is this the case?

No way to test right now as I have BNB on testnet and there doesn’t seem to be an option to toggle the fees payment system, and I don’t want to sell my BNB yet as BNBUSDT is the only pair with liquidity right now.

Thank you! :slight_smile:

I’ve also checked on testnet right now /api/v3/account, and


So it seems testing fees on testnet is not possible right now.

Ok I hope this helps you, when opening a buy position the commission is charged based on the base asset, in this example of the BTCUSDT pair the base asset is BTC, the commission charged depends on your VIP level, in my case I am Zero, so the fee I pay is 0.1% per operation, which you can obtain with a simple calculation if you look at the image the purchase operation was executed for “0.001809BTC” (executedQty) which is equivalent to 19.99026405USDT (cummulativeQuoteQty) so the commission to pay is “0.00000181” which comes from multiplying executedQty * fee

Then my system enters a STOP_LOSS_LIMIT to protect the operation that I just performed and as it is a test that I set to 1min 30seg, the STOP_LOSS _LIMIT is canceled after that time and later a LONG (SELL) closure is executed

As you can see in the case of the closing of the LONG (SELL) the commission is calculated using the quota asset (USDT) so when selling the “0.001809BTC” (executedQty) the commission is calculated based on the “19.98796662USDT” (cummulativeQuoteQty) being the fee equal to 0.1% so the commission paid in this case is equal to: cummulativeQuoteQty * fee

1 Like

@Saratoga Thank you, so there is no other way to calculate commission other than hard-coding your fee levels on a particular account?

As if your BTC balance was absolutely empty (zero), the executedQty on buy is 0.001809 BTC but you only have 0.001809 BTC - 0.00000181 BTC = 0.00180719 BTC to sell of which you can sell only 0.00180700 BTC because lot tick size on BTCUSDT is currently 0.00000100.

So if you had empty account and did not hardcode the commissions, you wouldn’t be able to calculate how much you can actually sell (without looking at /v3/account and other trickery).

Likewise this also applies to sells, if you had no USDT to begin with, you don’t know from cummulativeQuoteQty how much you really obtained from that sell.

The problem is when the order doesn’t immediately fill (e.g. it is a limit order for example), you can’t get fills from GET /api/v3/order and therefore you can’t know the commission paid without hardcoding it.

Is that correct? The API could be updated to return fills from GET /api/v3/order, that would be great :confused:

So I guess the morale of the story here is that NO, executedQty / cummulativeQuoteQty do NOT get subtracted with the commission paid when not paying commission via BNB (that also applies on pairs where BNB is the base or the quote and the account IS paying commission using BNB).

Ok I leave you this test that I run with only 10usdt in my margin portfolio, which is the minimum amount in addition to completely emptying the wallet and only leaving the exact 10usdt in addition to deactivating the discount paying with BNB as you can see in the image, I left a little balance of ZEC but it does not affect the results

If we deduct the 0.1% fee at 10usdt from the order it would be 10 * (1 - 0.001) = 9.99 which is what we have approximately in cummulativeQuoteQty (9.9993225), and as you can see my stop loss order was not executed by It was going to be executed for the “9.9993225” which is less than the minNotonial of 10usdt which is the minimum for this pair

1 Like

Interesting, I will experiment with this more soon, thank you.