Thanks @JordanLee for taking the time to expand on the enhanced liquidity operation with some figures. It has cleared up most of the concerns I had around the reasons for doing so when such a large change to the technical workings of NuBot is required to achieve it.
My remaining concerns are less to do with NuBot itself although they do echo @Cybnate s concerns above.
When working with NuBot, and previously with personal trading bots, the weakest point has always been the APIs of the Exchanges. While they perform admirably 99% of the time, the 1% when they fail (or communication with them fails) is when the market has most movement, which is just when you need them most. I’m less concerned about NuBot instances not being highly available, more the APIs, which are, unfortunately, out of our hands.
Although knowing this to be the case puts us on a good footing, a lot of thought needs to be paid to the best ways of reacting to such an API failure when it could impact the mirroring and overall liquidity provision so badly.
The actual implementation of reading orders, doing a calculation and placing a similar order somewhere else should be fairly straight forward. It’ll take time but the code to interact with the exchanges in that way is already there in NuBot, it’s just the controlling logic that needs a tweak. I’d agree that an extra developer for NuBot would be a good thing. As mentioned, I don’t always have the spare time to devote as I would like due to other commitments.
I do think though that before that, there should be a wider discussion among shareholders around the controlling logic of NuBot and how to react to the various scenarios that have historically played out in the real world. I’m constantly astounded by the level of trading knowledge displayed on this forum and feel that it’s a hugely valuable resource that needs to be tapped for the Nu trading bot.
My other concern is around the number of Custodians we have versus the number of markets we will potentially have to mirror. I’m comfortable with the idea of a single custodian potentially handling the mirroring of an entire exchange on a second, with all the pairs that entails. I’m also comfortable with the idea of a single custodian potentially running multiple instances of NuBot to cope with that. There comes a point though where we hit a natural limit both in terms of what a single custodian should be expected to handle for the return they get and in what a single NuBot instance can handle with mirroring.
I’m not really expecting an answer to this as we will only find out what those limits are by trying out various combinations in the real world and seeing what happens. I write it here as a concern merely because that’s what I started thinking about when I read Jordan’s example. At least it’s now a known unknown!
In conclusion - I’m sold on this idea now. I think this is a logical evolution for liquidity provision to take and, now that my concerns around it have been allayed, I’m excited by the technical challenges it presents. I’m going to crack on with implementing as many APIs as I can find.
) .