[ANN] ALix BETA - Exchange volume based automated liquidity index

Liquidity Pools
#1

ALix BETA

from
https://www.coinerella.com/index.php/ALix

What is ALix?

ALix, the
Derived from the words “automated liquidity” and “index”
Is an API feed service for NuBits, currently in beta.
It calculates the average trading volume of a trading pair (NBT/X, X/NBT) and displays this in different time frames.

What’s it for?

Well, that’s up to the community. I imagine this to become a major part of T1 liquidity distribution, mainly for ALPs.
The idea behind it: Have the liquidity where the trade volume is.

Quick example:
NuPool needs to find out which liquidity targets to choose for the next period.
Sam and I would look at the ALix values for e. g. 30 days (which will be available soon) on the Bittrex and Poloniex pairs and we would have a good idea what happened on the trading pair, volume wise.
We can take this into calculation, might lower our targets after all and would thus reduce costs for Nu.

Upcoming:

  • DONE: further improved resilience for data collection
  • 30% DONE fancy charts
  • DONE: more pairs
  • more time frames (90 left)

What’s after the Beta?

If this beta is a success, I’ll draft a custodian grant request to get a six month contract for providing this feed.
This draft will include a high availability server structure.

ALix might seem simple at the moment, but it took me a lot of working hours (nearing three digits) to get a functional beta, which I’m confident to present to the community. I hope you find it useful.

Documentation

Available methods:

VOLUME

pairs_available
https://alix.coinerella.com/volume/?pairs_available

Returns all trading pairs currently supported by ALix.
Example:

{"error":"false","available":[{"pair":"poloniex_btc_nbt"},{"pair":"bittrex_btc_nbt"}]}

frames_available
https://alix.coinerella.com/volume/?frames_available

Returns all time frames currently supported by ALix. Time frames are measured in seconds.
Example:

{"error":"false","available":{"86400":"1","259200":"3","604800":"7"}}

pair
https://alix.coinerella.com/volume/?pair=**x**&frame=**y**

Returns the ALix data for the requested pair X in time frame Y.
Example: https://alix.coinerella.com/volume/?pair=poloniex_btc_nbt&frame=7

{"error":"false","pair":"poloniex_btc_nbt","frame":"7","volume":"74084.68313822","columns":"7","alix":"10583.526162603"}

Note: The “columns” value shows the number of stored data arrays for the pair in said time frame and is currently used for debugging purposes only.
We check whether our gathered data doesn’t contain more than one data array per day.
In this example the total volume for 7 days was 74084.68313822. This value is divided by the number in the “columns” value, which should be identical with the “frame” value, to get the “alix” result.

WALLS

New in the beta:

https://alix.coinerella.com/walls/ with 15 minute moving average

https://alix.coinerella.com/walls/?4h with 4 hour moving average

Graphic overview of the current liquidity.

Want the raw data?

Current data: https://alix.coinerella.com/walls/?json
15min moving average json: https://alix.coinerella.com/walls/?json15min
4h moving average json: https://alix.coinerella.com/walls/?json4h

Provides the current t1 buy and sell walls on the pairs with 1.5 tolerance from the last bitstamp/bitfinex/coinbase price (fail over in that order.) Updates every minute.

Example:

{“timestamp”:1446214562,“btc_usd”:“322.39”,“exchanges”:[{“pair”:“poloniex_btc_nbt”,“amount”:{“tolerance”:“1.5”,“ask_total”:19531.08521977,“bid_total”:32229.36249618}},{“pair”:“bittrex_btc_nbt”,“amount”:{“tolerance”:“1.5”,“ask_total”:9197.12037344,“bid_total”:7246.15995558}}]}

Happy to hear your feedback on this!

8 Likes
[Draft] FLOT and T4+6 - masterOfDisaster edition
#2

At first glance: impressive!
Will have a closer look :wink:

First question: is it possible to display the liquidity information that is broadcast by a specific address?

#3

First answer ;): Yes, it is. But currently not for ALix.
ALix is working with the exchange APIs, not with nud.

The broadcasted liquidity is shown in debug.log btw.

1 Like
#4

Gathering liquidity information from the debug.log is less convenient than e.g.

https://alix.coinerella.com/?broadcastAddresses_available

and

https://alix.coinerella.com/?broadcastAddresses=**x**&frame=**y**

if you know what I mean :wink:

#5

Ah, I see what you’re heading for.

Well, I can give you the liquidity history at least for the ALP based liquidity providers. That’s actually what @thecrema is working on at the moment.
He’s not using the broadcast address for that though, but the /exchanges history.

Unless I’ve missed something, anyone with a valid grant address can propagate random liquidity amounts. It’s not a value I would overly trust at this stage, so… not something for ALix at the moment, but we will soon deliver something very similar to your request on Raw.coinerella.

#6

Very useful service indeed!

While this can be a good general guideline, we should also factor in other things : I give you a simple example : often historic volume is low BECAUSE of low liquidity, not the other way around. Bring liquidity, then the volume kicks in.

That’s generally true for new pairs.

I would look at another metric personally, computed starting from both t1 liquidity on that pair (call it t1(frame) ) and historical volume in that time frame ( vol(frame) ) .

t1(frame) should be used to weigh the output. Zero liquidity provided? Then it’s ok to expect zero or low volume…

Etc …

I hope my example is clear, please let me know if more is needed

EDIT:
Basically, we should be looking at disproportions : is there any place where we are providing high liquidity and we are recording low volume? withdraw. Is there any place where volume is high and liquidity provided is low? bring it in

#7

Question : do you expect ALP server or NuBot/TLLP clients to consume your service?

Because I thought this service should be somehow integrated and deployed on the same infrastructure where currently the price streaming server is (right now just a load balancer and a couple of machines behind it) …

But I am open to using other servers. There’s no real need of a push architecture via websockets in this case, and a pull can work perfectly.

In NuBot roadmap, very soon there is an item called

Liquidity balancing across markets

Which aims at doing exactly the kind of logic we are discussing here. I did not started any implementation and I will be more than happy to consume “third party” services to access information necessary to take decision.

Just wanted to make you aware of it and invite you to collaborate on this, because I think nubot will be your first customer :slight_smile:

#8

There’s also a concept of the rate we are paying for the liquidity, especially if pools switch to fixed-cost models, but even in the dutch auction model. The real metric should be (trade volume per day) / (NBT paid to LPs during that day)

#9

I can only talk for Bittrex here, since I was monitoring the liquidity there closely due to NuPool:
Despite a few larger transactions (~3k NBT once in a while) it far underperformed, compared 25k and more of liquidity on the pair. I’m confident in saying that, at least for Bittrex, your claim is not 100% true.
… By the way, I can’t remember seeing anyone complain about too low walls on a pair yet via the various channels available (this forum, twitter, gitter…)

But I get what you mean. We are definitely in need for a sophisticated liquidity prediction method.

Yes. I was briefly talking to Sam about this. I hope it will be useful!

I’m glad to hear that, since I’m no friend of single point of failures.

1 Like
#10

People have complained about lack of sellside liquidity on fiat pairs more than btc pairs.

1 Like
#11

With my examples I wanted to show you that for sure, volume alone, is not a good proxy of where liquidity provision should be directed.

#12

Yeah. That’s right.
Those situations were 0% ask filled, >100 bid filled, right?
Nothing an index would be needed for as the demand is very obvious.

1 Like
#13

Changes October 23rd, 2015:

“available”:[{“pair”:“poloniex_btc_nbt”}
formerly
"0":[{“pair”:“poloniex_btc_nbt”}

I will also enable the following pairs in the next couple of days:

  • southx_btc_nbt
  • southx_nbt_usd
  • cryptsy_nbt_btc
  • cryptsy_nbt_usd
  • bter_nbt_cny
  • bter_nbt_btc
  • ccedk_nbt_usd
  • ccedk_nbt_btc
  • ccedk_nbt_ppc
  • ccedk_nbt_eur
  • hitbtc_nbt_btc

ALix 1,3,7 and 14 will be available on release for all new pairs as well.

5 Likes
#14

All above pairs are now live.

https://alix.coinerella.com/?pairs_available

{“error”:“false”,“available”:[{“pair”:“poloniex_btc_nbt”},{“pair”:“bittrex_btc_nbt”},{“pair”:“southx_btc_nbt”},{“pair”:“southx_nbt_usd”},{“pair”:“cryptsy_nbt_btc”},{“pair”:“cryptsy_nbt_usd”},{“pair”:“bter_nbt_cny”},{“pair”:“bter_nbt_btc”},{“pair”:“ccedk_nbt_usd”},{“pair”:“ccedk_nbt_btc”},{“pair”:“ccedk_nbt_ppc”},{“pair”:“ccedk_nbt_eur”},{“pair”:“hitbtc_nbt_btc”}]}

3 Likes
#15

Re the ccedk_nbt_ppc pair. That is currently not supported in the ALPs software (no feed). I believe the nbt_cny pair is. Both don’t have an active grant against them anyway. One can only provide free liquidity on those pairs :wink:

#16

raw.coinerella.com

and

alix.coinerella.com

are now deployed on a HA server structure.

Enjoy!

2 Likes
#17

I’ve dedicated nearly my whole weekend to ALix development, but I must say: I’m quite pleased with the outcome.

Data gathering is resilient. The HA server structure works like a charm as well so far.
Also, testing fail over scenarios went rather well. Switching from master to backup server will take ~30-60 seconds.
I’ve tried accessing the URL from several devices after the switch from different VPN locations. On some it was instant, others took up to a minute until the backup server was serving them.
My guess is, that this is due to CloudFlare propagating the changed IPs among their globally distributed (DNS) servers.

Given the fact that the total cost for the infrastructure is currently far under 100 USD per month, one or two minutes down time in case the master server goes down is acceptable.

One other thing…
My recent thoughts on ALix development:

What about live exchange wall tracking? I’m thinking of scanning exchange order books and filter the elements by comparing the spread with the current BTC/NBT/CNY price from the NuBot price feeds.

NuBot analyses the walls already, but this data is not available publicly, is it @desrever @woolly_sammoth?
Are we doing wall analysis outside NuBot?

Example:

{"error":"null", "pair":"poloniex_btc_nbt", "order_book":[{"spread":"0.1", "side": "ask", "amount":"1000"}]}

Edit:

I must have over read that, sorry. That sounds an awful lot like the thing I had in mind.

2 Likes
#18

uuups, I’ve missed the notification somehow.

Congrats for the great job, I am so glad we have talented people all around building services for Nu!

Analysing the orderbook is a good idea, but should also be taken carefully since manipulating orderbooks is free of charge. So, make sure no critical decisions are taking only by looking at orderbooks.

I am not sure I understand thi last bit. Would you mind to expand/clarify?

Currently NuBot has the capability to extract an analyse OrderBooks, but it’s not being used live. It will be used in the future tho.

1 Like
#19

Grouping the exchange order book items by spread calculated with the current price feeds.

Spread: 0.1 - order volume: 1234
Spread: 0.13 - order volume: 5678
[…]

Better or worse now? :zap:

Yes. But then again: The volume I’m gathering currently is also coming directly from the exchanges.
How do you imagine gathering t1(frame) then, if not by order book analysis?

The cost to arbitrage
#20

Ok so, let me rephrase it to make sure I understand it.

You want to get the cumulative amount of liquidity available, across exchanges, given a certain offset from 1$…

It will reply the answer the question : ‘How much sell|buy liquidity is available right now across all exchanges untill the price of 1,xx $’ ?

Is my understanding correct ? (note that I tend to talk about offset expressed in $ rather than spreads which are ambiguous metrics

I know volumes can be manipulated (and they also are, especially mainstream BTC exchanges are doing this daily lately) , however to manipulate an exchange you have to be the exchange owner, to manipulate the orderbook you just need an account. So it is less likely that the exchange owner itself will take advantage of volume faking for purpuses of defeating our liquidity distribution mechanism .

How do you imagine gathering t1(frame) then, if not by order book analysis?

By triangulating it with liquidity info. Each liquidity info comes with an identifier you can retrieve with getliquiditydetails , and the identifier should be formed as following tier:pair:exchange:sessionid .

Example : 2:BTCNBT:ccedk:0.1.5_1424193501841_d5ef77

This way you can parse the identifier and see if it matches the orderbook… If you detect a big difference than its either a fake, a bug, or a lack of correct reporting by liquidity operator.

1 Like