I definately have you in my logs. Do you have NBT or BTC on Bter? Is the bot putting up orders?
sorry , my bad , only have CNY . exchange into NBT and restart now , it is OK now.
thanks for your help!!
1 Like
I want to be clear here. If shareholders fail to vote for this motion, it will not necessarily defund NuPond on the BTC pair. This motion is specifically aimed at gauging shareholder support for fixed cost pools.
no payment if fail voting?
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