Selecting Quality Data Feeds

When you design your applications, consider the quality of the data that you use in your smart contracts. Ultimately you are responsible for identifying and assessing the accuracy, availability, and quality of data that you choose to consume via the Chainlink Network. Note that all feeds contain some inherent risk. Read the Risk Mitigation and Evaluating Data Sources sections when making design decisions. Chainlink lists decentralized data feeds in the documentation to help developers build new applications integrated with data.

Data Feed Categories

This categorization is put in place to inform users about the intended use cases of feeds and help highlight some of the inherent market integrity risks surrounding the data quality of these feeds.

All feeds published on docs.chain.link are monitored and maintained to the same levels and standards. Each feed goes through a rigorous assessment process when implemented. The assessment criteria can vary depending on the product type of feed being deployed or change over time as the understanding of market integrity risks evolves.

Market price feeds incorporate three layers of aggregation at the data source, node operator, and oracle network layers, providing industry-standard security and reliability on the price data they reference. To learn more about the three layers of data aggregation, see the blog post about Data Aggregation in Chainlink Price Feeds. Additional information about how Chainlink Data Feeds are secured can be seen in the blog post about How Chainlink Price Feeds Secure the DeFi Ecosystem.

Data feeds are grouped into the following categories based on the level of market integrity risk from lowest to highest:

• 🟢 Low Market Risk
• 🟡 Medium Market Risk
• 🔴 High Market Risk
• 🟠 New Token Feeds
• 🔵 Custom Feeds
• ⭕ Deprecating

🟢 Low Market Risk Feeds

These are data feeds that follow a standardized data feeds workflow to report market prices for an asset pair. Chainlink node operators each query several sources for the market price and aggregate the estimates provided by those sources.

Low Market Risk feeds have the following characteristics:

• Highly resilient to disruption
• Leverage many data sources
• High volumes across a large number of markets enable consistent price discovery

While market risk may be low, other risks might still exist based on your use case, the blockchain on which the feed is deployed, and the conditions on that chain.

🟡 Medium Market Risk Feeds

These feeds also follow a standardized data feeds workflow to report market prices for an asset pair. The pair in question may have features that make it more challenging to reliably price, or potentially subject it to volatility which may pose a risk in some use cases. While the architecture of these feeds is resilient and distributed, these feeds carry additional market risk.

Types of market risk that may lead to a feed being categorized as Medium Market Risk include:

• Lower or inconsistent asset volume may result in periods of low liquidity in the market for such assets. This, in turn, can lead to volatile price movements
• A spread between the price for this asset on different trading venues or liquidity pools.
• Market Concentration Risk: If the volume for a given asset is excessively concentrated on a single exchange, that trading venue could become a single point of failure for the feed.
• Cross-Rate Risk: The base asset trades in large volumes against assets that are not pegged to the quote asset. As a result, the price of this specific asset pair may fluctuate even if the underlying asset is not being traded.
• The asset is going through a significant market event such as a token or liquidity migration.
• The asset has a high spread between data providers, the root cause of which is often one of the above factors.

🔴 High Market Risk Feeds

These feeds also follow a standardized data feeds workflow to report market prices for an asset pair. However, the pair in question often exhibits a heightened degree of some of the risk factors outlined under “Medium Market Risk”, or a separate risk that makes the market price subject to uncertainty or volatility. In using a High Market Risk data feed you acknowledge that you understand the risks associated with such a feed and that you are solely responsible for monitoring and mitigating such risks.

Types of market risk that may lead to a feed being categorized as High Market Risk include:

• The asset is going through a significant market event such as a hack, bridge failure, or a delisting from a major exchange.
• The asset or project is being deprecated in the market.
• Volumes have dropped to extremely low levels.

🟠 New Token Feeds

When a token is newly launched, the historical data required to implement a rigorous risk assessment framework that would allow the categorization of a market data feed for that token as low, medium, or high market risk is unavailable. Consistent price discovery may involve an indeterminate amount of time. Users must understand the additional market and volatility risks inherent with such assets. Users of new token feeds are responsible for independently verifying the liquidity and stability of the assets priced by the feeds that they use. At the end of a probationary period, the status of new token feeds may be adjusted to high/medium/low market risk or in rare cases be deprecated entirely.

🔵 Custom Feeds

Custom Feeds are built to serve a specific use case and might not be suitable for general use or your use case's risk parameters. Users must evaluate the properties of a feed to make sure it aligns with their intended use case. Contact the Chainlink Labs team if you want more detail on any specific feeds in this category.

Custom feeds have the following categories and compositions:

• Onchain single source feeds: These feeds take their data from an onchain source, however, the feed has only a single data provider currently supporting the feed.
• Onchain Proof of Reserve Feeds: Chainlink Proof of Reserve uses a large decentralized collection of security-reviewed and Sybil-resistant node operators to acquire and verify reserve data. In this use case, reserves reside onchain.
• Exchange Rate Feeds: These feeds read an exchange rate from an external contract onchain that is designed to allow conversion from one token to another. Chainlink does not own or control these contracts in any way. They are not equivalent to market price feeds.
• Technical Feeds: Feeds within this category measure a particular technical metric from a specified blockchain. For example, Fast Gas or Block Difficulty.
• Total Value Locked Feeds: These feeds measure the total value locked in a particular protocol.
• Custom Index Feeds: An index calculates a function of the values for multiple underlying assets. The function is specific to that index and is typically calculated by node operators following an agreed formula.
• Offchain Single Source Feeds: Some data providers use a single data source, which might be necessary if only one source exists offchain for a specific type of data.
• Offchain Proof of Reserve Feeds: Chainlink Proof of Reserve uses a large decentralized collection of security-reviewed and Sybil-resistant node operators to acquire and verify reserve data. In this use case, reserves reside offchain.
• LP Token Feeds: These feeds use a decentralized feed for the underlying asset as well as calculations to value the liquidity pool (LP) tokens.
• Wrapped Calculated Feeds: These feeds are typically pegged 1:1 to the underlying token or asset. Under normal market conditions, these feeds track their underlying value accurately. However, given that the price is a derivative formed from a calculated method, the derivative asset may not always precisely track the value of the underlying token or asset precisely.

If you plan on using one of these feeds and would like to get a more detailed understanding, contact the Chainlink Labs team.

⭕ Deprecating

These feeds are being deprecated. To find the deprecation dates for specific feeds, see the Feeds Scheduled For Deprecation page.

Data Feed Shutdown Policy

Data feeds managed by Chainlink Labs will be considered for deprecation if they pose a risk to the Chainlink Community and broader ecosystem, if the asset or assets on the feed have significantly deteriorated and no longer meet our Quality Assurance standards, or if the data feed has become economically unsustainable to support.

Known users of these feeds will be contacted directly about the feeds' deprecation. Notifications will also be posted on the Feeds Scheduled For Deprecation page and on our Discord channel with two weeks of notice before they are shut down.

Market hours

In addition to categories, be aware that markets for several assets are actively traded only during certain hours. Listed data feeds include an attribute describing their market hours. Chainlink Labs recommends using these feeds only during their specified hours:

Risk Mitigation

As a development best practice, design your systems and smart contracts to be resilient and mitigate risk to your protocol and your users. Ensure that your systems can tolerate known and unknown exceptions that might occur. Some examples include but are not limited to volatile market conditions, the degraded performance of infrastructure, chains, or networks, and any other upstream outage related to data providers or node operators. You bear responsibility for any manner in which you use the Chainlink Network, its software, and documentation.

To help you prepare for unforeseen market events, you should take additional steps to protect your application or protocol regardless of the market risk categorization of the Data Feeds your application consumes. The below tooling is put in place to mitigate extreme market events, possible malicious activity on third-party venues or contracts, potential delays, performance degradation, and outages. Below are some examples of tooling that Chainlink users have put in place:

• Circuit breakers: In the case of an extreme price event, the contract would pause operations for a limited period of time. Chainlink Automation is able to monitor data feeds to identify unexpected events. If an event were to occur, the Automation network can send an onchain transaction to pause or halt contract functionality.
• Contract update delays: Contracts would not update until the protocol had received a recent fresh input from the data feed.
• Manual kill switch: If a vulnerability or bug is discovered in one of the upstream contracts, the user can manually cease operation and temporarily sever the connection to the data feed.
• Monitoring: Some users create their own monitoring alerts based on deviations in the data feeds that they are using.
• Soak testing: Users are strongly advised to thoroughly test price feed integrations and incorporate a soak period prior to providing access to end users or securing value.

For more detailed information about some of these examples, see the Monitoring data feeds documentation.

For important updates regarding the use of Chainlink Price Feeds, users should join the official Chainlink Discord and subscribe to the data-feeds-user-notifications channel.

Chainlink Community Deployments

Chainlink technology is used by many within the blockchain community to support their use cases. Deployments built and run by community members are not tracked in the Chainlink documentation. Chainlink's community is continuously growing, and they play a vital role in developing the ecosystem, so the software and tooling are developed for anyone to use. Users have a wide variety of options for choosing how to deliver data onchain. They can deploy Chainlink nodes themselves or via the extensive network of node operators that offer services and access one of the community-managed oracle networks that support the supply of various types of data onchain. Chainlink Labs does not take responsibility for the use of Chainlink node software.

It is always recommended that you conduct a thorough analysis of your requirements and carry out appropriate due diligence on any partners you wish to use with your project.

The Chainlink Labs team does not monitor community deployments and users should use best practices in observability, monitoring, and risk mitigation as appropriate for your application's stage of development and use case.

As your usage of data feeds evolves and requirements for higher availability and greater security increases, such as securing substantive value, the reliability properties of your data feed will become crucial. Contact Chainlink Labs team for services to ensure deployments meet the highest levels of availability and security.

High Risk: Forked, modified, or custom software:

As Chainlink is open source, independent forks and modifications may exist. Chainlink Labs and development teams are not involved in these and do not track or maintain visibility on them. Chainlink Labs is not responsible for updates, enhancements, or bug fixes for these versions, and Chainlink Labs does not monitor them. Their use might pose risks that can do harm to your project. Users are responsible for thoroughly vetting and validating such deployments and determining their suitability.

Evaluating Data Sources and Risks

If your smart contracts use data feeds, assess those data feeds for the following characteristics:

• Liquidity and its Distribution
• Single Source Data Providers
• Crypto and Blockchain Actions
• Market Failures Resulting from Extreme Events
• Periods of High Network Congestion
• Unknown and Known Users
• DEX volumes

Liquidity and its Distribution

If your smart contract relies on pricing data for a specific asset, make sure that the asset has a sufficiently healthy level of liquidity in the market to avoid price and market manipulation. Assets with low liquidity or volume can be volatile, which might negatively impact your application and its users. Malicious actors might try to exploit volatility or periods of reduced trading activity to take advantage of the logic in a smart contract and cause it to execute in a way that you did not intend.

Some data feeds obtain their pricing data from individual exchanges rather than from aggregated price tracking services that gather their data from multiple exchanges. These are marked as such in the docs page for that feed. Assess the liquidity and reliability of that specific exchange.

Liquidity migrations occur when a project moves its tokens from one liquidity provider (such as a DEX, a CEX, or a new DeFi application) to another. When liquidity migrations occur, it can result in low liquidity in the original pool, making the asset susceptible to market manipulation. If your project is considering a liquidity migration, you should coordinate with relevant stakeholders, including liquidity providers, exchanges, oracle node operators, Data Feed providers, and users, to ensure prices are accurately reported throughout the migration.

Feeds for assets with low market liquidity or volume where data providers exhibit an abnormal price spread may, on occasion, see a price oscillate between two or more price points within regular intervals. To mitigate risk associated with such price oscillation, users must regularly monitor & assess the quality of an asset's liquidity. Similarly, assets with low market liquidity may experience abnormal or volatile price movements due to erroneous trades.

Design and test your contracts to handle price spikes and implement risk management measures to protect your assets. For example, create mock tests that return various oracle responses.

Single Source Data Providers

Some data providers use a single data source, which might be necessary if only one source exists onchain or offchain for a specific type of data. Evaluate data providers to make sure they provide high-quality data that your smart contracts can rely on. Any error or omission in the provider's data might negatively impact your application and its users.

Crypto and Blockchain Actions

Price data quality is subject to crypto actions by the crypto and blockchain project teams. Crypto actions are similar to corporate actions but are specific to cryptocurrency and blockchain projects, such as token renaming, token swaps, redenominations, splits, reverse splits, network upgrades, and other migrations that teams or communities who govern the blockchain or token might undertake.

Sustaining data quality is dependent on data sources implementing the necessary adjustments related to such actions. For example, when a project upgrades to a new version of their token, this results in a token migration. When token migrations occur, they require building a new Data Feed to ensure that the token price is accurately reported. Similarly, actions by blockchain project teams or communities, such as forks or upgrades to the network, may require new Data Feeds to ensure continuity and data quality. When considering a token migration, fork, network upgrade, or other crypto action, projects should proactively reach out to relevant stakeholders to ensure the asset price is accurately reported throughout the process.

Market Failures Resulting from Extreme Events

Users are strongly advised to set up monitoring and alerts in the event of unexpected market failures. Black swan events, hacks, coordinated attacks, or extreme market conditions may trigger unanticipated outcomes such as liquidity pools becoming unbalanced, unexpected re-weighting of indices, abnormal behavior by centralized or decentralized exchanges, or the de-pegging of synthetic assets, stablecoins, and currencies from their intended exchange rates.

Circuit breakers can be created using Chainlink Automation. Circuit breakers are safety measures that monitor data feeds for unexpected scenarios such as stale prices, drastic price changes, or prices approaching a predetermined min/max threshold. If an unexpected scenario occurs, the circuit breaker can send an onchain transaction to pause or halt contract functionality.

Periods of High Network Congestion

Data Feed performance relies on the chains they are deployed on. Periods of high network congestion or network downtime might impact the frequency of Chainlink Data Feeds. It is advised that you configure your applications to detect such chain performance or reliability issues and to respond appropriately.

Unknown and Known Users

Routine maintenance is carried out on Chainlink Data Feeds, including decommissioning, on an ad-hoc basis. These maintenance periods might require users to take action in order to maintain business continuity.

Notifications are sent to inform known users regarding such occurrences, and it is strongly encouraged for all users, including those users utilizing data feeds for offchain purposes, to provide their contact information before utilizing data feeds. Without providing contact information, users will be unable to receive notifications regarding important Data Feed updates.

If you are using Data Feeds but have not provided your contact information, you can do so here. Users that fail to provide notification information do so at their own risk.

DEX Volumes

Assets with a significant market presence on decentralized exchanges (DEXs) face distinct risks related to unique market structure. The market integrity can be compromised by flash loan-funded attacks, volume shifts to different onchain or offchain exchanges, or a well-capitalized actor temporarily manipulating the price on that exchange. Additionally, DEX trades can result in slippage due to liquidity migrations and trade size. The likelihood of high-slippage trades being accurately reflected in market prices depends on the trading patterns of the asset.

Generally, a lower risk of deviant trades impacting aggregated prices is associated with assets having multiple DEX pools with healthy volumes and consistent trading activity across different time windows.

Evaluating Wrapped or Bridged Assets

Assessing how to Price Wrapped or Bridged Assets

When assessing a Chainlink Data Feed for a wrapped or bridged asset such as WBTC, users should evaluate the tradeoffs between using a Data Feed specifically built for the wrapped or bridged asset or a Data Feed built for the underlying asset.

Decisions should be made on a case-by-case basis considering the liquidity, depth, and trading volatility of the underlying asset compared to its derivative. In addition, users must consider the security mechanism that is designed to keep the wrapped or bridged asset coupled to its underlying asset. Review these parameters regularly as asset dynamics continuously evolve.

Extreme Events Causing Price Deviations in Wrapped or Bridged Assets

Chainlink Data Feeds are designed to provide the market-wide price of various assets, as determined by a volume-weighted average across a wide range of exchanges. On blockchain networks where assets are wrapped and/or bridged from another environment using a cross-chain token bridge, Chainlink Data Feeds built for the underlying asset will continue to report the market-wide price of the underlying asset as opposed to the price of the wrapped/bridged asset. This methodology reduces risks around market manipulation because wrapped/bridged tokens are often less liquid than the underlying asset.

However, users should be aware that certain extreme events may result in price deviations between the wrapped/bridged asset and its underlying counterpart. For example, the exploitation or hack of a cross-chain token bridge may cause a collapse in demand for a particular wrapped asset. As such, users should construct their applications with safeguards, such as circuit breakers to proactively pause functionality to mitigate risk during such scenarios. Circuit breakers can be created using Chainlink Automation to monitor data feeds for unexpected scenarios.

An additional mechanism for securing a protocol utilizing wrapped assets is by incorporating Chainlink Proof of Reserve. Chainlink Proof of Reserve enables the real-time reserve monitoring of offchain and cross-chain assets, including those that have been wrapped/bridged. By comparing the wrapped token’s supply against a Chainlink Proof of Reserve feed, protocols can ensure that these assets are properly collateralized at all times.

Front Running Risk

Front running (when a third party benefits from prior access to information about a transaction) is a known risk inherent to specific blockchain applications. Chainlink Data Feeds are optimized to prioritize high levels of data quality and reliability over latency.

To mitigate the risk associated with front running, users building highly latency-dependent applications should assess whether the configuration of data feeds meets their needed specifications for speed and frequency. Chainlink Data Streams serve as an alternative solution to Data Feeds for latency-sensitive applications, providing low-latency delivery of market data offchain that can be verified onchain while mitigating front running.

Exchange Rate Feeds

The architecture of exchange rate feeds differs from that of standard market rate Chainlink Price Feeds.

Market rate feeds (e.g., Chainlink Price Feeds) deliver price updates based on the volume-based aggregated market price of a specific asset. Price data is aggregated from across multiple sources, including centralized and decentralized exchanges, to provide an accurate representation of an asset's market-wide price.

Exchange rate feeds are tied to specific protocols or ecosystems and report the internal redemption rates for an asset (i.e., the value/rate at which an asset can be redeemed or exchanged within that protocol's ecosystem). This data is sourced directly from a specified smart contract on a source chain and relayed to a destination chain.

Exchange rate feeds are useful in circumstances such as:

• Pricing yield-bearing assets: Multiplying a yield-bearing asset's exchange rate by the underlying asset's market rate can be used to calculate the yield-bearing asset's current price. This methodology can reduce certain pricing volatility risks associated with lower-liquidity yield-bearing assets.
• Enabling cross-chain staking: For example, liquid staking tokens (LSTs) or liquid restaking tokens (LRTs) can be minted at the exchange rate on a layer 2, while Chainlink CCIP transfers the underlying asset to a layer 1 for staking.
• Improving liquidity pool performance for yield-bearing assets: Exchange rate feeds can be utilized to programmatically adjust swap curves to maximize liquidity efficiency.