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

Liquidity Pools
#21

I’m sorry, you missed the restime -> reset_timer. I can try to add something into the code to accept both if you’d rather.

Oh, also I think we should go to 0.5 hr default reset.

#22

Doh!
Will fix that later…
…sed will do it in fact :wink:

Done: https://github.com/Lamz0rNewb/alp-collection/tree/nagalim

#23

hi, a question related to ask/bid sides.
i see sometimes that an ask or bid side vanishes while running an ALP pair.
do you advise to manually keep the balance of ask/bid sides (every now and then) or leave it to balance it self?

#24

That can happen due to volume beyond target - as far as I understand how ALP works…

#25

no, i didn’t mean due to spread value, i mean due to filling order :smile:
for example:
i bid 100 and i ask 100 (perfect balance)
the other day, i see that i bid 200 and no ask (due to filling ask order)
then should i let it as it is or should i do some manually balancing?

#26

This is one of the questions being discussed in several threads :wink:
You can try to balance your sides with other pools on other exchanges.
This is causing a “switching problem” :

That can only be resolved by buying NBT from Nu (in case there’s too little overall NBT bis liquidity) or selling NBT to Nu (in case there’s too much overall NBT bis liquidity).
It can be mitigated to some degree if tier 3 is used. But resolving it is only possible with tier 4 liquidity.
For an overview of the tiered liquidity model have a look if here, if you are not already familiar with it and don’t know what I’m referring to.

If you try to balance tier 1,2,3 with other pools all you do is pass the imbalance around.

1 Like
#27

thanks. i am afraid i don’t understand the part:
"That can only be resolved by buying NBT from Nu (in case there’s too little overall NBT bis liquidity) or selling NBT to Nu (in case there’s too much overall NBT bis liquidity)."
you mean using other exchanges that have sufficient liquidity?

#28

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.

#29

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

#30

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
#31

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.

#32

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…

#33

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 cryptsy

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

#34

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

#35

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.

#36

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
#37

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
#38

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)

#39

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
NuRiver Pool on Cryptsy for NBT/USD & NBT/BTC
#40

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.