The Comprehensive Guide to the Challenge of Price Feeds

Price feeds are simply an up-to-date stream of just how much an asset is worth. Defi needs them to price collateral and settle derivative markets, but the challenge of properly pricing assets extends deep into traditional financial markets. It sounds super simple, but between choosing price sources, aggregating them, and differences in outlier handling, they’re a near impossible task.

This article will attempt to show that there is no one-size-fits-all approach to generating a robust price feed and there’s an unforgiving tradeoff between security, speed, and decentralization. Solutions are presented, but what specific implementation a project should use depends very much on the goals of that protocol and the sacrifices they’re willing to make.

Background – What is a Price?

price (noun)

/prīs/

The amount as of money or goods, asked for or given in exchange for something else

Prices represent value. A price is a measurement of the value one thing is worth relative to another thing. In the context of cryptocurrency price feeds, the denominator is usually a currency like the US dollar. So to say “the price of Ether is $3,000”, this implies that someone would be willing to exchange one Ether for $3,000.

So far it’s relatively simple, but the problem is that you rarely need to know what a theoretical subjective comparison between two assets is; you want to know the actual price that a trade can happen at, often in quantities much greater than one unit.

What is a price feed?

A price feed is just a constantly updated price. Imagine a list, where every time the price changes, or just every few seconds, a new “current” price is added to the list. But where do they get this “price” to push onto the list?

Usually when traders think of prices, they think of an orderbook. An orderbook (or even an AMM which is an automated one) is simply a list of buys on one side and sells on the other. I’ll buy 10 at $100, that guy will buy 20 at $95, and we’d all buy even more at less than that.

But when thinking about the price feed, what’s the correct “price”?

Intuitively an orderbook implies that there’s some theoretical “correct” price which is the midpoint of the orderbook (the space between the buys and sells…if only you could match them!). But then again, no trades actually occur at the midpoint, so is that right? To give an example, if I’m willing to sell at $100, but no one’s willing to buy until $90…what’s the price? Is it $95? What if all the trades come from sellers crossing the spread and selling at $90? As we’ll go into, maybe if there aren’t any trades over the last year, the midpoint might work fine, but most price feeds for liquid assets show the last traded price.

What about liquidity?

Price feeds are also both constrained and supported by their liquidity.

If you have a price of $100 with millions of dollars of liquidity at $99 and $101, this is pretty good. If you have $10 of liquidity at $90 and $110, this is bad. Using our midpoint math, both prices are $100, but I have a lot more certainty about the former.

In terms of what liquidity is, the easy way to think about it is in terms of orderbook depth. Someone will say “I’ll sell 100 X coins for $100” on an orderbook that I can trade against at any given moment. If you combine this with other bids and offers, you get an active orderbook. The sum of the buys or sells is the “depth” and this is what people usually think of when talking about liquidity. They’ll say something like there is “$50,000 depth within 2%”, meaning that within 2% of the midpoint, you can buy or sell 50k.

How liquidity is formed

If we’re saying that the price is a function of the orders on the book, it’s important to know how that book fills out in the first place — market makers.

Someone who provides liquidity (places those orders there for people to buy or sell) is a market maker. Their job is to bridge the gap between buyers and sellers. If it’s not obvious, buyers may not always (24/7) want to buy, and sellers may not always want to sell. So, market makers buy from sellers and hold the underlying until a buyer comes along. Of course, he takes a spread (a small fee, which is the difference between the sell price and buy price), but this is generally the price of liquidity in a competitive market. If market makers think that it will take a long time for a buyer to come along or if they think that the asset could drop in value during the time holding it, they’ll require a larger spread. So if there are infrequent buyers (or sellers), market makers must charge larger spreads in order to stay profitable.

There’s a time component to liquidity too that is only revealed by looking at the market over a period of time. Often buyers and sellers don’t want to show their whole hand with a trade, so they’ll place orders (or hire a market maker) with a directional strategy in mind. Additionally, price moves or news can make other participants come to the trading floor that weren’t even paying attention. For instance, imagine an orderbook has $100,000 worth of buy orders, split evenly from $100 (current price) down to 0. If I sell 1000$ of an asset every minute for an hour (take the top few orders in the book), odds are market makers will come to replenish the orderbook and this will have substantially less impact on the price than if I just market dump 60,000$. For another example, imagine the same scenario sees the price double; now retail customers who weren’t even planning to sell might be tempted. How much “liquidity” is available is therefore sometimes rather nebulous to put a number on, but as a general rule of thumb, you can look at volume and depth over a certain period to get a good idea.

Price formation

In addition to knowing where on the orderbook to look, you also need to know what orderbooks to even look at. Most of the time in crypto, price feeds are usually just some aggregator service like Coinmarketcap or Coingecko, or they’ll just throw in any exchange that has some volume, but this might not be the best option. If speed is a consideration (which it is), what you actually care about for a current price is the orderbook where the price formation occurs; or in other words, where the actual information is. Liquidity can be on exchanges for any number of reasons (lots of deposits but few trades, large holdings by the exchange, fake liquidity, etc.), but you really want to know where the liquidity is and where it’s being used in figuring out what the price is.

To explain, imagine you have three exchanges, (xA,xB,and xC) and they all have the same orderbook depth. Some trades might happen on all of them, but what you really care about is where most of the trades happen, particularly the big ones. Say xA has a large order that moves the price up by 10%. Over the next few milli-seconds, arbitrageurs will sell assets on xA, and buy on xB and xC (at the lower price) until the prices are all even. So the price will eventually settle up, but probably slightly lower than the full 10% move. So for our price feed, what do we care about and how do we show what’s happening in real time?

Time (ms)	Price xA	Price xB	Price xC
1	100	100	100
2 (trade occurs)	110	100	100
3	109	105	105
4	108	108	108

A theoretical price comparison across exchanges

If you have a price feed that updates instantly and takes the median of the three exchanges, you’ll have your defi app consume: 100,100, 105, and 108. You might be better off going with just the price of xA (100,110,109,108).

But what happens if the first 10% move was just the beginning? What if it’s a move that’s due to a new announcement of the company that profits are through the roof?

Time (ms)	Price xA	Price xB	Price xC
1	100	100	100
2 (trade occurs)	110	100	100
3	120	105	105
4	130	110	110
5	129	120	120
6	128	128	128

Now it’s just being delayed. The swing time for arbitrage is just slowing down your consumption of the proper price. You sort of want an average, but if you care about the price of the asset, the one you really want is just that xA feed. It’s the one where the move happened. The others are just some lazy form of delayed liquidity.

This concept is especially relevant for defi founders. For uniswap, a paper found that 75-93% of volume was some form of arbitrage or sandwich bot. This means it’s probably not a price setting exchange the vast majority of the time (it just provides passive liquidity to arb bots who trade on CEX’s). Liquidity on these alternative venues isn’t bad and it should be looked at as a good thing; they provide security against manipulation, as we’ll go into, but for an up-to-date price, they’re kind of a problem.

The scenario gets even more complicated when you look at derivatives markets. Research has found that derivatives markets can even be the exchange where price discovery happens.. To give an example, imagine someone places a 10x long BTC trade on a perpetuals dex. Someone needs to take the other side of this trade (short BTC). This means that someone can buy BTC on a normal (non-derivative) market, and go short on the derivatives market. This implies that the 10x long on a purely synthetic market actually causes the price of BTC to go up even though it’s in no way tied to the spot market. The hard part now for price feeds is how to make any sense of this. Does a 10x long position count as volume? How do you discount the leverage? Does the midpoint of long and short prices on a perp dex count as a price in your feed? Maybe it should.

So how do we use price feeds?

The main use cases for price feeds within crypto are derivatives (namely perps), stablecoins, and lending protocols; and they all need them for the same reason — collateral. If I give you a token (as collateral), you give me a token to borrow. The borrowed token can be a stablecoin that your protocol mints, an existing stablecoin, or a different coin altogether. We then need to accurately price the collateral in a smart contract so that the borrowed token (or position) is fully backed.

To make these systems safe, one formula needs to hold:

Value of collateral > value borrowed

Usually this is done by converting the value of each of the tokens to its price in dollars. If at any point, the collateral is worth less than that borrowed, the borrower won’t pay back the loan and your system has lost money.

It’s the job of the oracle to price the collateral and they do this by updating a price feed on-chain.

To give a concrete example:

If I have ETH and want to borrow USDC, I deposit $100 worth of ETH into a protocol. The protocol then gives me $90 worth of USDC (slightly over collateralized as is standard).

An oracle constantly updates the price feed for ETH. If the value of the ETH locked goes down to $95…someone can liquidate the position (e.g. give the protocol back $90 worth of USDC for the $95 worth of ETH), thus saving the protocol with $5 to spare.

If however, the ETH price drops really fast to where it’s only worth $80, now no one wants it. The system is “undercollateralized” and broken. Different projects usually have tokens and pools of capital as insurance in case this happens, but it’s not good. Ideally the system will catch this before it happens in any form.

As you can tell, you want a fast price feed (so you can catch the fall as soon it starts). But unfortunately it’s not easy.

Compromising price feeds

In blockchains, there’s a well known tradeoff space that exists between scalability, decentralization, and security: the scalability trilemma.

Stated simply, if you want to make your chain faster (more scalable), you’ll have to either give up security or decentralization. The reasoning is that if you have more speed, you generally have more data, and then less people have the hardware to run/verify the chain, making it less decentralized. And if you have a system where everyone verifies everything and you have consensus around the globe (perfect security and decentralization)…this isn’t very scalable. Or to put it even simpler, the bigger the data you’re sending around and the more people that have to verify it, the slower it is.

What people have realized in the chain space is that you want different tradeoffs for different use cases. If your application is trying to be a real-time global Nasdaq, then you need speed, but maybe not WWIII censorship resistance. If you want to host a platform that can publish state level secrets for whistleblowers, then you might want the opposite. Same with finance, maybe you need sub-second timing, or maybe t+1 settlement is fine as long as you never have a reverted transaction. There’s tradeoffs everywhere and they exist for price feeds too.

Price feeds are limited by the exact same features as blockchains:

Security
Speed
Decentralization

Security

The security of a price feed is a tough one to quantify, but we want to know how to get a price feed that represents an actual price (something you can buy the asset at) on-chain.

First, there’s base level security of an oracle, which regards it to “how do you get it on-chain”, but this is an easy one going forward because of technical advances. ZK tech has enabled trustless querying of API’s, and other methods such as enshrined oracles make this part easily as secure as the chain itself. The real security challenge is actually around “what” do you put on-chain.

For price feeds in a modern context (2025), you generally have one model: one, or a handful of parties, takes a median from a list of exchange APIs to calculate a price. So if TRB/USD is trading on Binance, Coinbase, and OKX, you take a median and call it your price. This is how almost all price feeds function currently. The differences that do exist are mainly around how many APIs are used, and whether or not the list of APIs is known publicly.

For these price feeds, there are two attack methods:

Have the API report a wrong price or
manipulate the exchange so the API temporarily shows a non-representative price

API’s are security risks

The first way to attack a protocol is by hacking the API. An API is just run by a server somewhere. Whether it’s Binance or Coingecko or one set up by your own team, API’s have unknown levels of security. You should assume it’s a 1 of 1 multisig unless you know otherwise (e.g. it’s a node for a DEX). You get around this risk by having more than one API. The more the better. The only problem though is that you add manipulation risk if the exchanges aren’t high quality and have price formation questions as talked about above. Additionally, if most of the trading happens on one venue, no amount of API aggregators will help since they’re all listening to the same exchange API under the hood.

Manipulating the Price

This is the big problem with price feeds. You want to know how to price an asset, but it trades 95% on one exchange and it’s not that liquid. If someone can move your price 10% for $50,000, your protocol is at risk. And this is just the visible part. You can go further down the rabbit hole; if there’s only one market maker on the exchange, how many people would it take to move your price at the moment? If the exchange gets hacked, if a handful of market makers all go offline at the same time, if the one API is compromised, or even if one party fat fingers a trade…the more centralized the price sources or their liquidity providers, the lower the confidence you should have in the accuracy of the feed.

Speed

This question is related intimately to the security of your protocol. There’s a direct tradeoff between having a fast update and updating to a malicious value. As we showed in the security section, there are countless problems with relying on one or even a handful of exchange API’s. The unfortunate reality that parties still don’t want to admit to, is that anytime you want real time information, you’re in for a hard time.

Flash crashes happen.

Markets can dip down and pop back up within milli-seconds. Does your protocol consume that price? What if it was a legitimate down move and the market stays down? Now any delay is just consuming a mispriced feed. There’s no right answer, but crypto has yet to find a universal solution.

In traditional financial markets, you actually have “circuit breakers” or limits to how far prices can move in a certain time period. If the price moves that far, the market is literally paused for a certain period of time. The reasoning is simple, people weren’t expecting this and it may take time to price. Back in the days of the trading pit (when brokers would stand in a room to trade), when a large market moving piece of news would hit, no one would trade. They literally just waited it out and had the ability to not answer the phone or take orders while everyone figured out they were going to lose money. In a broader sense, it’s the admission that the orderbook doesn’t reflect all knowledge; that all demand or supply can’t be known and it’s always a subset by definition.

If I’m holding ETH, I might sell it at $10,000, but I’m sure as hell not going to sit with my ETH on an exchange to provide liquidity so far out of normal trading ranges. In the same way I may have been willing to buy ETH at $1,000, but news of a hack or big sell that causes ETH to retrace that far may have me questioning my order when push comes to shove.

Decentralization

Lastly, also tightly linked to the other features, is decentralization. How many sources a price feed has is critical for obvious reasons, but the decentralization of the feed even goes beyond there.

The transparency of the source list is the first piece. An oracle that is the median of Binance, Coinbase, and Kraken is less “decentralized” than an oracle that says: get the price from top exchanges. The reasoning is that the first price feed has known exchanges. Anyone can see which API’s need to be corrupted and even the exchanges themselves(or the small number of market makers on the exchanges) know that they control the feed. The latter, more anonymous price feed, may be less precise in its number, but could have countless numbers of sources with outlier protection (the attacker may have a hard time knowing). This consideration also has problems when it comes to the utility of your product. If you’re using the price feed as a way to hedge against this price moving, sometimes traders want to hedge against a price on a specific exchange, so a more generic one might not work. The tighter the spread in sources, the less of an issue this is, but in a world where there could be different premiums based on country (e.g. Bitcoins in China are cheaper than in the US or vice-versa), specifying certain requirements for your exchanges can force your list to be known.

Additionally, known exchanges being used as a source, especially CEX’s, can lead to censoring if a government can order that feed to turn off. Decentralized exchanges can help this, but are often subject to even more manipulation due to current dex designs and the non-existent regulatory environment there. If you yourself are doxxed and trying to be compliant, maybe you don’t care about this. But for most protocols seeking price feeds, they may want to claim some censorship resistance and so the decentralization of the price feed is absolutely critical.

Illiquid assets and oracles

The big issue for users of price feeds is in choosing collateral. As we’ve shown, liquid assets with lots of real time volume are usually much easier to reason about their actual price. Sure, there’s some issues around a small delay from price formation and then maybe some disagreement on what the “exact” price is, but these are relatively tiny differences and short of owning the liquidity, there’s not much you could do to improve the system. But smaller assets come with a whole different slew of problems.

For the big, blue chip tokens, you have CEX listings, hundreds of millions of dollars worth of dex liquidity, and handfuls of quality APIs reporting the price on an aggregate of these exchanges. For the newer or smaller assets, it’s a little different.

The main problem is that there’s just no liquidity. There are a lot of consequences that stem from this, but the usual suspects seen are:

Only one price source with any volume(almost always just an AMM created by the team)
There’s often only 5-6 figures of depth on the AMM
All of it is provided by two or three people
The AMM is often on another chain
Often the token distribution itself is such that the team owns the lion’s share

For these assets, it’s hard to give them a price feed. The asset price is clearly controlled by a handful of people, it’s cheap to manipulate by anyone, and it’s certainly dependent on at least one other system (the alternate chain/AMM it’s on).

But you don’t even have to think about just tokens. Pricing is hard for smaller assets even in traditional finance. Whether it’s a liquidity issue, or a standardization issue, there are lots of reasons, you don’t actually “know” the price of something. The most familiar example might be house prices. If you go to Zillow, you’ll note a very large range for what the price of the house is. The problem is that not every house is the same and the quality is impossible to tell unless you’re there or the one buying.

Volume, liquidity and time weighting considerations

If you’re incorporating liquidity metrics into a price feed, there are other considerations you need to account for. Since we care about a price actually being representative of the asset’s worth, we need liquidity metrics to match this as well. If trading on christmas day with 1/10th the liquidity of a normal day sees a large spike down on a usually irrelevant exchange…is this really showing a move downward? Maybe, but maybe your protocol shouldn’t assume that market makers are working every day of the year when statistics clearly show they pull liquidity on holidays.

Some people have argued for time and volume weighting to create proper reference prices. In fact, centralized exchanges even provide cryptocurrency prices with very robust methodologies to do exactly this. The problem is that a “reference” price is very different from a price feed. If we’re going to calculate what the average price of a bitcoin was over the past hour, we can do that. You take volume and time weighting considerations and you aggregate over every trusted exchange you can get your hands on. We know this works; but it tells us very little about the current price of bitcoin.

Even besides the tactical questions of what exchanges you include and what regulation/manipulation prevention you require, the bigger problem is just that backward looking prices would require a complete redesign of both traditional and decentralized financial systems. Others have tried auctions to try and do a redesign (force liquidity on to the same venue as the instrument that needs the price feed), but this just creates a slower feed that causes other issues. Often tight collateral requirements and the need for market makers on a platform (which itself can be centralizing and subject to manipulation if they fall off or collude) can lead to more unsolved problems.

Paths forward

There are tradeoffs in the various solutions, but we feel optimistic about the grand vision that it definitely is possible to make price feeds for any kind of collateral… you’ll just have to be careful. And this is the real solution long term. We’re going to need custom protocols that don’t abstract away risks or pretend that oracles are, or even can be, real time.

“Robust” price feeds

Price feeds need to be dependent on size. What this means specifically is that they need liquidity measures that are based on what you’re trying to price. Whether you’re trying to trade $1 of an asset or you’re trying to trade $10M, you have different prices. This is common sense, but for some reason we have collateral pools in defi with hundreds of millions of dollars that accept the $1 price for valuing the entire pool. This makes no sense.

You should be consuming price feeds based upon the liquidity you’d need to support a given price. Oftentimes this means you’ll need to take a pessimistic approach to the price you’re going to get. If some action benefits from a low price you should assume the highest price you might get. Conversely if your action benefits from a high price (e.g. buying into some token), you should take the low bid. It’s fine having prices be ranges.

As an example, protocols should adjust to minting at a low price and redeeming at a high price. This way, if there is a discrepancy, your system is just fine. You can have a “fast feed” for immediacy and “slow feed” to prevent manipulability (e.g. a uni pool or pull oracle for the fast one and then a twap with a dispute mechanism for the slow). Then if you take the worst of each price for the action, it can help to solve some of the issues where arbitrageurs bankrupt your system. This is going to take risk metrics, governance to calculate out the parameters, and different assumptions around the safety and legitimacy of different API liquidity numbers, but it can be done.

To continue the idea for illiquid tokens, or even large collateral pools for liquid tokens, we need more robust calculations as to liquidity, even if this means harshly marking these assets to market. We should be assuming that there’s an immense amount of slippage if an orderbook cannot accommodate the sale of the entire price point. For assets that don’t trade very often, this will mean steep liquidity discounts and more collateral needed.

Optimistic with Rollbacks

One option that might be especially useful for appchains is to use prices optimistically. The way this works is that you allow for parties to consume real time price feeds, but you have methods, and documentation, for rolling the chain back in the case of a price feed manipulation or flash event. Similar to how traditional financial exchanges work, the price feed can be altered going forward. If there’s a large move, circuit breakers can hit or withdrawals from the system can be paused until it recovers. This can be the responsible choice if you have this ability and the assets you’re trading are subject to manipulation.

Systems that ensure liquidity

This is likely the way to go in our mind. To do this, you need to make sure that your system can always liquidate the underlying collateral at a given price. The only way this is possible is to integrate the liquidity provision directly into the applications that need price feeds (stablecoins/perps/lending protocols). What this means is that your protocol has the liquidity to liquidate the asset; as an example if you’re lending USDC for ETH, and ETH takes in price, you have an AMM that you can sell the ETH on to get the USDC and make the lender whole. Now you can make sure that your collateral doesn’t go below the price and leave your protocol with losses. In practice, this looks like limiting the amount that can be lent and even tying in liquidations to the AMM; if someone wants to place a trade on that liquidity, the price feed is updated with that price, forcing any liquidations or sensitive actions.

Parasitic Price Feeds

Any analysis of price feeds is incomplete without a reference to the fact that the usage of price feeds can degrade the underlying sources. Just as in tradfi, a derivatives exchange can both use a price feed and be the source of price formation for that feed. If you’re using price feeds and intend to dominate the market, you should account for the fact that your system could affect the security of the price feeds you rely on. Another example is setting up your system to place large spot orders if certain prices are hit. If you use exchange Y as your price feed, but you place large sell orders in the case of a price move, you can actually cause liquidity to degrade during times when you need it most. If everyone knows your protocol will dump 1% of the market if the price hits $100, there will probably be few buyers at the $99 level (they’ll let you dump it lower and buy back in).

The end state for price feeds

We need to be better about accounting for the risks of price feeds in decentralized environments. Unlike the regulated tradfi, manipulating spot prices can and will happen if there’s enough of a gain. Even beyond that, projects trying to consume a price feed must assume that there will always be a delay. Unless you’re tying your protocol to a liquidity pool, liquidity is not known instantly and a price feed cannot be real time. Your assets will always be slightly mispriced when the market moves and you must account for this.

Assuming only moderate tail risks leads to systemic failures, a lot of protocols have very large, completely unlimited, tail risks in the case a price moves against a protocol. They ensure that the “token holders” or “LP’s” or some other group are the ones who lose if the system is not provided with the correct price feed. The problem here is that they’re doomed to fail. If a party can drain the value out of your system and walk away, they will. You need to limit exit under unfair conditions if they can arise and force the “winner” to share in the loss. We need to ensure that systems in web3 are always safe and can be used as trustlessly centralized third party dependencies, especially CEX based price feeds.

Price feeds are just one area where crypto needs to step up and self-regulate or these projects will be unable to compete with their regulated counterparts. Tail risks will kill protocols and we’ll be forced to have a clearing house as a financial backstop where regulators approve any collateral in your system. We don’t want this, so let’s build systems that don’t leave users holding the bag when sharp price movements occur.

If we build our systems right, what this looks like in practice is that the exchanges that hold the liquidity will have a massive advantage in launching these subsequent products. For web3, this would look like Uniswap building lending pools and stablecoins directly on top of their liquidity pools and then tapping it for prices / liquidity.

Conclusion

Price feeds are complex. There are limited standards and most projects have failed to think through what they’re even consuming. Additionally, it’s really hard to provide secure price feeds for smaller assets or at speeds anywhere near as fast as trading. That said, there are some options. Of course there are tradeoffs, but if we’re going to build the decentralized dream of being able to tokenize all forms of value, we’re going to need to figure this out. Hopefully this article gives you a more comprehensive view on how price feeds work, some options to minimize risk, and some of the tradeoffs you’ll need to discuss before building your protocol.

For general best practices on oracle integration, check out: https://tellor.io/blog/using-tellor-best-practices-part-1-development/

If you’re looking for integration or just want to chat oracles, feel free to reach out to Tellor: info@tellor.io or join our Discord.

References