[Voting] Dual side NuBot gateways at multiple exchanges - masterOfDisaster

Hash: 7b61108ab5d94b2830f5fac226a9a2f1ca9a67ba

I don’t want to be a (benevolent) dictator and don’t want to be perceived as such.

Here’s a draft quoted from https://daology.org/proposals/d77faa99301af795fe6b3c1c8e3193906dbd359a
Please discuss.
I’m aware that a lot is fuzzy.
But I’m sure wee need to keep a lot of flexibility.

1 Like

Very good. Before we can automate a gateway with usd reserve, we should experiment with manual operations to get proper parameters,

Automating a gateway will require reworking NuBot.
How much depends on how NuBot works in such an environment.
At least the wrappers need to be updated.

If you operate two NuBots on the same account, but with different API credentials, it might be possible to have one

  • trade only on the NBT/BTC pair and the other NuBot
  • trade only on the BTC/USD pair (in case you want to convert some BTC to USDT)

It would be useful, that they can’t delete the orders of each other when shifting walls, but only move their own orders.
I don’t know how deleting orders works.
If it’s related to the account, it won’t work this way.
If it’s related to the API credentials, it should work.
The fallback option would be to synchronize the order shifts. As they are triggered by a change of BTC price, it should be possible to synchronize them via


configuration parameter.

It’s further required to have a corridor between a “reserve” value parameter and a “lower limit” parameter
The “reserve” prevents BTC funds from being traded to USDT; this way you can keep, say $5,000 in BTC on T2 to have it ready for trades.
The “lower limit” starts trading USDT for BTC, once the BTC on T2 start to run low.

Summarizing this:
as soon as BTC/USDT is supported by the NuBot wrapper on Poloniex, we can start testing :wink:

i don’t think it has to.


  1. shut down the nbt/btc bot and the orders get deleted.
  2. start the btc/usd bot with a shift that accelerates selling btc. Use nagalim’s bot to sell only a fraction of btc into usd.
  3. shut down btc/usd bot and restart nbt/btc bot.

you just need a bot, and a shell script that shuffles two config files.

Ideally both bots would run at the same time and an overflow of BTC gets automatically traded to USDT, while USDT get traded back to BTC once BTC funds run low.
Doing it manually is of course possible and would be the first step of playing with it.

Poloniex has no BTC/USD, only BTC/USDT. I think we need an adjusted wrapper, but I don’t know how to investigate wrappers for supported trading pairs.

Can we use the BTC/USD price feed for trading on BTC/USDT?
That might be risky, but I’m not aware of a feed for BTC/USDT.

This discussion would better be continued in

I hope I get some feedback on the motion soon, because I don’t want to wait very long until I promote it to [Voting].

No maximum of funds on each exchange? I hope you are not going to make the same mistake with huge Nu reserves on exchange. If anything it should be spread across exchanges evenly in order to spread the risk and capped.

There is also no indication regarding offsets. I appreciate market awareness but by who. You only?
Still looking to some oversight/governance. Can we have FLOT voting at least?

I’m rather trying to follow my propsal I described in the thread about the paradigm shift.

I know that this proposal is quick and dirty - maybe too much of both of it.

The truth is: I have no idea, where to put the limits.
Voting on a change might come to late.
Even if I can adjust them by my own discretion, I might come too late.
If people decide, they rather sell NBT at $0.925 than keep them, I might not recognize it, until it’s too late to increase the offset of the last last line of peg support.
Voting doesn’t make that better.

That’s why we need automatic market awareness.

Fixed Cost scheme that gives more reward to smaller spread is the quickest market awareness – it is a set of rules in LP’s mind; it excerts effectiveness at the same moment market changes happen.

To spell it out, for every minute

a LP’s reward = Fixed_Total_Reward * liquidity / offset / SUM_OF_EVERYONES(liquidity / offset)

The less liquidity, the more a LP showing up with fund will be rewarded; for the same amount liquidity provided, thoese with smaller offset will get more reward proportional to 1/offset.

A minimum offset and maximum offset can be given to remove extremes.

Promoted to [Voting].
Hash 7b61108ab5d94b2830f5fac226a9a2f1ca9a67ba