Words of compliments

[marsrobertson]

I like your code style, readability, clear separation of concerns.

My suggestion would be to avoid market orders.

Something can go wrong during the process, the market can move adversely

I suggest limit orders here: https://github.com/bmino/binance-triangle-arbitrage/blob/master/src/main/BinanceApi.js#L42-L70

I’m actually figuring out how to analyze all triangular arbitrage pairs on an exchange that has multiple base currencies.

• USD
• BTC
• ETH
• EUR
• JPY
• GBP

Also thinking if there is an opportunity of polygonal (4 trades, 5 trades) arbitrage.

Another view could be:

“if 4-trade arbitrage exists, then 3-trade arbitrage is possible too?”

TRUE or FALSE?

[bmino]

Well thank you!

Neat point on the polygonal trades as that is definitely a thing. Perhaps we can shift this codebase to be shape agnostic in the future.

As per market orders, I actually disagree with ya here. When purchasing higher values you are exhausting multiple levels of an orderbook. So if you are buying an asset, the lowest ask will be exhausted, then the second, third, etc. Market orders do exactly this where limit orders would require multiple orders to be placed per leg in the position. Perhaps you could argue that limit orders are more secure in that the leg would fail quickly if a depth is exhausted before the bot can grab it meaning the position is not the same as calculated

[marsrobertson]

About the limit / market orders: you can specify the limit order above the ticker price.

Example:

ASKS

amount	price
500	0.0011
200	0.0012
1000	0.0013

You can simply create limit order for 1000 at 0.0013

If you were to create market order and market moves against you, then you could end up spending too much.

---

I still do not know the thing about polygonal trades... If polygonal exist, does the simpler triangular exist too?

[sergioliberton]

Interesting

[bmino]

Interesting indeed. Okay so I was unaware that limit orders placed above the spread are filled in that manner.

I like that it guarantees the calculated quantity and quote. The deal breaker is verifying that the transaction has completed successfully. A market order http call returns (200 code) when the order is filled but a limit order might return when the order is not yet filled. Checking for such a case will use precious time mid-execution. Thoughts on this?

[marsrobertson]

It's better to check, lose 0.5s but avoid market order when it moves in another direction.

Testing will tell.

[bmino]

The ways I know to check:

1) Listen for order update websocket and filter for trade id 2) Query trade history endpoint on a loop until order has been filled

This will put a delay for all three steps in the execution (effectively slowing down the first and second execution). Depending on how long this takes it might be unacceptable. This solution was suggested to avoid interacting with a market that has moved, but by introducing more time to verify each step has completed will allow the market to move further