Does that mean you convert the compensation for liquidity contributions based on the log files to the standard model in the case this motion fails?
I sincerely hope this motion succeeds, because the potential of fixed cost pools is tremendous.
Either 1) this motion passes or 2) this motion doesn’t pass or show support within some reasonable time frame.
-
I will set up everything for fixed cost and submit the home pool grant with fixed reward for the CNY pool. This grant will contain the 450 NBT requested for term 5 in this motion, as well as any rollover funds and so on and so forth. Once I’m confident I have the funds (and the shareholder support) to begin fixed cost I will. The exact timing will be fuzzy, but as we are not in an official periodic operator competition anyway the timing is assumed to be fuzzy. As this will be done as an upgrade to the current pool, there will be only seconds of downtime and no chance for the operator to unfairly take funds on an empty pool.
-
I will propose a standard NuPond term 5 grant. This grant will be fixed reward for both the CNY and the BTC pool.
1 Like
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
Here are the details for the Motion Vote on 187e547074c3fe0508a56d684dd705ec5d9929ee:
##187e547074c3fe0508a56d684dd705ec5d9929ee
Blocks: 6 (0.060000%)
Share Days: 1294696 (0.037405%)
voted.
it seems only you, me and nagalim vote for it 
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.
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.
I don’t know.
Maybe you wait for the outcome of my shameless plug…
@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
…or at least provide a reasoning for not doing so…
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
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
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
Done. Thanks for the support.
1 Like
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
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
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?
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 nudIf 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?