ALix BETA

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.

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.

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.

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

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.

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

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)

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.

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

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?

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

willy:

What about live exchange wall tracking? I’m thinking of scanning exchange order books

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.

willy:

and filter the elements by comparing the spread with the current BTC/NBT/CNY price from the NuBot price feeds.

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

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.

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?

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

willy:

The volume I’m gathering currently is also coming directly from the exchanges.

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.