Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend get_top_markets API #1911

Draft
wants to merge 3 commits into
base: develop
Choose a base branch
from
Draft

Conversation

abitmore
Copy link
Member

  • Added an optional base asset argument to get_top_markets API
    • get_top_market ( limit, optional base_asset )
    • To implement this, the plugin now stores two ticker objects for each market
  • Refactored some code for better performance

TODO:

  • add an API to get total trading volume of specified assets (already added an item to the enum but didn't write more code)

@abitmore
Copy link
Member Author

@oxarbitrage: I think this would be helpful for bitshares/bitshares-explorer-api#64.

@oxarbitrage
Copy link
Member

sure it will :)

@abitmore
Copy link
Member Author

abitmore commented Aug 14, 2019

@oxarbitrage I think it's better to move the timestamp out of the individual items. Since the API was noted as experimental, I guess we can make the change.

{
  "time":xxx,
  "data":[ {ticker_1},{ticker_2},... ]
}

What do you think? Do you know who are using this API except the open explorer?

@abitmore abitmore force-pushed the pr-database-api-code-refactory branch 3 times, most recently from d51305c to 62fc622 Compare August 15, 2019 13:36
@abitmore abitmore added this to In development in Protocol Upgrade Release (5.0.0) via automation Aug 15, 2019
@abitmore abitmore added this to the 4.1.0 - Feature Release milestone Aug 15, 2019
@abitmore abitmore changed the base branch from pr-database-api-code-refactory to develop August 15, 2019 22:01
@abitmore abitmore force-pushed the pr-extend-get-top-markets-api branch from 8b6f923 to 1e8fc78 Compare August 15, 2019 22:47
@abitmore
Copy link
Member Author

Right now, the get_top_market API, if not called with the base asset parameter, the sorting doesn't make sense for users. Ideally, we need a reference price for each asset so that we can sort by trading "value" (volume * price). Data sources we have now:

  • CER, however it is not always reliable so it would mess up the results, perhaps still better than what we currently have though;
  • price feeds, currently it's usable for assets which are backed by CORE
    • We may need price feeds for every asset which wanted to be included in this API, it doesn't sound like a good idea though.
  • market price, can be off or stale for illiquid or inactive markets.

Possible approaches:

  • always use CER
  • use price feeds when available, otherwise use CER
  • use price feeds when available, otherwise assume trading_value = 0

Thoughts?

@oxarbitrage
Copy link
Member

what about considering also what @Zapata did in the bitshares-explorer-api to get top markets?

This is count of fill orders in the last 24 hours. It could mess the results a bit considering some markets will fill less but bigger orders but will still be better than what we have now as we have a reference value in all pairs.

@oxarbitrage
Copy link
Member

Another thing i tried in the past with @MichelSantos is to normalize the volume in BTS by querying the crosses tickers https://github.com/oxarbitrage/scripts/blob/master/bitshares_market_volume.lua#L73-L103 of the market base and quote against BTS.

Not very reliable, the ticker prices need to be up to date and we assume there is a cross in BTS for at least 1 asset or the market pair. Still can be an approach to consider.

@abitmore
Copy link
Member Author

count of fill orders

Count of fill orders makes sense for some people (E.G. a website that measures Dapps' activities) but I think it doesn't make sense for traders.

normalize the volume in BTS

Ideally we should do this or normalize volume in another currency E.G. USD or CNY. However, if we can't stably get somewhat accurate reference prices, the result would be unreliable thus mostly useless. Specifically, hard to do this on-chain, perhaps we (API server admins) can feed some external data to the back end of explorer API and serve results from there.

@abitmore abitmore added this to In development in Feature Release (5.1.0) via automation Sep 13, 2020
@abitmore abitmore removed this from In development in Protocol Upgrade Release (5.0.0) Sep 13, 2020
@abitmore abitmore removed this from In development in Feature Release (5.1.0) Jan 6, 2021
@abitmore abitmore added this to In development in Feature Release (5.2.0) via automation Jan 6, 2021
@abitmore abitmore added this to In progress in Feature Release (6.1.0) via automation Apr 13, 2021
@abitmore abitmore removed this from In development in Feature Release (5.2.0) Apr 13, 2021
@abitmore abitmore removed this from In progress in Feature Release (6.1.0) Aug 8, 2022
@abitmore abitmore added this to In development in Feature Release (7.1.0) via automation Aug 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

None yet

2 participants