Subsidizing Market Liquidity

[abit]

BTS/bitEUR score (formula is here https://bitsharestalk.org/index.php/topic,21544.msg289590.html#msg289590)

Code: [Select]

2016-04-13
 183696659.8428,liquidity-bot-linouxisbot
 113107835.0706,altfund
  76662915.9213,liquidity-bot-mauritso
  32650952.0400,bts-scotter


Nice work, @abit!  The only comment I have is that we previously discussed rewarding balance between buy and sell side orders.  So for example if a market makers scores 3000 on the bid side and 2000 on the ask side, they would get full credit for 2000 + 2000.  And then we could apply some factor less than 1 to the remaining 1000 from the bid side score.   I don't think the factor should be 0, but perhaps in the .25-.5 range.  In the future we can do something more sophisticated that identifies the weak and strong sides of a market when it's trending, that way we can more heavily reward liquidity provided to the weak side.   

By the way, can you test out your scoring on a UIA?  Maybe OBITS since it's one of the most active?  Thanks for your work on this, @abit!

Thanks! Scoring of UIA pairs is on my to-do list.

According to https://cryptofresh.com/assets, in last 24 hours, the most active UIA:UIA pair is MKR:OPEN.BTC, the most active BTS pair is BTS:OPEN.BTC

UIA related pairs need to add some factors to the formula, I haven't figured out the final formula.

[tbone]

Define the formula for smart coins as (only count in one side: sell bitEUR & buy BTS):

Code: [Select]

account_score = sum(order_score)

order_score = volume * seconds * price_score(feed_price,order_price)

price_score =
  if order_price < feed_price * 80%
    then 0
  else if order_price <= feed_price * 99%
    then 100 / (1 - order_price / feed_price)
  else
    100 + 10000 * (order_price / feed_price - 0.99)
So,
* price_score is 0 if order_price is less than 80% of feed_price
* price_score is 5 if order_price is 80% of feed_price
* price_score is 10 if order_price is 90% of feed_price
* price_score is 20 if order_price is 95% of feed_price
* price_score is 33 if order_price is 97% of feed_price
* price_score is 50 if order_price is 98% of feed_price
* price_score is 100 if order_price is 99% of feed_price
* price_score is 150 if order_price is 99.5% of feed_price
* price_score is 200 if order_price = feed_price

Then scores of BTS/bitEUR market in April are here:

Code: [Select]

2016-04-12
 184400378.7000,lin9uxis
 158725194.2100,bts-scotter
  48644049.8322,altfund
  37088100.0000,mf-tzo
  14851206.9189,liquidity-bot-linouxisbot
  13052533.0683,liquidity-bot-mauritso
   3235363.3944,liquidity-bot-linouxis2
   1367414.0955,liquidity-bot-mauritso2

2016-04-11
 203062435.9842,bts-scotter
  63045259.2621,altfund
  28664143.6950,lin9uxis
  10421922.3498,liquidity-bot-mauritso2
   5889780.8652,liquidity-bot-mauritso
   5057244.0000,mf-tzo
   4649968.5468,liquidity-bot-linouxis2
   4043822.3133,liquidity-bot-linouxisbot

2016-04-10
 641074500.0000,hugogoulart
 307256636.3463,bts-scotter
 105651130.2000,liondani
  98901551.4495,hcf27
  60203082.8904,altfund
   9153766.9794,liquidity-bot-linouxis2
   8539407.2832,liquidity-bot-mauritso2
   7128896.5920,liquidity-bot-linouxisbot
   6013054.6734,liquidity-bot-mauritso
   2609749.4892,lin9uxis
   2256716.3844,liquidity-bot-bm

2016-04-09
 516839795.8971,bts-scotter
 254116500.0000,hugogoulart
  46036964.3199,altfund
  42258169.8000,liondani
   8893063.7451,liquidity-bot-mauritso2
   7583349.3258,liquidity-bot-mauritso
   6019348.3032,hcf27
   5872279.0644,liquidity-bot-linouxisbot
   5126273.1861,liquidity-bot-linouxis2
   1843986.2718,liquidity-bot-bm

2016-04-08
 402232130.1660,bts-scotter
 216266250.0000,hugogoulart
 113177815.4358,altfund
  36026166.0000,liondani
  18505503.4875,liquidity-bot-mauritso2
  14579342.0448,hcf27
   9433227.9429,liquidity-bot-mauritso
   1256984.7966,liquidity-bot-gold21
    820598.4297,gold-mine
    631812.8628,liquidity-bot-linouxisbot
    548911.6506,liquidity-bot-bm

2016-04-07
 228067431.7239,bts-scotter
  91298250.0000,hugogoulart
  64178934.8070,altfund
  24261388.8000,liondani
   5664953.6586,liquidity-bot-mauritso2
   5378275.7307,liquidity-bot-mauritso
   1030284.2871,antman890
    348001.2387,hcf27
     74945.3340,liquidity-bot-gold21

2016-04-06
 204159419.3772,bts-scotter
  53689303.3404,altfund
  22085322.6000,liondani
   1019154.3606,antman890
    647557.2120,mf-tzo
    223506.2250,liquidity-bot-mauritso

2016-04-05
 194139802.9065,bts-scotter
  52144072.1850,altfund
  21599146.8000,liondani
    945507.3318,antman890

2016-04-04
 228594201.3564,bts-scotter
  62036456.5413,altfund
  23930959.8000,liondani
   1217967.2901,antman890

2016-04-03
 275702980.5606,bts-scotter
  28311683.4000,liondani
  24672346.9869,altfund
    321518.3616,antman890

2016-04-02
 283152877.3458,bts-scotter
  28497024.6000,liondani
  16613545.7664,altfund

2016-04-01
 250503237.4629,bts-scotter
  27221079.6000,liondani
  15580021.5384,altfund
   1266542.7588,inarizushi

@kenCode

Nice work, @abit!  The only comment I have is that we previously discussed rewarding balance between buy and sell side orders.  So for example if a market makers scores 3000 on the bid side and 2000 on the ask side, they would get full credit for 2000 + 2000.  And then we could apply some factor less than 1 to the remaining 1000 from the bid side score.   I don't think the factor should be 0, but perhaps in the .25-.5 range.  In the future we can do something more sophisticated that identifies the weak and strong sides of a market when it's trending, that way we can more heavily reward liquidity provided to the weak side.   

By the way, can you test out your scoring on a UIA?  Maybe OBITS since it's one of the most active?  Thanks for your work on this, @abit!

[abit]

Define the formula for smart coins as (only count in one side: sell bitEUR & buy BTS):

Code: [Select]

account_score = sum(order_score)

order_score = volume * seconds * price_score(feed_price,order_price)

price_score =
  if order_price < feed_price * 80%
    then 0
  else if order_price <= feed_price * 99%
    then 100 / (1 - order_price / feed_price)
  else
    100 + 10000 * (order_price / feed_price - 0.99)
So,
* price_score is 0 if order_price is less than 80% of feed_price
* price_score is 5 if order_price is 80% of feed_price
* price_score is 10 if order_price is 90% of feed_price
* price_score is 20 if order_price is 95% of feed_price
* price_score is 33 if order_price is 97% of feed_price
* price_score is 50 if order_price is 98% of feed_price
* price_score is 100 if order_price is 99% of feed_price
* price_score is 150 if order_price is 99.5% of feed_price
* price_score is 200 if order_price = feed_price

Then scores of BTS/bitEUR market in April are here:

Code: [Select]

2016-04-12
 184400378.7000,lin9uxis
 158725194.2100,bts-scotter
  48644049.8322,altfund
  37088100.0000,mf-tzo
  14851206.9189,liquidity-bot-linouxisbot
  13052533.0683,liquidity-bot-mauritso
   3235363.3944,liquidity-bot-linouxis2
   1367414.0955,liquidity-bot-mauritso2

2016-04-11
 203062435.9842,bts-scotter
  63045259.2621,altfund
  28664143.6950,lin9uxis
  10421922.3498,liquidity-bot-mauritso2
   5889780.8652,liquidity-bot-mauritso
   5057244.0000,mf-tzo
   4649968.5468,liquidity-bot-linouxis2
   4043822.3133,liquidity-bot-linouxisbot

2016-04-10
 641074500.0000,hugogoulart
 307256636.3463,bts-scotter
 105651130.2000,liondani
  98901551.4495,hcf27
  60203082.8904,altfund
   9153766.9794,liquidity-bot-linouxis2
   8539407.2832,liquidity-bot-mauritso2
   7128896.5920,liquidity-bot-linouxisbot
   6013054.6734,liquidity-bot-mauritso
   2609749.4892,lin9uxis
   2256716.3844,liquidity-bot-bm

2016-04-09
 516839795.8971,bts-scotter
 254116500.0000,hugogoulart
  46036964.3199,altfund
  42258169.8000,liondani
   8893063.7451,liquidity-bot-mauritso2
   7583349.3258,liquidity-bot-mauritso
   6019348.3032,hcf27
   5872279.0644,liquidity-bot-linouxisbot
   5126273.1861,liquidity-bot-linouxis2
   1843986.2718,liquidity-bot-bm

2016-04-08
 402232130.1660,bts-scotter
 216266250.0000,hugogoulart
 113177815.4358,altfund
  36026166.0000,liondani
  18505503.4875,liquidity-bot-mauritso2
  14579342.0448,hcf27
   9433227.9429,liquidity-bot-mauritso
   1256984.7966,liquidity-bot-gold21
    820598.4297,gold-mine
    631812.8628,liquidity-bot-linouxisbot
    548911.6506,liquidity-bot-bm

2016-04-07
 228067431.7239,bts-scotter
  91298250.0000,hugogoulart
  64178934.8070,altfund
  24261388.8000,liondani
   5664953.6586,liquidity-bot-mauritso2
   5378275.7307,liquidity-bot-mauritso
   1030284.2871,antman890
    348001.2387,hcf27
     74945.3340,liquidity-bot-gold21

2016-04-06
 204159419.3772,bts-scotter
  53689303.3404,altfund
  22085322.6000,liondani
   1019154.3606,antman890
    647557.2120,mf-tzo
    223506.2250,liquidity-bot-mauritso

2016-04-05
 194139802.9065,bts-scotter
  52144072.1850,altfund
  21599146.8000,liondani
    945507.3318,antman890

2016-04-04
 228594201.3564,bts-scotter
  62036456.5413,altfund
  23930959.8000,liondani
   1217967.2901,antman890

2016-04-03
 275702980.5606,bts-scotter
  28311683.4000,liondani
  24672346.9869,altfund
    321518.3616,antman890

2016-04-02
 283152877.3458,bts-scotter
  28497024.6000,liondani
  16613545.7664,altfund

2016-04-01
 250503237.4629,bts-scotter
  27221079.6000,liondani
  15580021.5384,altfund
   1266542.7588,inarizushi

@kenCode

[tbone]

For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

The formula depends on distance from the market price.  That can be the feed price in the case of BitAssets.  But for UIAs, it would need to be something like the midpoint of the best bid and best ask.  See what I mean?

I see. But that's not something that have to be included in the basic snapshot data. It's an intermediate result while calculating with the formula.

The distance calculation result doesn't need to be in the snapshot data...but the price that will be used later for that calculation needs to be.  For BitAssets, that price comes from the feed, which you have a field for.  For UIAs, it needs to be something else, probably midpoint of best bid and best ask.  You don't have to calculate that midpoint, but you'll have to include the best bid and best ask so the midpoint can be calculated later.  See what I mean now?

Sorry, I didn't get the point.

For smart coins, the feed_price is simply fetched from the blockchain, which is a value published by the witnesses, so can't be calculated out from the order book. It's a basic data. I put it there, you can either use it or not in your formula.

But for UIA? The formula of "best bid" and "best ask" is yet to be defined, so how can I give out the best middle price? As I said it's an intermediate result, not a basic data.

Ok, I see where the misunderstanding is coming from.  Yes, the midpoint is a calculated value.  But the best bid and best ask are NOT calculated values.  They are values that must be recorded in the snapshot.  So let me define them.    The best bid is the highest bid at a given time.  And the best ask is the lowest ask at a given time.  If those values are not recorded in the snapshot, there is no way to calculate the midpoint, and therefore there is no way to calculate the distance component of the score.

On a given time point, the snapshot comes with an entire order book (which is basic data), say a `bids` field and a `asks` field, both are lists ordered by price, the first element on each list is the best one. So?

I see what you mean now.  I guess I was looking at it a little differently since I was envisioning that at some point (if not immediately), it would be too much data if we snapshot EVERY order on the book and that we'd have to start recording only orders of "registered market makers", which is fine except for one thing -- there would be no way to determine the best bid and ask after the fact.  Because that is a very real possibility, now would be a good time to start identifying best bid/ask and place those values into their own top level fields alongside price_feed.  This way a) the code to do the scoring would not break if we have to start doing the limited snapshots, and b) perhaps more importantly, it will be far easier to visually check the scoring results against the snapshot data.   By the way, I'm not saying you should calculate the midpoint.  That can always be done after the fact.  I'm just suggesting to identify the best bid/ask as part of the snapshot. 

[abit]

For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

The formula depends on distance from the market price.  That can be the feed price in the case of BitAssets.  But for UIAs, it would need to be something like the midpoint of the best bid and best ask.  See what I mean?

I see. But that's not something that have to be included in the basic snapshot data. It's an intermediate result while calculating with the formula.

The distance calculation result doesn't need to be in the snapshot data...but the price that will be used later for that calculation needs to be.  For BitAssets, that price comes from the feed, which you have a field for.  For UIAs, it needs to be something else, probably midpoint of best bid and best ask.  You don't have to calculate that midpoint, but you'll have to include the best bid and best ask so the midpoint can be calculated later.  See what I mean now?

Sorry, I didn't get the point.

For smart coins, the feed_price is simply fetched from the blockchain, which is a value published by the witnesses, so can't be calculated out from the order book. It's a basic data. I put it there, you can either use it or not in your formula.

But for UIA? The formula of "best bid" and "best ask" is yet to be defined, so how can I give out the best middle price? As I said it's an intermediate result, not a basic data.

Ok, I see where the misunderstanding is coming from.  Yes, the midpoint is a calculated value.  But the best bid and best ask are NOT calculated values.  They are values that must be recorded in the snapshot.  So let me define them.    The best bid is the highest bid at a given time.  And the best ask is the lowest ask at a given time.  If those values are not recorded in the snapshot, there is no way to calculate the midpoint, and therefore there is no way to calculate the distance component of the score.

On a given time point, the snapshot comes with an entire order book (which is basic data), say a `bids` field and a `asks` field, both are lists ordered by price, the first element on each list is the best one. So?

[tbone]

For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

The formula depends on distance from the market price.  That can be the feed price in the case of BitAssets.  But for UIAs, it would need to be something like the midpoint of the best bid and best ask.  See what I mean?

I see. But that's not something that have to be included in the basic snapshot data. It's an intermediate result while calculating with the formula.

The distance calculation result doesn't need to be in the snapshot data...but the price that will be used later for that calculation needs to be.  For BitAssets, that price comes from the feed, which you have a field for.  For UIAs, it needs to be something else, probably midpoint of best bid and best ask.  You don't have to calculate that midpoint, but you'll have to include the best bid and best ask so the midpoint can be calculated later.  See what I mean now?

Sorry, I didn't get the point.

For smart coins, the feed_price is simply fetched from the blockchain, which is a value published by the witnesses, so can't be calculated out from the order book. It's a basic data. I put it there, you can either use it or not in your formula.

But for UIA? The formula of "best bid" and "best ask" is yet to be defined, so how can I give out the best middle price? As I said it's an intermediate result, not a basic data.

Ok, I see where the misunderstanding is coming from.  Yes, the midpoint is a calculated value.  But the best bid and best ask are NOT calculated values.  They are values that must be recorded in the snapshot.  So let me define them.    The best bid is the highest bid at a given time.  And the best ask is the lowest ask at a given time.  If those values are not recorded in the snapshot, there is no way to calculate the midpoint, and therefore there is no way to calculate the distance component of the score.

[abit]

For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

The formula depends on distance from the market price.  That can be the feed price in the case of BitAssets.  But for UIAs, it would need to be something like the midpoint of the best bid and best ask.  See what I mean?

I see. But that's not something that have to be included in the basic snapshot data. It's an intermediate result while calculating with the formula.

The distance calculation result doesn't need to be in the snapshot data...but the price that will be used later for that calculation needs to be.  For BitAssets, that price comes from the feed, which you have a field for.  For UIAs, it needs to be something else, probably midpoint of best bid and best ask.  You don't have to calculate that midpoint, but you'll have to include the best bid and best ask so the midpoint can be calculated later.  See what I mean now?

Sorry, I didn't get the point.

For smart coins, the feed_price is simply fetched from the blockchain, which is a value published by the witnesses, so can't be calculated out from the order book. It's a basic data. I put it there, you can either use it or not in your formula.

But for UIA? The formula of "best bid" and "best ask" is yet to be defined, so how can I give out the best middle price? As I said it's an intermediate result, not a basic data.

[tbone]

For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

The formula depends on distance from the market price.  That can be the feed price in the case of BitAssets.  But for UIAs, it would need to be something like the midpoint of the best bid and best ask.  See what I mean?

I see. But that's not something that have to be included in the basic snapshot data. It's an intermediate result while calculating with the formula.

The distance calculation result doesn't need to be in the snapshot data...but the price that will be used later for that calculation needs to be.  For BitAssets, that price comes from the feed, which you have a field for.  For UIAs, it needs to be something else, probably midpoint of best bid and best ask.  You don't have to calculate that midpoint, but you'll have to include the best bid and best ask so the midpoint can be calculated later.  See what I mean now?

A snapshot is taken every time when there is a change in the market. The links I provided are live & real data pushing.
* live BTS/bitEUR market snapshots: https://data.sparkfun.com/bitshares_bts_eur_market_snapshot
* live BTS/bitUSD median feed price history: https://data.sparkfun.com/bitshares_usd_price

Oh I see.  So that means that in an active market, the snapshot may be happening as often as every block?

Yes.

Ok, that's great.

[abit]

For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

The formula depends on distance from the market price.  That can be the feed price in the case of BitAssets.  But for UIAs, it would need to be something like the midpoint of the best bid and best ask.  See what I mean?

I see. But that's not something that have to be included in the basic snapshot data. It's an intermediate result while calculating with the formula.

A snapshot is taken every time when there is a change in the market. The links I provided are live & real data pushing.
* live BTS/bitEUR market snapshots: https://data.sparkfun.com/bitshares_bts_eur_market_snapshot
* live BTS/bitUSD median feed price history: https://data.sparkfun.com/bitshares_usd_price

Oh I see.  So that means that in an active market, the snapshot may be happening as often as every block?

Yes.

[tbone]

For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

The formula depends on distance from the market price.  That can be the feed price in the case of BitAssets.  But for UIAs, it would need to be something like the midpoint of the best bid and best ask.  See what I mean?

A snapshot is taken every time when there is a change in the market. The links I provided are live & real data pushing.
* live BTS/bitEUR market snapshots: https://data.sparkfun.com/bitshares_bts_eur_market_snapshot
* live BTS/bitUSD median feed price history: https://data.sparkfun.com/bitshares_usd_price

Oh I see.  So that means that in an active market, the snapshot may be happening as often as every block?

[abit]

For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

A snapshot is taken every time when there is a change in the market. The links I provided are live & real data pushing.
* live BTS/bitEUR market snapshots: https://data.sparkfun.com/bitshares_bts_eur_market_snapshot
* live BTS/bitUSD median feed price history: https://data.sparkfun.com/bitshares_usd_price

[tbone]

[
@roadscape , @abit

Hey guys, how soon do you think this can be completed?  @abit, have you been making progress?  Ronny from @ccedk said he would be interested in utilizing this to reward market makers in his UIAs.  And he will soon be launching some high profile assets suck as Lisk, Digix, and Synerio.  Not to mention, it is critical for us to start bootstrapping key fiat BitAssets.  What do you guys think?

Yes, some progresses.
Check https://data.sparkfun.com/bitshares_usd_price for a feed_price only stream. Market snapshots stream would be something like that but with much more data, which can be used to calculate scores.
If I'm given a decided formula, I can also stream scores.

Ok, so since time is of the essence, it sounds like the important thing to worry about is the snapshots since they can be analyzed and have the formula applied after the fact, correct?  With that in mind, it would be great to see the other required datapoints added, such as asset name, account name, number of shares, current bid/ask, and current price feed (if asset has feed).   Nice work, @abit!

Please check this url for BTS/bitEUR market snapshots: https://data.sparkfun.com/bitshares_bts_eur_market_snapshot . Right now there are only account ids but no account names..

I'll try to score the participants of this market first. And so can you

Very good.. Will these market snapshots be saved to log files directly from the node for external parsing/scoring? How will it work?

Since my code is currently very dirty, I'm not going to publish it right now. So live streaming is the best way for others to be able to use the data at this moment.

Nice progress.  Quick question -- I see you have a field for feed price.  That would apply to BitAssets, but what about for UIAs?  Will you calculate the bid/ask midpoint and place that value in the feed_price field?  Or create an additional field?  Also, how often do you plan to take snapshots?  Thanks.

[abit]

[
@roadscape , @abit

Hey guys, how soon do you think this can be completed?  @abit, have you been making progress?  Ronny from @ccedk said he would be interested in utilizing this to reward market makers in his UIAs.  And he will soon be launching some high profile assets suck as Lisk, Digix, and Synerio.  Not to mention, it is critical for us to start bootstrapping key fiat BitAssets.  What do you guys think?

Yes, some progresses.
Check https://data.sparkfun.com/bitshares_usd_price for a feed_price only stream. Market snapshots stream would be something like that but with much more data, which can be used to calculate scores.
If I'm given a decided formula, I can also stream scores.

Ok, so since time is of the essence, it sounds like the important thing to worry about is the snapshots since they can be analyzed and have the formula applied after the fact, correct?  With that in mind, it would be great to see the other required datapoints added, such as asset name, account name, number of shares, current bid/ask, and current price feed (if asset has feed).   Nice work, @abit!

Please check this url for BTS/bitEUR market snapshots: https://data.sparkfun.com/bitshares_bts_eur_market_snapshot . Right now there are only account ids but no account names..

I'll try to score the participants of this market first. And so can you

Very good.. Will these market snapshots be saved to log files directly from the node for external parsing/scoring? How will it work?

Since my code is currently very dirty, I'm not going to publish it right now. So live streaming is the best way for others to be able to use the data at this moment.

[roadscape]

Discussion also here: https://github.com/cryptonomex/graphene/issues/643

At this point I'm thinking @abit's solution would indeed work great as long as he can implement this detail:

OK, how about a middle ground - taking the snapshot every 10 (20, 30 whatever) minutes BUT also reading the filled orders in that period and using them for the calculation[effectively adding them to the orderbook like they were not filled]?
We can do 2 diff things - either credit them for the whole time period or really check when they were placed and  filled and credit them with the correct real time they were on the book.

####
thisTimeIntervalStart = now() - 10 min
For each filled order in time [now, thisTimeIntervalStart]
      T = OrderFillTime - max(OrderPlacementTime,  thisTimeIntervalStart)
       order_total = size of the Filled Order
####

So each snapshot really needs to be a window of time (say 15mins) that contains every order that existed during that time PLUS its placement time and/or fill time. Is this what you were thinking @abit? Any idea how partially filled orders are handled with this approach?

My idea can be considered that a new snapshot will be taken on every new block, so all unfilled orders will be tracked. For partially filled orders, we'll know when they were created, when they were partially filled, and when they disappeared.

Sounds good.. so this data will be streamed to a log file for processing/scoring by external scripts? It would be ideal to have multiple people running the same script and checking to make sure the numbers are in agreement. Your approach sounds like the most accurate way to get the data.

I'll stream data to somewhere on the Internet.

@roadscape , @abit

Hey guys, how soon do you think this can be completed?  @abit, have you been making progress?  Ronny from @ccedk said he would be interested in utilizing this to reward market makers in his UIAs.  And he will soon be launching some high profile assets suck as Lisk, Digix, and Synerio.  Not to mention, it is critical for us to start bootstrapping key fiat BitAssets.  What do you guys think?

Yes, some progresses.
Check https://data.sparkfun.com/bitshares_usd_price for a feed_price only stream. Market snapshots stream would be something like that but with much more data, which can be used to calculate scores.
If I'm given a decided formula, I can also stream scores.

Very good.. Will these market snapshots be saved to log files directly from the node for external parsing/scoring? How will it work?

[tbone]

[
@roadscape , @abit

Hey guys, how soon do you think this can be completed?  @abit, have you been making progress?  Ronny from @ccedk said he would be interested in utilizing this to reward market makers in his UIAs.  And he will soon be launching some high profile assets suck as Lisk, Digix, and Synerio.  Not to mention, it is critical for us to start bootstrapping key fiat BitAssets.  What do you guys think?

Yes, some progresses.
Check https://data.sparkfun.com/bitshares_usd_price for a feed_price only stream. Market snapshots stream would be something like that but with much more data, which can be used to calculate scores.
If I'm given a decided formula, I can also stream scores.

Ok, so since time is of the essence, it sounds like the important thing to worry about is the snapshots since they can be analyzed and have the formula applied after the fact, correct?  With that in mind, it would be great to see the other required datapoints added, such as asset name, account name, number of shares, current bid/ask, and current price feed (if asset has feed).   Nice work, @abit!