No, that will not help.
If the liquidity is imbalanced network wide you can only balance it with Nu:
by trading NBT with Nu - buy NBT from Nu or sell NBT to Nu.
who is “Nu”? how can i do that?
This is starting to derail the thread, but since you asked:
“Nu” is the Nu network, represented by the NSR holders.
One way to make that happen would be ongoing seeded auctions.
As long as there are funds in tier 2 and 3 to balance, liquidity providers might use those layers.
Looking only at tier 1 or tier 2 and 3 as well is a matter of discussion.
But whether you count only tier 1 or tier 1-3 you can look at the liquidity situation of Nu.
You calculate the network wide liquidity of all ALP and MLP operations compensated by Nu.
If there’s need to balance liquidity, seeded auctions might come into play:
- in times of more buy side liquidity NBT were offered by multi signature custodians who sell the NBT on behalf of “Nu”. In those auctions the NBT (from Nu) are traded for NSR (from LPs or Nu customers).
- in times of more sell side liquidity NSR were offered by multi signature custodians who sell the NSR on behalf of “Nu”. In those auctions the NSR (from Nu) are traded for NBT (from LPs or Nu customers).
To get an understanding how seeded auctions work, please have a look at its predecessor unseeded auctions.
2 Likes
In my opinion, the answer for ALP is do whatever gets you paid. If you find all your funds are sell side but you’re still getting full compensation, leave it. If one side’s at target and the other side isn’t, arbitrage off another nbt pool that is unbalanced the other way. If all pools are having the same problem then the shareholders need to step in like MoD was saying.
The cny pool on bter has 4000 buy and only 1000 sell right now, just so y’all know.
Even furthering the derailing, but it’s just too good an opportunity for this plug:
there is a way to incentivize balancing:
The balance follows the ratio of the fixed amounts on buy and sell side that are granted by Nu for providing liquidity…
Trouble with (at least) the “Universal ALP bot collection” running on cryptsy.
More information here: NuRiver Pool on Cryptsy for NBT/USD & NBT/BTC and in the subsequent posts.
I added a “KNOWN ISSUES” section to the initial posts until that is fixed (and that hopefully stays empty for most of the time)
edit: and it’s gone just like it came - the bot kept running and I recognized it’s placing orders again:
2015/09/24-15:28:36 INFO: price of btc moved from 0.00428807 to 0.00427917, will try to delete orders on cryptsy
2015/09/24-15:28:39 INFO: successfully deleted all orders for btc on cryptsy
2015/09/24-15:29:09 INFO: successfully placed bid btc order of "X" nbt at "Y" on cryptsyI will keep this in the “known issues” section, though.
and it came again 
something random! who knows!
keep the funds for hitbtc and southX 
BTW, @woolly_sammoth I noticed that that ‘if’ statement that inludes a logger.info saying ‘decreasing bid limit’ activates whenever rate is zero, even when we don’t want it to. It’s trying to tell if the rate is less than the user set ‘interest’ but when 0 liquidity is placed the rate is 0% and it triggers this statement. To fix it (I think) I added an ‘and’ to the conditional that rate needs to be >0 before it starts decreasing limits. I’m fairly certain this will have unintended consequences, but I think those are negligible compared to how much better the performance is with this adjusted conditional.
Thanks for the look @Nagalim. I’ve been very cautious about changing anything in that area of the code. As you say, it tends to have unintended consequences in tests. The >0 conditional does make sense though. I’ll take another look with that in mind
1 Like
Update:
An update was pushed to the cryptsy wrapper following the latest changes in https://github.com/inuitwallet/nu-pool/blob/extra-cryptsy-logging/python/exchanges.py#L330.
The update aims at solving issues with placing orders at cryptsy via API.
It appears like changes in cryptsy’s fee structure caused the trouble.
Thank you, @woolly_sammoth for (hopefully!) resolving this issue.
Only https://github.com/Lamz0rNewb/alp-collection/tree/experimental-0.51 contains this adjustment until further tests have shown that it’s safe to apply it to the other branches as well.
1 Like
i am getting the same “insufficient…” message but after a while i see the orders in place and ‘balance’ increasing!
(without any message that orders are indeed placed)
This is because the bot first try to place an order at full height and if that fails a fallback mechanism kicks in that puts only 99% of the available fund in the order book.
1 Like
The latest commit on https://github.com/Lamz0rNewb/alp-collection/tree/experimental-0.51 adjusted the bot for the fixed cost test run on bter, because the operation is on the btc and not on the cny pair.
update:
- removed nupond_bter_btc_fix_payout_test because nupond_bter_btc is now fixed cost
- added southx usd trading bot
@masterOfDisaster and my repository are merged at this point. When I pulled in some of the changes @woolly_sammoth made, one of them was a change of the way the bot auto-restarts. I am not satisfied with the new implementation and plan to revert back to the old one. The new restart does not seem to actually reset all the values, so my bots often end up getting stuck even through a bot restart.
Latest push to my repo should work for bter, ccedk, bittrex, and poloniex. I did not test them all.
@masterOfDisaster I’m hoping someone will test some of this, then it would probably be ideal for you to pull these changes into your branch.
3 Likes
I will do that. I hope I can test some of it myself. But currently I’m busy trying to do my part to keep the peg.
Sound like drama?
Sometimes feels like it
Yah, i was kinda hoping others would do the testing. I know no one’s using it on ccedk cause none of the spreads changed. Dont take too much on yourself, we need you healthy wealthy and wise.
1 Like
Where is the official place for discussing alp-colllection?
If I set 100 as fillamount on ccedk nbt-usd and let it run, and I have 45.678 balance left. then i set fillamount to 50 to another bot on nbt-eur, sometimes the bot places 50-45.678=4.321 order.
I think it’s from
empty = ast.literal_eval(self.fillamount)[‘ask’] - fullask
in trading.py, when fullask=45.678 from previous minute. But I don’t know exactly why.
the problem never shows if i don’t use fillmount, and seems to fix itself after a while.
Pybot has many bugs and i don’t think that they will ever be fixed since nubot for ALP is on its way