[Passed] NuPond Term 5 Fixed Cost Motion

NuShares Passed Grants
#27

What is NSR holders stopping from voting for this grant?

@assistant motion vote 187e547074c3fe0508a56d684dd705ec5d9929ee

Fixed cost pools will be nothing short of a small revolution in liquidity providing.

The fixed cost concept can very well be adapted to running multiple NuBots at the same exchange and even a combination of NuBots and an ALP at the same exchange.

With fixed cost liquidity operations the world can be told how much liquidity providing at a particular exchange or pair is worth to Nu.
Let the fight for a piece of the cake, that liquidity providers will then lead, begin!

Example: Poloniex liquidity will be announced to receive in total 2,500 NBT per month.
It will be very attractive for liquidity providers to get a piece of that cake. Providers will compete for a piece of the compensation with higher volume and lower operator fees than already proposed grants until a point is reached from which no more volume and cheaper operator fees can be afforded.
It will be especially nice to have fixed cost ALP and NuBots in parallel at the same exchange and pair, for the ALP compensation rate will raise the bar for the NuBot efficiency (economically speaking).
A side effect will be an increased decentralization, if the same exchange/pair is supported by different liquidity operations.

Fixed cost liquidity operations are an impressive way to lower the liquidity costs.

Fixed cost ALP can be used to determine the compensation rate for which liquidity providers will do a job. This is especially important for new exchanges and new operations.
From that rate Nu can derive how much compensation is required to have a desired liquidity volume at the exchange.

I seriously thought this motion to test the fixed cost operation were a no-brainer. What did I miss?

2 Likes
#28

Hi @masterOfDisaster

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

##187e547074c3fe0508a56d684dd705ec5d9929ee
Blocks: 6 (0.060000%)
Share Days: 1294696 (0.037405%)

#29

voted.
it seems only you, me and nagalim vote for it :smiley:

#30

I don’t know who votes for it, but I think this motion deserves more support.

Especially after [Withdrawn] Motion to lower compensation for NuLagoon sell side was made to lower costs with a sledgehammer approach.

I perceive the fixed cost approach as more sophisticated as it doesn’t dictate liquidity providers conditions.
They are offered a compensation instead and need to tell Nu how much they will offer for receiving the compensation or a part of it.
Free market will make ensure that Nu will get the best deal for the provided compensation.

#31

Should I make this a grant? Would that make people vote for it more for some reason or another? I was hoping to keep it synchronized with the CNY pool because fixed cost pools are expected to have vastly fewer rollover funds and timing of the grants will start to become much more important.

#32

I don’t know.
Maybe you wait for the outcome of my shameless plug…

#33

@cryptog and @Cybnate please consider voting for this pioneering motion or I will have to stop subscribing from your feeds. Just let you know as a subscriber.

1 Like
#34

…or at least provide a reasoning for not doing so…

#35

It takes time for ideas to sink in. I am glad that front line dev team members @willy supports it and @woolly_sammoth considers it a fairer system and implementing it. So the idea is not only endorsed by we liquidity pool operators and providers.

2 Likes
#36

I have been very busy at work recently. Could not find the time to read through everything…I am digging into the thread right now…And will update my feeds very soon.

1 Like
#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…