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!
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.
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.
You had a “by the way”, I scrolled up a few posts and down again and it was gone. Almost thought I was hallucinating. Interesting that post edits work that way…
I’m still trying to figure out if those 500 NBT on the NBT/BTC sell side are a wall. It seems so, but the price I’ve calculated in a snapshot a few minutes ago is around 1,023 NBT, which is a bit far above the 1.015 NBT tolerance.