Time for a change in liquidity provision?

NuShares
#1

Considering the trade volume on Bittrex

Pasted image1387Ă—711 71.7 KB

I want to ask whether Nu really wants to continue an ALP operation there.
The compensation of the NuPool Bittrex ALP is not far from the trade volume there.

The transition to a new liquidity provision scheme that differentiates between fully supported (ALP + MLP [e.g. dual side NuBot with Nu funds, NuLagoon]) exchanges and sell side only exchanges needs some preparation, though.

I think a motion is required to evaluate the current situation and make a plan for a transition.
Before I draft a motion body, I want to test the waters to find out whether there’s interest in taking such a route or not.

I guess the bter and ccedk operations need to have continued ALP support, because they connect Nu to chinese traders and offer fiat pairs.
SouthXchange has little volume, but supporting it is very cheap and it offers a fiat pair as well. The BTC/NBT pair there might be fine with a sell side only bot.
Poloniex is at the moment the US-NBT exchange when measured in volume.

I doubt that ALP/MLP support for Bittrex and hitBTC are useful (as far as I’m aware of, there’s currently no support for hitBTC at all) and should be replaced by sell side only NuBots.

Further I think the Poloniex ALP volume can be reduced. History showed that in times when ALP is most needed, it isn’t reliable.
LP might make the rational choice during the next heavy BTC price swing again and pull their funds.
It’s not necessary to offer compensation for up to $20,000 on each side if you can’t rely on them and don’t need them in normal times.
CRFC might be able to mitigate the low reliability of ALP, but

  • the NuBot integration of ALP isn’t complete
  • even then a target of $20,000 on each side at Poloniex seems to be too much (read: too expensive)

###Mile stones could be:

  • advertize a change of liquidity provision:
    major exchanges like Poloniex and NuLagoon tube are the only officially supported exchanges where the peg is ensured by Nu and where both buying and selling US-NBT is supported; other exchanges might have (limited) sell side support. They are not the recommended places to buy and sell US-NBT.
  • find an operator (or operators) for sell side only NuBot/PyBot on at least
  • Bittrex (NBT/BTC)
  • hitBTC (NBT/BTC)
  • CCEDK (NBT/BTC)
  • CCEDK (NBT/PPC)
  • southXchange(NBT/BTC)
  • find an operator (or operators) for dual side NuBots on
  • Poloniex (BTC/NBT); currently supported by @zoro, @nagalim, @masterOfDisaster (until forther notice for emergencies only)
  • reduce Bittrex ALP compensation to e.g. $1,000 each side
  • reduce Poloniex ALP compensation to e.g. $6,500 each side
  • gather experience with sell side only operations; this includes
  • scheduled refills
  • standardized reporting
  • scheduled accounting and withdrawals
  • end ALP support for
  • Bittrex (NBT/BTC)
  • hitBTC (NBT/BTC)
  • CCEDK (NBT/BTC)
  • keep ALP support for each fiat pair (doing that with a dual side NuBot is hard because of the KYC, AML policies) and for Poloniex (until Poloniex gets replaced or complemented as the major US-NBT exchange)
6 Likes
#2

Id love to provide on bittrex. I can drastically reduce compensation over nupool by using a small fixed cost like 5 nbt/side/day for a total of 300 nbt/month + 50 operator. This is a 50% reduction in operator fees and a 58.33% reduction in pool support.

3 Likes
#3

I am for such change on a trial basis. We should write down how much liquidity we provide at what cost now, make the transition, then compare the results 3 months later.

2 Likes
#4

There was never ALP support for those pairs.

1 Like
#5

Thanks for that comment!
I’ll adjust the OP, although the mile stones are more a kind of draft than a reliable project plan.
I was just trying to sketch a possible way to try something new and hopefully more reliable and cheaper.

1 Like
#6

and how about bter.com?

#7

Here

#8

thanks , i will run a nubot at bter soon.

#9

I’m thinking about this for a while now.
I’d like to do it in “NuLaw” style, but I fear I’m too early for it.

I intend to run a sell side NuBot at more or less every exchange (or at least a lot of them) that is supported by NuBot wrappers.
This is my plan:

  • My offer will be dirt-cheap (at least I hope so).
  • I will only passively operate the NuBots (I won’t check the liquidity).
  • I will only withdraw funds once a week or even more rarely and I won’t do any accounting more often.
  • I expect only as few funds as possible to be sent by FLOT, although I can’t hinder them from doing otherwise.
  • I will provide a thread with an overview of deposit addresses, NBT broadcast address etc.
  • I will use the the same NBT address to broadcast liquidity for all operations for the sake of simplicity. I think each operation can still be checked by looking at the NuBot session ID, although it might be less convenient than having a separate NBT address per operation. NuBot automatically broadcasts the exchange name together with the session ID (e.g. “1:NBTBTC:poloniex:0.3.2a_1452979035944_3152f8”).

Each of the points is subject to negotiation.
The fee I’m going to charge will depend on the effort I’m going to have.
I intentionally have left out numbers.
I want to have some feedback first.

2 Likes
#10

Will you use one Rpi2 for every nubot or one big rig for all of them? (i think the latter is more efficient and cheaper for NU although introducing a single point of failure for all!)

1 Like
#11

I expect to run two RPI2 with nud 2.1.1 (because of the reduced RAM consumption) and UPS.
Each RPI2 should be able to run 3 or 4 NuBots.
I will add a redundant internet uplink via cellular radio.

Hosting the NuBots on RPI2 is cheaper than on any other hardware (purchase costs, operation costs) and more secure than on VPS. I don’t trust VPS providers with the private keys of the NBT addresses that are required to broadcast liquidity.

#12

I think it is due to the possibility of messing up nubot’s configuration. The nu addresses for liquidity purposes could have 0 nbt inside or not?

#13

That’s not the problem.
Broadcast address private keys in the wrong hands can be abused to mess up the reported/broadcast liquidity.
Thanks to @willy and ALix we have a tool to make a reality check!

1 Like