Account has insufficient balance for requested action

[bmino]

Description:
This issue stems from the high latency it takes to execute three trades. The app can calculate profits in maybe 20ms, but then it takes almost 1000ms to execute the first trade and more time to execute the next two trades. By the time the first trade completes, too much time has passed and the market has shifted.

You can have market information that is 10ms old, and complete calculations in 20ms, but if it then takes 2500ms to execute the three trades, you are in a pickle :(

More Technical Description:
The bot calculates that with the current depth cache you should convert currency A into X amount of currency B and then X amount of currency B into Y amount of currency C, but by the time the first or second trade completes, that market depth cache information which the initial calculation was based on is stale so you can end up with less B or C than expected.

This error will occur when trying to perform the second or third leg of the triangle arbitrage.

Solutions:

• Use the TRADING.EXECUTION_STRATEGY of "parallel"
• Help me figure out a better alternative!

[kuuulwin]

Is there a way to switch trading in absolute values to percents?

Right now the program calculates how much cryptocurrency to buy and sell in absolute values but by the time they’re executed the market shifts and you have your orders stuck midway through.

What if you can execute trades using percents: you buy 100% (available from your balance) of coin B then sell 100% of your coin B for coin C and last you buy coin A with 100% of coin C.

You won’t need MIN, MAX and STEP anymore. But I don’t know how difficult that may be for you to implement into your source code.

As for runtime I heard about a connection called HTTP KeepAlive. I think it revolves around the idea to keep websockets always open. But the after effects of it are a mystery to me. I can look more into it.

It can be found in node-binance-api.js after the initial install of the script.

This is all I have for now. Don't know if it helps.

[bmino]

As per the keepOpen option of websockets:
This is currently implemented. All market cache data is being populated from websockets

As per trading on a percent basis:
Interesting! This isn't something I have considered yet. If all symbols involved are traded at 100% except for the base symbol this would work I think. However, it couldn't be a backup option ie "trade the calculated amount unless an insufficient balance error occurs, then trade x amount" because that would involve extra http calls which is the issue in the first place.

[kuuulwin]

Perhaps orders will not get stuck if you have some spare change in your wallet such as BTC and ETH.
When the market shifts and there is not enough coin to finish the triangle, the script can take some from your wallet.
For example, we have A, B, C cryptocurrencies. Just have 95% of A and 5% of B. It's usually the fractions of a cent that get the triangle stuck.

[bmino]

Yup, that would avoid the insufficient balance error @kuuulwin, but there is still a large window between calculation and when the final execution completes. That calculation has a lower degree of accuracy as time passes

[bmino]

Piggy backing off your idea however

If the calculation says x amount A will be converted into y amount of B, we can assume something like 0.95 * y is actually obtained of B where the 0.95 is configurable depending on volatility and market execution times.

Pros:

• Lessen the likelihood of the insufficient balance error
• Configurable depending on volatility, preference, etc.

Cons:

• Leads to small quantities of balance accumulating in random symbols
• Will not convert 100% of A through the cycle leading to less profit
• Does not guarantee to avoid the insufficient balance error

[kuuulwin]

Another idea, perform a calculation after the first or before the last trade.
In A - B - C you calculate according to the results of the first BUY or SELL (after AB executed, before BC)
In A - C - B you calculate according to the results of second BUY or SELL (after BC executed, before AB)
You said calculations might take about 20 ~ 30 ms that's not too bad of a loss.

[kuuulwin]

It looks like whether you want it or not you can't make a buy or a sell using the exact values as in MIN, MAX and STEP. Binance will round them up either way. So after the first or before last trade, the triangle is recalculated for the new purchase or sale price and no extra http calls as I understand.
If this idea won't work I can keep thinking about something else.

[bmino]

I like where your thought process is going!

If I read your idea correctly, you are suggesting once a determined amount of A is successfully converted into some amount of B, we then do another calculation to determine how much C we should expect from that amount of B?

The simpler approach would be to simply look at the exact amount of B we actually obtained. This can perhaps be done by:

1. Subscribing to a user's balance updates and calculating a delta on previous / new balance for B
2. Subscribing to a user's executionReport or something similar to view actual received quantity from a market order. This is by far preferable if possible

[kuuulwin]

Sometimes I overcomplicate things. But yes, the general idea is to do a balance check and recalculate based on what you got from the previous trade/trades.

Once converted you can't buy the same amount with BTC as you could with USDT.

I have another idea. When selecting an amount to trade with the script usually underBuys. For example, if you start execution with 40 USDT, you trade will rounded up to 39+ change. Is there a way to let the script overBuy with 40+ change then you have more room for the next trade.

Here the script could have bought 0.005866 and still fit in 30.2 USDT

Or overBuy 0.005867 and go over 30.2 by 0.00114521 which is a tenth fraction of a cent.
I have no clue whether this is going good, bad or work at all but no recalculation will be needed.

[bmino]

Looks like Binance has changed their api for market orders since the last time I looked. They now provide two golden parameters called executedQty and cummulativeQuoteQty which will provide us the the exact quantity of both symbols involved in the transaction.

After each leg in linear execution, we can look at the amount of the previous symbol received or spent, recalculate based on current market conditions if necessary, and then convert 100% of that into the next symbol. No need for insufficient balance errors!

It also allows us to convert as much of A as possible into B -> C -> A with minimal dust being generated in intermediate symbols.

[moonorblue]

Looks like Binance has changed their api for market orders since the last time I looked. They now provide two golden parameters called executedQty and cummulativeQuoteQty which will provide us the the exact quantity of both symbols involved in the transaction.

After each leg in linear execution, we can look at the amount of the previous symbol received or spent, recalculate based on current market conditions if necessary, and then convert 100% of that into the next symbol. No need for insufficient balance errors!

It also allows us to convert as much of A as possible into B -> C -> A with minimal dust being generated in intermediate symbols.

So this issue might be resolved by these parameters ? This issue still occurs in current version, might be fixed in next release ?
Thank you for such good bot

[bmino]

I'm testing it locally, but the next release will likely include these changes!

[sergioliberton]

All right?
I would like to know if there is anything new in relation to linear linearity, is someone making a profit or still has a problem that has already changed the market?
Thank you.

[bmino]

The recalculation logic is looking good, but there is still the occasional "account has insufficient balance" error. We're going for 100% bug squashing here though!

My other idea is to provide a config option that locks the three trade methods to BUY, SELL, SELL. This guarantees that we know the quantity of conversion in the second and third trade and can safely assume that we are even or slightly overestimating the initial investment quantity of A

[bmino]

Release 5.0.0 should fix this issue. If you continue to experience this issue using the latest release and settings, please open a new issue