In the last week our focus has been exclusively on improving the quality and user experience of our price data endpoint.

The aim was to address key issues and/or feedback that was given to us by users.

Key Issues Addressed:

1. Comparisons to other providers. Before this update our price data used the TradingView method of calculating OHLC candles. Given user feedback, we have now also extended our API to be able to return OHLC data similar to alternatives like Defined and DEXTools.

2. Limited to WETH pools. It’s rare, but some tokens (especially near launch) can only be traded against a stable coin (e.g. USDT, USDC). Up until now our price data was only tracking WETH pools. The problem: no data was available for tokens that only traded against stable coins. One would have to wait for a WETH pool to be created until price data was available.

3. Low volume micro cap tokens. To deal with outliers our OHLC endpoint offers the ability to calculate candles over volume weighted average price. In most cases this works fine. But it’s not robust in very low volume environments. If only one or two small trades happen in a period, there was a non negligible chance for those trades to be outliers, such that averaging over the period did not help.

To address the above issues we made the following updates:

• Added new price type price_token_usd_robust_tick_1

• Added USDT and USDC pools

• Added open_method query parameter

Other updates:

• Maximum number of records per request

• Added sorting

Added new price type

The way our OHLC endpoint works is that you can select which price type to use when creating aggregating the underlying data into OHLC candles.

Each price type corresponds to a different method of calculating the price of a token. The table below (taken from https://syve.readme.io/reference/price_historical_ohlc) shows the available price types.

The price type we added with the latest update is price_token_usd_robust_tick_1.

Instead of calculating an average across trades (like the other price types), we let price_token_usd_robust_tick_1 equal to price_token_usd_tick_1, but with extreme outliers removed.

Note: price_token_usd_tick_1 which we refer to as the “tick” price, is the the exact price at which a token was swapped.

Our current method of removing outliers is to discard trades with price larger than 2x the trailing 10 period volume weighted average.

This is approach is deliberately conservative. We have noticed that alternatives (like DEXTools) have a much more aggressive anomaly filter. In the future we intend on letting this threshold be determined by users themselves (by adding it as a query parameter).

The figure at the top of this article shows the price of $PEPE (address: 0x6982508145454ce325ddbe47a25d4ec3d2311933) on Uniswap V2 pool (address: 0xa43fe16908251ee70ef74718545e4fe6c5ccec9f).

The top chart uses the price_token_usd_robust_tick_1 price type, whereas the bottom chart uses price_token_usd_robust_total_24h.

NOTE: The charts were taken from this dashboard here: https://api.syve.ai/dashboards/price_downloader/. You can use this dashboard to view and download the price of different tokens. You can also use it to try out different query parameters of our OHLC endpoint.

Benefits of price_token_usd_robust_tick_1:

• More responsive. Past price observations have no effect on the latest price. This makes makes it a lot more responsive.

• More dense. The method of calculating a volume weighted average price required a minimum amount of trading volume to occur in a given period. For micro-cap tokens it’s not uncommon for there to be a lot of periods of very low volume (below our threshold). This resulted in an inability to calculate price over these periods. No such minimum volume threshold is imposed on price_token_usd_robust_tick_1.

Added USDT and USDC pools

Tokens that are initially launched in a USDT or USDC pool are tracked earlier.

We now also track more pools. In cases where a token is traded on a WETH pool as well as a stable coin pool, you can return a denser OHLC price series, by virtue of being able to calculate OHLC data over more pools.

Note: The Syve API OHLC endpoint enables you to combine trades from multiple pools when calculating OHLC candles using pool_address=all as a query parameter.

Added open_method query parameter

Before this update we let the open price be based on the first trade that occurred within a period. However, we noticed that alternative APIs like Defined and DEXTools used a different method. In particular, they let the open price equal to the previous period close price.

To address the feedback we received of users wanting our price data to look more similar to alternatives, we have now also added a open_method query parameter to our OHLC endpoint.

There are two options. You can let open_method=prev_close which will let the current period open price be equal to the previous close (like Defined and DEXTools).

The other option is to use open_method=first_trade which lets the open price be equal to the price of the first trade in period. This method is actually used by TradingView in their charts. It’s also the method that we initially used ourselves.

Other updates

We added the ability to determine the order in which the data is returned. Before the default was to always return OHLC candles in ascending order (according to time). We have now added an order query parameter which lets you specify whether to return the data in ascending (order=asc) or descending format (order=desc).

The desc format provides faster response times. The asc format is more convenient when downloading historical data.

The other new parameter we added is max_size, which controls the number of candles to return. The default is 100, and the maximum number of records you can return in a single request is 2500.

If you have questions or want to give feedback you can contact us on Discord (https://discord.com/invite/rs5GPAZ7tG) or Twitter (https://twitter.com/syve_ai).

Feel free to also check out the rest of our API: https://syve.ai.