# Key Terms and Concepts
Source: https://docs.chain.link/data-feeds/key-terms

> For the complete documentation index, see [llms.txt](/llms.txt).

This page explains the columns and fields shown in the [Data Feeds address tables](/data-feeds/price-feeds/addresses), along with the key concepts behind how Data Feeds work. Use it as a reference when reading the tables or integrating a feed.

For an overview of the different kinds of feeds, see [Feed Types](/data-feeds/feed-types).

## Table columns

Each row in a Data Feeds address table represents a single feed. The columns describe how the feed reports data and how to read it.

### Risk

The market pricing risk category assigned to the feed. Feeds are categorized as 🟢 Low, 🟡 Medium, 🟠 High, or 🔴 Very High market pricing risk based on how reliably the asset can be priced. The risk category helps you evaluate whether a feed is appropriate for your use case.

To learn how each risk category is defined and how to mitigate risk, see [Selecting Quality Data Feeds](/data-feeds/selecting-data-feeds#data-feed-categories).

### Pair

The asset pair that the feed reports, such as `BTC / USD`. The pair identifies the base asset and the quote asset used to express the price.

### Deviation

The deviation threshold that triggers a new onchain update. When the reported price moves by at least this percentage from the last reported value, the oracle network publishes a new answer. For example, a deviation of `0.5%` means the feed updates when the price changes by 0.5% or more.

### Heartbeat

The maximum time between onchain updates, expressed in seconds. The oracle network publishes a new answer at least this often, even if the price has not moved enough to trigger the [deviation](#deviation) threshold. For example, a heartbeat of `3600s` means the feed updates at least once per hour.

### Dec

The number of decimal places used to represent the feed's answer. Because answers are stored as integers, you must know the feed's decimal precision to interpret its value. This column is hidden by default and appears when you toggle **More Details**. See [Decimal precision](#decimal-precision) below.

### Address and info

The onchain address of the feed's [proxy contract](#proxy-contract), which points to the underlying [aggregator contract](#aggregator-contract). Click the address to view it in a blockchain explorer, or use the copy button to copy it. This column also expands to show additional details about the feed, described in [More info fields](#more-info-fields) below.

## More info fields

Expanding a row in the address table reveals additional details about the feed.

### Asset name

The name of the underlying asset that the feed reports, such as `1inch`. This is the base asset in the [pair](#pair).

### Asset type

The category of the underlying asset, such as `Crypto`, `FX`, or `Precious Metals`. The asset type helps you understand the market the feed tracks and which [decimal precision](#decimal-precision) standard applies.

### Market hours

The hours during which the underlying market is open and trading. Some markets, such as precious metals and forex, close on weekends and holidays. To learn how market hours affect feed behavior, see [Market hours](/data-feeds/selecting-data-feeds#market-hours).

### Asset class

A broader classification of the asset, such as `Crypto`, `Equities`, or `Macroeconomics`. This is similar to [asset type](#asset-type) but can include additional sub-classifications.

### Full name

The full product name of the feed, when available. This is a more descriptive label than the [pair](#pair).

### Trading hours

The specific trading session hours for equity feeds, such as `Regular Hours` (9:30am–4:00pm Mon–Fri ET). This is more granular than [market hours](#market-hours) and applies mainly to tokenized equity feeds.

### Bounded (Upper)

A note shown when a feed has a maximum reportable price. This applies to certain stablecoin feeds that are capped at an upper price bound. To learn more, see [Bounded Market Price Feeds](/data-feeds/selecting-data-feeds#bounded-market-price-feeds).

### Deprecating

A note shown when a feed is scheduled for deprecation, including its shutdown date. To learn more, see [Deprecating Feeds](/data-feeds/deprecating-feeds).

## Decimal precision

Chainlink Data Feeds use the following decimal precision standards:

| Asset                  | Decimal Standard |
| ---------------------- | ---------------- |
| Crypto - USD (Non-Eth) | 8                |
| Crypto - ETH           | 18               |
| FX                     | 8                |
| Precious Metals        | 8                |
| Commodities/Energy     | 8                |
| All others             | Feed specific    |

Decimal precision standards are subject to reevaluation. Decimal precision is not changed on live feeds; if an asset pricing falls below a certain acceptable decimal precision, protocols can talk to their Chainlink representatives about spinning up a new feed to accommodate.

To get the decimal precision of a given feed, use the `decimals` function as described in the [Getting Started Guide](/data-feeds/getting-started#compile-deploy-and-run-the-contract) and verify with the contract onchain or via [the Address pages](/data-feeds/price-feeds/addresses?showDetails=true#overview).

For example, when you call `getChainlinkDataFeedLatestAnswer` to retrieve the latest answer from the aggregator contract, the returned value is an integer without a decimal point. You can find the correct number of decimal places for this answer on the [Price Feed addresses](/data-feeds/price-feeds/addresses) page by clicking the **Show more details** checkbox. The answer on the BTC / USD feed uses 8 decimal places, so an answer of `3030914000000` indicates a BTC / USD price of `30309.14`. Each feed uses a different number of decimal places for answers.

## Related concepts

### Answer

The numeric value that a data feed publishes onchain, such as an asset price. Answers are stored as integers in fixed-point format, so they do not include a decimal point. To interpret an answer correctly, you need to know the feed's [decimal precision](#decimal-precision).

### Aggregator contract

An onchain contract that receives periodic data updates from the oracle network and stores the aggregated data so that consumers can retrieve it and act on it within the same transaction. Aggregators are the underlying contracts that [proxy contracts](#proxy-contract) point to. For a complete list of functions and variables available on most aggregator contracts, see the [Data Feeds API Reference](/data-feeds/api-reference#accesscontrolledoffchainaggregator).

### Consumer

An onchain or offchain application that uses Data Feeds. Consumer contracts use the [`AggregatorV3Interface`](https://github.com/smartcontractkit/chainlink/blob/contracts-v1.3.0/contracts/src/v0.8/shared/interfaces/AggregatorV3Interface.sol) to call functions on the [proxy contract](#proxy-contract) and retrieve information from the [aggregator contract](#aggregator-contract). For a complete list of functions available in the `AggregatorV3Interface`, see the [Data Feeds API Reference](/data-feeds/api-reference#aggregatorv3interface).

### Data Feed

A decentralized oracle network that aggregates data from many independent sources and publishes it onchain so that smart contracts can access real-world data such as asset prices, reserve balances, and L2 sequencer health. See the [Data Feeds Overview](/data-feeds) to learn more.

### Decentralized Oracle Network (DON)

A decentralized, peer-to-peer network of independent node operators that work together to fetch, validate, and deliver data to a data feed. Data Feeds aggregate many data sources and publish them onchain using a combination of the [Decentralized Data Model](/architecture-overview/architecture-decentralized-model?parent=dataFeeds) and [Offchain Reporting](/architecture-overview/off-chain-reporting?parent=dataFeeds).

### Feed type

The category of data that a feed provides. Chainlink Data Feeds include [Price Feeds](/data-feeds/price-feeds), [Tokenized Equity Feeds](/data-feeds/tokenized-equity-feeds), [SmartData Feeds](/data-feeds/smartdata), [Smart Value Recapture (SVR) Feeds](/data-feeds/svr-feeds), [Rate and Volatility Feeds](/data-feeds/rates-feeds), [L2 Sequencer Uptime Feeds](/data-feeds/l2-sequencer-feeds), [24/7 Extended-Hours Data Feeds](/data-feeds/24-7-extended-hours-data-feeds), and [Self-Managed Feeds](/data-feeds/self-managed-feeds). See [Feed Types](/data-feeds/feed-types) for an overview.

### Latest round data

The most recent data published by a feed, retrieved using the `latestRoundData` function. This function returns five values representing information about the latest price data, including the answer, the round ID, and timestamps. See the [Data Feeds API Reference](/data-feeds/api-reference) for more details.

### Price Feed

A type of data feed that provides aggregated, decentralized asset prices with cryptographic integrity, commonly used for collateral, lending, and derivatives. See [Price Feeds](/data-feeds/price-feeds) to learn more.

### Proxy contract

An onchain proxy that points to the [aggregator contract](#aggregator-contract) for a particular data feed. Using proxies enables the underlying aggregator to be upgraded without any service interruption to consuming contracts. Proxy contracts can vary from one data feed to another, but the [`EACAggregatorProxy.sol` contract](https://github.com/smartcontractkit/chainlink/blob/contracts-v1.0.0/contracts/src/v0.6/EACAggregatorProxy.sol) on GitHub is a common example.

### Round

A single update cycle in which the oracle network publishes a new answer to a feed. Each round has a unique round ID, and historical answers can be retrieved by round ID. See [Historical Price Data](/data-feeds/historical-data) to learn more.

## Components of a data feed

Data Feeds are examples of decentralized oracle networks with different interfaces depending on the type of data they provide. Each feed type includes specific components:

### Single-value Feed Components

Data feeds that deliver a single numeric value (such as price feeds or single-value [SmartData feeds](/data-feeds/smartdata)) include the following components:

- **Consumer**: A consumer is an onchain or offchain application that uses Data Feeds. Consumer contracts use the [`AggregatorV3Interface`](https://github.com/smartcontractkit/chainlink/blob/contracts-v1.3.0/contracts/src/v0.8/shared/interfaces/AggregatorV3Interface.sol) to call functions on the proxy contract and retrieve information from the aggregator contract. For a complete list of functions available in the `AggregatorV3Interface`, see the [Data Feeds API Reference](/data-feeds/api-reference#aggregatorv3interface).
- **Proxy contract**: Proxy contracts are onchain proxies that point to the aggregator for a particular data feed. Using proxies enables the underlying aggregator to be upgraded without any service interruption to consuming contracts. Proxy contracts can vary from one data feed to another, but the [`EACAggregatorProxy.sol` contract](https://github.com/smartcontractkit/chainlink/blob/contracts-v1.0.0/contracts/src/v0.6/EACAggregatorProxy.sol) on Github is a common example.
- **Aggregator contract**: An aggregator is a contract that receives periodic data updates from the oracle network. Aggregators store aggregated data onchain so that consumers can retrieve it and act upon it within the same transaction. For a complete list of functions and variables available on most aggregator contracts, see the [Data Feeds API Reference](/data-feeds/api-reference#accesscontrolledoffchainaggregator).

To learn how to create a consumer contract that uses an existing price feed, read the [Using Data Feeds](/data-feeds/price-feeds) documentation.

### MVR Feed Components

[Multiple-Variable Response (MVR) Feeds](/data-feeds/mvr-feeds), which deliver multiple data points of various types in a single bundle, include the following components:

- **Consumer**: A consumer is an onchain or offchain application that uses MVR Feeds. Consumer contracts use the [`IBundleAggregatorProxy`](/data-feeds/mvr-feeds/api-reference#ibundleaggregatorproxy) interface to call functions on the proxy contract and retrieve bundle data.
- **Bundle Aggregator Proxy**: This proxy contract points to the underlying bundle aggregator. Using proxies enables the underlying aggregator to be upgraded without service interruption to consuming contracts. The proxy exposes functions like [`latestBundle()`](/data-feeds/mvr-feeds/api-reference#latestbundle), [`bundleDecimals()`](/data-feeds/mvr-feeds/api-reference#bundledecimals), and [`latestBundleTimestamp()`](/data-feeds/mvr-feeds/api-reference#latestbundletimestamp) for consumers to access the bundled data.

To learn how to create a consumer contract that uses an existing MVR feed, read the [Using MVR Feeds on EVM Chains (Solidity)](/data-feeds/mvr-feeds/guides/evm-solidity) guide.

## Reading proxy and aggregator configurations

Because the proxy and aggregator contracts are all onchain, you can see the current configuration by reading the variables through an [ABI](https://docs.soliditylang.org/en/latest/abi-spec.html) or using a blockchain explorer for your network. For example, you can see the [BTC/USD proxy configuration](https://etherscan.io/address/0xF4030086522a5bEEa4988F8cA5B36dbC97BeE88c#readContract) on the Ethereum network using Etherscan.

If you read the BTC/USD proxy configuration, you can query all of the functions and variables that are publicly accessible for that contract including the `aggregator` address, `latestRoundData()` function, `latestAnswer` variable, `owner` address, `latestTimestamp` variable, and several others. To see descriptions for the proxy contract variables and functions, see the source code for your specific data feed on [Etherscan](https://etherscan.io/address/0xF4030086522a5bEEa4988F8cA5B36dbC97BeE88c#code#L568).

The proxy contract points to an aggregator. This allows you to retrieve data through the proxy even if the aggregator is upgraded. If you view the `aggregator` address defined in the proxy configuration, you can see the aggregator and its configuration. For example, see the [BTC/USD aggregator contract](https://etherscan.io/address/0xF4030086522a5bEEa4988F8cA5B36dbC97BeE88c#code) in Etherscan. This contract includes several variables and functions, including another `latestRoundData()`. To see descriptions for the aggregator variables and functions, see the source code on [GitHub](https://github.com/smartcontractkit/libocr/blob/master/contract/AccessControlledOffchainAggregator.sol) or [Etherscan](https://etherscan.io/address/0xAe74faA92cB67A95ebCAB07358bC222e33A34dA7#code#F1#L1).

You can call the `latestRoundData()` function directly on the aggregator, but it is a best practice to use the proxy instead so that changes to the aggregator do not affect your application. Similar to the proxy contract, the aggregator contract has a `latestAnswer` variable, `owner` address, `latestTimestamp` variable, and several others.

## Components of an aggregator

The aggregator contract has several variables and functions that might be useful for your application. Although aggregator contracts are similar for each data feed, some aggregators have different variables. Use the `typeAndVersion()` function on the aggregator to identify what type of aggregator it is and what version it is running.

Always check the contract source code and configuration to understand how specific data feeds operate. For example, the [aggregator contract for BTC/USD on Arbitrum](https://arbiscan.io/address/0x942d00008D658dbB40745BBEc89A93c253f9B882#code) is different from the aggregators on other networks.

For examples of the contracts that are typically used in aggregator deployments, see the [libocr repository](https://github.com/smartcontractkit/libocr/blob/master/contract/) on GitHub.

For a complete list of functions and variables available on most aggregator contracts, see the [Data Feeds API Reference](/data-feeds/api-reference#accesscontrolledoffchainaggregator).

## Updates to proxy and aggregator contracts

To accommodate the dynamic nature of offchain environments, Chainlink Data Feeds are updated from time to time to add new features and capabilities as well as respond to externalities such as token migrations, protocol rebrands, extreme market events, and upstream issues with data or node operations.

These updates include changes to the aggregator configuration or a complete replacement of the aggregator that the proxy uses. If you consume data feeds through the proxy, your applications can continue to operate during these changes.

Proxy and aggregator contracts all have an `owner` address that has permission to change variables and functions. For example, if you read the [BTC/USD proxy contract](https://etherscan.io/address/0xF4030086522a5bEEa4988F8cA5B36dbC97BeE88c#readContract) in Etherscan, you can see the `owner` address. This address is a [multi-signature safe](https://docs.safe.global/getting-started/readme) (multisig) that you can also inspect.

If you [view the multisig contract](https://etherscan.io/address/0x21f73D42Eb58Ba49dDB685dc29D3bF5c0f0373CA#readProxyContract) in Etherscan using the *Read as Proxy* feature, you can see the full details of the multisig including the list of addresses that can sign and the number of signers required for the multisig to approve actions on any contracts that it owns.

The multisig-coordinated upgradability of Chainlink Data Feeds involves time-tested processes that balance collusion-resistance with the flexibility required to implement improvements and swiftly react to external conditions. The approach taken to upgradability will continue to evolve over time to meet user requirements.

## Monitoring data feeds

When you build applications and protocols that depend on data feeds, include monitoring and safeguards to protect against the negative impact of extreme market events, possible malicious activity on third-party venues or contracts, potential delays, and outages.

Create your own monitoring alerts based on deviations in the answers that data feeds provide. This will notify you when potential issues occur so you can respond to them.

### Check the latest answer against reasonable limits

The data feed aggregator includes both [`minAnswer` and `maxAnswer` values](https://github.com/smartcontractkit/libocr/blob/9e4afd8896f365b964bdf769ca28f373a3fb0300/contract/AccessControlledOffchainAggregator.sol#L33). On most data feeds, these values are no longer used and they do not stop your application from reading the most recent answer. For monitoring purposes, you must decide what limits are acceptable for your application.

Configure your application to detect when the reported answer is close to reaching reasonable minimum and maximum limits so it can alert you to potential market events. Separately, configure your application to detect and respond to extreme price volatility or prices that are outside of your acceptable limits.

### Check the timestamp of the latest answer

Chainlink Data Feeds do not provide streaming data. Rather, the aggregator updates its `latestAnswer` when the value deviates beyond a specified threshold or when the heartbeat idle time has passed. You can find the heartbeat and deviation values for each data feed at [data.chain.link](https://data.chain.link/) or in the [Contract Addresses](/data-feeds/price-feeds/addresses) lists.

Your application should track the `latestTimestamp` variable or use the `updatedAt` value from the `latestRoundData()` function to make sure that the latest answer is recent enough for your application to use it. If your application detects that the reported answer is not updated within the heartbeat or within time limits that you determine are acceptable for your application, pause operation or switch to an alternate operation mode while identifying the cause of the delay.

When the node detects that the heartbeat is reached, it initiates the latest round. Depending on congestion and network conditions, there may be a slight delay for the latest round to get onchain.

During periods of low volatility, the heartbeat triggers updates to the latest answer. Some heartbeats are configured to last several hours, so your application should check the timestamp and verify that the latest answer is recent enough for your application.

Users should build applications with the understanding that data feeds for wrapped or liquid staking assets might have different heartbeat and deviation thresholds than that of the underlying asset. Heartbeat and deviation thresholds can also differ for the same asset across different blockchains. Combining data from multiple feeds, even those with a common denominator, might result in a margin of error that users must account for in their risk mitigation practices.

To learn more about the heartbeat and deviation threshold, read the [Decentralized Data Model](/architecture-overview/architecture-decentralized-model?parent=dataFeeds#aggregator) page.