Universal ALP bot collection - forked (and hopefully improved) @Nagalim edition :)

[seki]

who is “Nu”? how can i do that?

[masterOfDisaster]

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.

[Nagalim]

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.

[masterOfDisaster]

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.

Even furthering the derailing, but it’s just too good an opportunity for this plug:
there is a way to incentivize balancing:

Fixed total payout for liquidity providers to enhance liquidity security and pool operation

This post is to extend disucssions on "Fixed per-minute total interest payout" for liquidity pools here @Nagalim pointed out that I think the rollover money is a result of unfullfilled target. If a fixed per-minute interest is implemented, every pool will have to pay out a fixed amount of interest every month. Pools with less volume will get a proportional greater boost (they pay higher interest) compared with a pool with more volume, if they are granted with the same interest funding by…

The balance follows the ratio of the fixed amounts on buy and sell side that are granted by Nu for providing liquidity…

[masterOfDisaster]

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)

KNOWN ISSUES:
There’s some trouble with the NuRiver BTC bot that creates error messages like

`unable to place bid btc order of "X" nbt at "Y" on cryptsy: Insufficient BTC in account to complete this order.`

Repo will be updates as soon as a fix is available.

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 cryptsy

I will keep this in the “known issues” section, though.

[seki]

and it came again
something random! who knows!
keep the funds for hitbtc and southX

[Nagalim]

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.

[woolly_sammoth]

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

[masterOfDisaster]

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.

[zoro]

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)

[masterOfDisaster]

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.

[masterOfDisaster]

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.

[masterOfDisaster]

update:

• removed nupond_bter_btc_fix_payout_test because nupond_bter_btc is now fixed cost
• added southx usd trading bot

[Nagalim]

@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.

[Nagalim]

Latest push to my repo should work for bter, ccedk, bittrex, and poloniex. I did not test them all.

Nagalim/alp-collection

@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.

[masterOfDisaster]

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

[Nagalim]

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.

[mhps]

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.

[zoro]

Pybot has many bugs and i don’t think that they will ever be fixed since nubot for ALP is on its way

[Nagalim]

Fill amount is a hack job i did to simulate parametric order books, kind of. Anyway, like you said it fixes itself once the reset_timer times out.

If you have a better implementation, im all ears. Or just submit a pull request.