At first glance: impressive!
Will have a closer look 
First question: is it possible to display the liquidity information that is broadcast by a specific address?
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
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
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.
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
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 
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.
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
People have complained about lack of sellside liquidity on fiat pairs more than btc pairs.
1 Like
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.
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
Changes October 23rd, 2015:
- ALix 14 day time frame is now available https://alix.coinerella.com/?pair=poloniex_btc_nbt&frame=14
- API output for ?pairs_available and ?frames_available fixed
“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
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
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
2 Likes
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
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
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? 
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?
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
Updated query string for volume!! see main post
New in the beta:
https://alix.coinerella.com/walls/?json
{“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}}]}
Updated every minute. Currently supporting Bittrex and Poloniex BTC/NBT pairs.
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.)