[Passed] NuPond Term 5 Fixed Cost Motion

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?

Does this help?

1 Like

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

socket error (111)

any change?

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.

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ā€¦

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

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.

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

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

running the test client again

@assistant motion vote 187e547074c3fe0508a56d684dd705ec5d9929ee

Hi @cryptog

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


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


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

Voted

1 Like

@assistant motion vote 187e547074c3fe0508a56d684dd705ec5d9929ee

Hi @huafei

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


##187e547074c3fe0508a56d684dd705ec5d9929ee
Blocks: 820 (8.200000%)
Share Days: 320881621 (9.325522%)


@assistant motion vote 187e547074c3fe0508a56d684dd705ec5d9929ee

Hi @cryptog

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


##187e547074c3fe0508a56d684dd705ec5d9929ee
Blocks: 1630 (16.300000%)
Share Days: 669965972 (19.597495%)


@assistant motion vote 187e547074c3fe0508a56d684dd705ec5d9929ee