@abit if you think any part of this can be done from within graphene, that's great. I've been looking at it from an API perspective.

@tbone @cylonmaker2053 currently the scoring bonus is linear: 100% bonus @ the midpoint, and 0% bonus at 5% off. This could be scaled to a wider range, and we could also use a curve instead of a line (creating a "long tail") for the bonus.

Quote from: roadscape on March 22, 2016, 02:24:45 pm

tonyk Your proposed changes make sense, but continuous monitoring is much more complex than sampling*. What does it capture that sampling can't? And what if samples were e.g. 15 mins apart?

@roadscape
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
####

My question is, what scenario are you trying to avoid (or create) by doing this?

If your order is on the books for 120 mins, and is *completely* filled at minute 125, you would not get credit for those last 5 minutes (assuming 10-minute snapshot interval). To me this doesn't seem like a problem.

If you expect orders to be on the books for less than 10 minutes at a time, I could see why we would need to be tracking this more detailed order activity.

My original line of thinking was a simple "sharedrop" of points onto order book participants at a regular interval.

My assumptions for MM subsidies:
1) The actual market activity doesn't matter nearly as much as creating a nicely-shaped order book.
2) 'Sampling' the order book every ~10 minutes is at least 95% as accurate as analyzing continuous data.

Quote from: roadscape on March 21, 2016, 12:54:22 pm

Quote from: gamey on March 18, 2016, 07:22:27 pm

Thank you for the response Xeroc and even mr Tonyk.

While that definitely works, it isn't using the method I would like to use. I don't want to delve into RPC calls even if they are very easy. (because no other block explorer / api does this) I was looking more for something like a normal web API where the whole call is in the GET.  It is almost easier for me to scrape a block-explorer, (already implemented using regexes) it is just a bit of wasted resources to do as the full page is generated and discarded just to grab a balance. I want to be a friendly netizen.

@gamey could you briefly outline the API's you're looking for? Cryptofresh has a few undocumented APIs, and I plan to grow them out and add doc pages.

Just balances off of the userid. The most basic blockchain API call one could need. It is easy enough to scrape it, but that is a lot of overhead on the server end (all those transactions) just to get the BTS balance. (for example)

API is much preferred over scraping

Here ya go: https://cryptofresh.com/api/account/balances?account=kkachi

@tonyk Your proposed changes make sense, but continuous monitoring is much more complex than sampling*. What does it capture that sampling can't? And what if samples were e.g. 15 mins apart?

@cylonmaker2053 20% seems a bit high if we're trying to maintain a tight peg, no? For other markets it might make sense but imho for *stable* coins it should be a tight band.


Also: should we use the feed price or the center of the spread for P? (My preference would be to not rely on feed price if possible)

* more complex to implement, and correctly. and if anything goes wrong it may be difficult to "replay" the events because we don't have historical orderbook API. at any rate, this would have to be an open source script/daemon that multiple people run and cross-check results. and this, too, will be much easier if we deal with snapshots rather than streams of data. not ruling anything out but I'd like to make sure we exhaust the simplest options.

Thanks guys for summing it up. It looks like @tonyk has the only developed idea, but it might take me longer to fully comprehend it than to offer my own. I'll begin with what I think might be the easiest/most accessible way to score market makers and if it makes sense we can meet in the middle:

For each subsidized market, every hour:

 - Let P = "center point" of the market. (Feed price? Center of spread?)
 - Take a snapshot of the order book
 - Ignore all orders (a) more than 5% away from P or (b) less than 60 minutes old

Score the remaining (i.e. eligible) orders, and sum up *per side/account*

 - score = (order_size / side_total) * (1 + distance_bonus)
   - order_total = size of the sell (ask or bid side).
   - side_total = sum of all eligible orders on the ask or bid side
   - distance_bonus = ((max_distance - distance) / max_distance) (0% off feed = 1 ; 5% off feed = 0)

If we wanted to force balanced market making, then the final score per account is MIN(bid_score, ask_score).

(At this point, we could also discard any scores that are, say, below 25th percentile.)

100% of the reward per hour is split proportionally to the scores in this round. Payouts occur every 7 days.

-------

You get the optimal reward only if your bid/ask is balanced. One side can be smaller and closer to the peg yet still be balanced. Reward is based on your relative ownership of the eligible part of the bid/ask walls. Scalable bonus for how tight your walls are (up to 100% bonus for trading at the center of the market).

Quote from: roadscape on March 20, 2016, 12:08:29 am

Quote from: cube on March 18, 2016, 06:34:47 am

Quote from: roadscape on March 10, 2016, 10:51:14 pm

This week I focused on improving the asset pages. It's not finished but this is all useful market data so I figure I'd release the work in progress sooner than later:
https://cryptofresh.com/a/USD
https://cryptofresh.com/a/MKR_OPEN.BTC

Feedback is appreciated, especially from a trader's perspective.. Any units to flip? Any obvious missing data?

Really nice!

I think the current feed price should be in a more prominent position.  Is there a plan for transaction history?  What does the top 250 accounts mean?

Thanks @cube, feed price is the same thing as "settlement price" price, correct? I've added it above "Details" pane on the right side for now.

Transaction history - you mean to show latest transfers? Or market orders history? Market order history is definitely something I'd like to add there, it's just part of the new API I haven't accessed yet.

Top 250 accounts means "250 accounts with the highest balances and/or debts in this asset" (i.e. the most interesting)

Yes, the fed price is the 'settlement price' in the GUI.  Settlement price in CF is showing '--'.

Transaction history = 'transacted order history'.  Does market order history means that?

The top 250-account list is lumping the highest balances and debts together and this can be confusing.  Can it be separately ranked (ie top in balance OR top in debt)?

Ah, there's actually 2 'settlement prices' -- the 2nd one is part of the "Global settle" feature, and currently only applies to RUB/SEK. But I did add "Price feed" at the top of the right-hand pane. I'll try to clear this up to make it look better though.

And yep, that's what I meant by market order history.

As for the top 250 list, I see what you mean. Maybe it is best to split it into two tables? One for debt positions, the other for balance+orders+collateral balance. Should I combine "Orders" and "Collateral" fields? Or keep them separate?

Thank you for the response Xeroc and even mr Tonyk.

While that definitely works, it isn't using the method I would like to use. I don't want to delve into RPC calls even if they are very easy. (because no other block explorer / api does this) I was looking more for something like a normal web API where the whole call is in the GET.  It is almost easier for me to scrape a block-explorer, (already implemented using regexes) it is just a bit of wasted resources to do as the full page is generated and discarded just to grab a balance. I want to be a friendly netizen.

@gamey could you briefly outline the API's you're looking for? Cryptofresh has a few undocumented APIs, and I plan to grow them out and add doc pages.

Quote from: roadscape on March 18, 2016, 02:33:55 am

New feature, instant search:
https://cryptofresh.com/

Great 

Doesn't work with transaction ID?

It should be working with transaction ID. It requires you to paste either the first 8 or full 40 chars. I didn't think anyone would be typing them in by hand so I saved some processing power by not trying to match anything else. Could you try again? Or let me know which tx id isn't working?

Yep, excellent interview.. nailed it!