LOT_SIZE step size not correct on all pairs

Hi,

I am having issues understanding the precision of different pairs.

I’ll take the example of XLMUSDT. If I pull the info from your api (/api/v3/exchangeInfo)

LOT_SIZE - stepSize: “0.10000000”
PRICE_filter - tickSize: “0.00001000”

So based on theses informations I should use only 1 decimal for the amounts (quantity/lot size).

But I get amounts with 2 decimals which creates an error in my system:
OrderBook->setElement(Object(Brick\Math\BigDecimal), ‘2677497.7500000…’, ‘asks’)

So basically why is there 2 decimals instead of one, and if I should not use the LOT_SIZE.tick_size as base asset amount precision, which value should I use ?

Thanks,

For quantity’s precision, use LOT_SIZE. For price’s precision, use PRICE_FILTER

This confirms that what I did is correct. I used LOT_SIZE.stepSize (“0.10000000”) for quantity but got quantity of 2677497.7500000 from binance).

Is this a bug from Binance ? And how should I handle it, just rounding it would cause issues ?

I saw this issue on multiple pairs.

I am using the websocket data :

wss://stream.binance.com:9443/ws/{$this->listen_key}

$conn->send(json_encode([
‘method’ => ‘SUBSCRIBE’,
‘params’ => [
strtolower($this->pair)."@depth", // Orderbook updates - THIS ONE IS THE ONE THAT RETURNS BAD DECIMALS
@userdata” // Trade updates
],
‘id’ => 1,
]));

I have the same error on price. Here is another example : EGLDUSDT

Taken today from /exchangeInfo:
filterType: “PRICE_FILTER”,
minPrice: “0.01000000”,
maxPrice: “100000.00000000”,
tickSize: “0.01000000

So we agree that every prices should only have 2 decimals.

What I received from websocket API => OrderBook->setElement('121.93900000’, ‘7.50000000’, ‘asks’)
Function parameters definition => setElement($price, $qty, $side).

So sometimes I get 3 decimals in price instead of 2. This data is fresh and taken from today.

Any idea ?

It doesn’t happen every time, only after a while.

I’ll set logs in my code to dump what I receive from the websocket when I get this kind of error.

Here is raw data I received for pair EGLDUSDT. Check price for the 2 last elements of the array (13 & 14). This is the ASK array. tick_size is 0.01, so 2 decimals, but got 3.

"a" => array:15 [
        0 => array:2 [
          0 => "112.73000000"
          1 => "0.00000000"
        ]
        1 => array:2 [
          0 => "112.74000000"
          1 => "0.00000000"
        ]
        2 => array:2 [
          0 => "112.75000000"
          1 => "7.93340000"
        ]
        3 => array:2 [
          0 => "112.76000000"
          1 => "2.03740000"
        ]
        4 => array:2 [
          0 => "112.77000000"
          1 => "0.00000000"
        ]
        5 => array:2 [
          0 => "112.78000000"
          1 => "8.08390000"
        ]
        6 => array:2 [
          0 => "112.79000000"
          1 => "0.17990000"
        ]
        7 => array:2 [
          0 => "112.80000000"
          1 => "0.00000000"
        ]
        8 => array:2 [
          0 => "112.81000000"
          1 => "0.00000000"
        ]
        9 => array:2 [
          0 => "112.82000000"
          1 => "2.85790000"
        ]
        10 => array:2 [
          0 => "112.84000000"
          1 => "0.76720000"
        ]
        11 => array:2 [
          0 => "112.89000000"
          1 => "0.00000000"
        ]
        12 => array:2 [
          0 => "112.90000000"
          1 => "0.00000000"
        ]
        13 => array:2 [
          0 => "298.96300000"
          1 => "0.00000000"
        ]
        14 => array:2 [
          0 => "398.96300000"
          1 => "0.00000000"
        ]
      ]

Maybe this data can also help:

 "e" => "depthUpdate"
  "E" => 1621494628289
  "s" => "EGLDUSDT"
  "U" => 435203660
  "u" => 435203721

Which endpoint did you get the 2 decimal point response from?

We will also keep track of the 2 symbols on our side and look out for this abnormal response. Please state the exact timestamp in your logs, thank you.

I’m not able to reproduce the 2 decimals in quantity for xlmusdt@depth with the market stream: websocat "wss://stream.binance.com:9443/stream?streams=xlmusdt@depth"