This article primarily covers the role of internal “price oracles” within Curve Finance v2 pools, with a brief note at the end of LLAMMA price oracles.
Please note that Curve v1 and v2 pools do not rely on external price oracles. Misuse of external price oracles is a contributing factor to several major DeFi hacks. If you are looking to use Curve’s “price oracle” functions, or any price oracle, to provide on-chain pricing data in a decentralized application you are building, we recommend extreme caution.
Curve v2 pools, which consist of assets with volatile prices, require a means of tracking prices. Instead of relying on external oracles, the pool instead calculates the price of these assets internally based on the trading activity within the pool.
This is tracked by two similar but distinct parameters:
- Price Oracle: The pool’s expectation of the asset’s price
- Price Scale: The price based on the pool’s actual concentration of liquidity
Pools keep track of recent trades within the pool as a variable called
price_oracleis calculated as an exponential moving average of recent trade prices. The
price_oraclerepresents what the pool believes is the fair price of the asset .
price_scaleis a snapshot of how the liquidity in the pool is actually distributed. For this reason,
price_oracle. As users make trades, the pool calculates how to profitably readjust liquidity, and the
price_scalemoves in the direction of the
Price Oracle and Price Scale shown in the Curve UI
As discussed above, the
price_oraclevariable is calculated as an “exponential moving average” of
For comparison, traders commonly rely on a “simple moving average” as a technical analysis indicator, which calculates the average of a certain number points (ie, a 200-day moving average computes the average of the trailing 200 days of data).
The “exponential moving average" is similar, except it applies a weighting to emphasize newer data over older data. This weighting falls off exponentially as it looks further back in time, so it can react quicker to recent trends.
An internal function
tweak_priceis called every time prices might need to be updated by an operation which might adjust balances within a pool (hereafter referred to as a liquidity operation):
tweak_pricefunction is a gas expensive function which can execute several state changing operations to state variables.
price_oracleis updated only once per block. If the current timestamp is greater than the timestamp of the last update, then
price_oracleis updated using the previous
price_oracle valueand data from
price_oracleis then used to calculate the vector distance from the
price_scale, which is used to determine the amount of adjustment required for the
Curve v2 pools operate on profits. That is, liquidity is rebalanced when the pool has earned sufficient profits to do so. Every time a liquidity operation occurs, the pool chooses whether it should spend profits on rebalancing. The pool’s actions may be considered as an attempt to rebalance liquidity close to market prices.
Pools perform all such operations strictly with profits, never with user funds. Profits are occasionally claimed by administrators, otherwise funds remain in the pool. In other words, profits can be calculated from the following function:
profits == erc20.balanceOf(i) - pool.balances(i)
Internally, every time the
tweak_pricefunction is called during a liquidity operation, the pool tracks profits. It then uses the updated profit values to consider if it should rebalance liquidity.
Specifically, pools carry a public parameter called
allowed_extra_profitwhich works like a buffer. If the pool’s virtual price has grown by more than a function of profits and the
allowed_extra_profitbuffer value, then the pool is considered profitable enough to rebalance liquidity.
From here, the pool further checks that the
price_scaleis sufficiently different from
price_oracle, to avoid rebalancing liquidity when prices are pegged. Finally, the pool computes the updates to the
price_scaleand how this affects other pool parameters. If profits still allow, then the liquidity is rebalanced and prices are adjusted.
We do not recommend using Curve pools by themselves as canonical price oracles. It is possible, particularly with low liquidity pools, for outside users to manipulate the price.
Curve pools nonetheless include protections against some forms of manipulation. The logic of the Curve
price_oraclevariable only updates once per block, which makes it more resistant to manipulation from malicious trading activity within a single block.
Due to the fact that changes to
price_oracleare dampened by an exponential moving average, attempts to manipulate the price may succeed but would require a prolonged attack over several blocks.
Actual $CVX price versus CVX-ETH Pool Price Oracle and Price Scale during rapid volatility
These safeguards all help to prevent various forms of manipulation. However, for pools with low liquidity, it is not difficult for whales to manipulate the price over the course of several transactions. When relying on oracles on-chain, it is safest to compare results among several oracles and revert if any is behaving unusually.
Newer v1 Pools also contain a price oracle function, which also displays a moving average of recent prices. If the moving average price was written to the contract in the same block it will return this value, otherwise it will calculate on the fly any changes to the moving average since it was last written.
Curve v1 pools do not have a concept of price scale, so no endpoint exists for retreiving this value. Older v1 pools will also not have a price oracle, so use caution if you are attempting to retrieve this value on-chain.
The LLAMMA use of oracles is quite different than Curve v2 pools in that it can utilize external price oracles. In LLAMMA, the
price_oraclefunction refers to the collateral price (which can be thought of as the current market price) as determined by an external contract.
For example, LLAMMA uses
price_oracleto convert $ETH to $crvUSD at a specific collateral price. When the external price is higher than the upper price (internally:
P_UP), all assets in the band range are converted to $ETH. When the price is lower than the lower price (internally:
P_DOWN), all assets are converted to $crvUSD. When the oracle price is in the middle, the current band is partially converted, with the exact proportion determined by price changes.
When the external price changes, an arbitrage opportunity exists. External arbitrageurs can deposit $ETH or $crvUSD to balance the pool, until the pool price reaches parity with the external price. LLAMMA applies an exponential moving average to the
price_oracleto prevent users from absorbing losses due to drastic fluctuations.