[Passed] NuPond Term 5 Fixed Cost Motion

NuShares Passed Grants
#37

I just informed myself of the meaning of fixed cost liquidity. I think it is simple and powerful. It is likely to become the dominant liquidity compensation model. I’m very happy to see it has a built in, simple and graceful method for lowering liquidity costs (on a per NBT of liquidity basis).

This is just an experiment, and it may need to be tuned. Still, this is cheap and important innovation.

I give this motion my strongest support, and urge all shareholders and data feed operators to give it serious consideration. @Nagalim would you consider giving a complete but simple explanation of what fixed cost liquidity is in the OP?

4 Likes
#38

Done. Thanks for the support.

1 Like
#39

Sorry for the delay in giving my feedback.
I never fully understood how the dutch auction worked inside the ALP rationale created by creon.
To me also, Fixed cost ALP’s concept is much simpler to understand.
I speculate that it would be also the case for anybody that wants to provide liquidity, therefore increasing the potential for NuNet to attract a much bigger liquidity.

187e547074c3fe0508a56d684dd705ec5d9929ee verified and voted.

Just a question. I remember that Creon’s ALP uses pybot as its default bot program.
Is it also the case for FC ALP and if yes, why not using NuBot?

1 Like
#40

At the moment you can only use NuBot if you control the funds, you’d need to run an MLP, which is something completely different and requires either using own funds or account management.

ALP doesn’t require control over the funds (by the pool operator) that are used for liquidity providing.
The parts of the ALP software (server.py) that needed to be adjusted to make fc_server.py were small (on client side there’s no change required!):

diff server.py fc_server.py
39,40c39,40
< _wrappers = {'bittrex': Bittrex, 'cryptsy': Cryptsy, 'poloniex': Poloniex, 'ccedk': CCEDK, 'bitcoincoid': BitcoinCoId, 'bter': BTER,
<              'testing': Peatio}
---
> _wrappers = {'bittrex': Bittrex, 'poloniex': Poloniex, 'ccedk': CCEDK, 'bitcoincoid': BitcoinCoId, 'bter': BTER,
>              'testing': Peatio, 'cryptsy': Cryptsy}
141c141
<     def liquidity(self, bid, ask):
---
>     def liquidity(self, bid, ask, identifier):
146a147,150
>
>         tier:pair:exchange:botsessionid
>
>         Example of a valid identifier : 2:BTCNBT:ccedk:nubotsession3
149,150c153,155
<             self.rpc.liquidityinfo('B', bid, ask, self.address)
<             self.logger.info("successfully sent liquidity: buy: %.8f sell: %.8f", bid, ask)
---
>             self.rpc.liquidityinfo('B', bid, ask, self.address, identifier)
>             self.logger.info("successfully sent liquidity: buy: {0} sell: {1} "
>                              "identifier: {2}".format(bid, ask, identifier))
153c158
<             self.logger.error('NuRPC: client not initialized')
---
>             self.logger.error('NuRPC: liquidity client not initialized')
471c476
<                     maxrate = config._interest[name][unit][side]['rate']
---
>                     # maxrate = config._interest[name][unit][side]['rate']
481a487
>                     imprate = float(config._interest[name][unit][side]['rate'])
482a489
>                         maxrate = imprate * 10000000 / mass
599c606
<     curliquidity = [0, 0]
---
>     curliquidity = {}
602a610,614
>             exchange = repr(keys[user][unit].exchange)
>             if exchange not in curliquidity:
>                 curliquidity[exchange] = {}
>             if unit not in curliquidity[exchange]:
>                 curliquidity[exchange][unit] = [0, 0]
604,605c616,621
<                 curliquidity[0] += sum([order[1] for order in keys[user][unit].liquidity['bid'][-(s + 1)]])
<                 curliquidity[1] += sum([order[1] for order in keys[user][unit].liquidity['ask'][-(s + 1)]])
---
>                 curliquidity[exchange][unit][0] += sum([order[1] for order in
>                                                         keys[user][unit].liquidity[
>                                                             'bid'][-(s + 1)]])
>                 curliquidity[exchange][unit][3] += sum([order[1] for order in
>                                                         keys[user][unit].liquidity[
>                                                             'ask'][-(s + 1)]])
607,609c623,631
<     curliquidity = [curliquidity[0] / float(config._sampling), curliquidity[1] / float(config._sampling)]
<     _liquidity.append(curliquidity)
<     nud.liquidity(curliquidity[0], curliquidity[1])
---
>     for exchange in curliquidity:
>         for unit in curliquidity[exchange]:
>             liquidity = [curliquidity[exchange][unit][0] / float(config._sampling),
>                          curliquidity[exchange][unit][4] / float(config._sampling)]
>             _liquidity.append(liquidity)
>             identifier = "1:{0}:{1}:{2}".format('NBT'+unit.upper(),
>                                                 exchange,
>                                                 config._pool_name)
>             nud.liquidity(liquidity[0], liquidity[1], identifier)
788c810
<             if curtime - lastsubmit >= 60:
---
>             if curtime - lastsubmit >= 5:
1 Like
#41

I see. Do you remember the difference between PyBot and NuBot?
I suppose FC ALPs will be using something close to PyBot but in that case how can the parametric order book that will be implemented in the next NuBot version be implemented and used?

#42

Does this help?

1 Like
#43

NuBot is currently only working for MLPs (e.g. NuLagoon; soonTM maybe my NuBot on hitBTC).
PyBot is currently only working for ALPs.

NuBot has been soundly developed ever since development was started.
PyBot is hacked together code (correct me if I’m wrong) that acts as a proof of concept for an ingenious concept, invented by @creon: the automated liquidity pools (formerly known as TLLP - trustless liquidity pools).

NuBot requires a lot of CPU power.
[edit] But as I found out a few minutes ago: only if being run in server mode; without server mode CPU load looks like thison my RaspberryPi 2 (4 CPU cores):

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
22483 pi        20   0  321m  60m  10m S 101.8  6.2   9:14.09 java
 2337 pi        20   0  680m 559m  32m S  32.7 57.5   5357:27 nud

If you don’t need the server mode (maybe because you run it on a headless RaspberryPi…), NuBot is more CPU friendly than with server mode and can run very well on RaspberryPi 2,maybe even on a RaspberryPi 1 (although that’s close to the limit of it)!
[/edit]
PyBot doesn’t require much CPU power.

Exactly that - with an adjusted server.py that’s called fc_server.py.

@woolly_sammoth is working on a solution that will integrate NuBot into the ALP client:

That should give ALP clients the same features NuBot has.

If you intend to run NuBot on a RaspberrPi, I recommend to get a RaspberryPi 2. The CPU load NuBot causes is at average on 75% on a RaspberryPi 2.That means 3 of 4 cores are constantly busy.
Here’s output from top:

top - 06:53:04 up 8 days,  9:26,  2 users,  load average: 5.16, 5.21, 5.14
Tasks:  91 total,   1 running,  90 sleeping,   0 stopped,   0 zombie
%Cpu(s): 67.0 us,  3.1 sy,  6.6 ni, 21.7 id,  1.4 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem:    996848 total,   982224 used,    14624 free,    52212 buffers
KiB Swap:   102396 total,     1540 used,   100856 free,   191224 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
 2929 pi        20   0  338m 132m  11m S 277.4 13.6   2245:14 java
 2337 pi        20   0  680m 564m  37m S  28.0 58.0   4120:01 nud

You could move nud to a different machine to reduce some CPU load (nud is required for broadcasting liquidity information into the network).

PyBot on the other hand causes single digit CPU loads:

top - 06:49:33 up 26 days, 14:26,  2 users,  load average: 1,64, 1,41, 1,42
Tasks:   7 total,   0 running,   7 sleeping,   0 stopped,   0 zombie
%Cpu(s):  4,2 us,  2,8 sy,  1,8 ni, 91,0 id,  0,0 wa,  0,0 hi,  0,3 si,  0,0 st
KiB Mem:    998176 total,   974844 used,    23332 free,    17308 buffers
KiB Swap:   102396 total,     7028 used,    95368 free,   145900 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
26259 pi        20   0 64036  10m 5912 S   4,7  1,1 125:46.88 python
22490 pi        20   0 63832  10m 5968 S   4,0  1,1  18:00.29 python
1 Like
#44

socket error (111)

any change?

#45

The server kills itself every night because I don’t have nud on. I’ll restart it tonight. This will not be an issue once I’m operating on nupond instead of a test server.

#46

Tks for the tip about Pi.
So right now more than half of the liquidity is provided by a bot behavior different from NuBot. Doesn’t make NuBot as half
Valuable? If Pybot is lighter than Nubot, doesn’ t it make Pybot more efficient than Nubot and shouldn’t it make it the main bot?
I m trying to see to which extent Nubot is crucial to Nu.
I guess the answer is in the parametric order book…

#47

Pybot is a server-client pair. Nubot is everything in one. They are different programs with different goals in mind, and both are useful if not vital to Nu.

1 Like
#48

I’m very happy to finally see this idea articulated well and so I am voting for this proposal. I suggested the beginnings of a similar idea back in March but this is more relevant as I was considering the operator fee and requested funds as the same amount.

This is a superior method of purchasing liquidity that will balance liquidity targets and encourage lower interest rates.

#49

Thanks for bringing this interesting discussion up. I think given long enough time and a static boundary condition all models will converge to the same interest rate. The feedback loop of the fixed cost scheme is much shorter, making price discovery much faster, giving us a more agile system in a volatile market.

1 Like
#50

If this succeeds and reduces costs in the long-term, credit is due to yourself, Nagalim, Masterofdisaster, and all others who brought the idea to life here: Fixed total payout for liquidity providers to enhance liquidity security and pool operation.

1 Like
#51

running the test client again

#52

@assistant motion vote 187e547074c3fe0508a56d684dd705ec5d9929ee

#53

Hi @cryptog

Here are the details for the Motion Vote on 187e547074c3fe0508a56d684dd705ec5d9929ee:

##187e547074c3fe0508a56d684dd705ec5d9929ee
Blocks: 604 (6.040000%)
Share Days: 243446099 (7.048140%)

#54

Vote for this only if you think fixed cost should be explored experimentally using shareholder funds. It will not affect the total requested funds of NuPond Term 5, but is only proposing an alternative reward protocol, and only on the NBT/BTC pair.

1 Like
#55

Voted

1 Like
#56

@assistant motion vote 187e547074c3fe0508a56d684dd705ec5d9929ee