DeFi liquidity mining is hot, you should know these concepts before participating in Balancer
Editor's Note: This article comes fromBabbitt Information (ID: bitcoin8btc)Editor's Note: This article comes from
Babbitt Information (ID: bitcoin8btc)BalancerBabbitt Information (ID: bitcoin8btc)
, Author: Fernando Martinelli, translator: free and easy Xi, published with permission.With the recent popularity of COMP, the governance token of Compound, the wave of Defi "liquidity mining" has officially arrived, and it is also highly anticipated by the market and is known as the advanced version of uniswap, and is about to usher in its own governance token mining. Before participating in Balancer’s liquidity mining, you need to understand several concepts, one is how to calculate the value of the Balancer reserve pool, the other is the calculation of impermanence loss, and the last is the calculation of slippage. For these, Balancer CEO Fernando Martinelli will walk us through.
Balancer's white paper
, you might find it daunting to understand all the math involved. Fortunately, most of the complicated partial derivatives and proofs are actually unnecessary to understand and use the protocol. A simple invariant (which we call the value function) ensures all of the interesting self-balancing properties that Balancer asset reserves have:
secondary titlearticle)
The value of the Balancer reserve pool
A Balancer reserve pool can be composed of up to 8 different ERC20 tokens, and each token has its own arbitrary weight. This weight represents the percentage of value that the reserve pool should hold in each token at any one time. As long as there are active rational arbitrageurs in the market and the pool's fees are low, the percentage of value of each token held by the reserve pool is expected to always be very close to the pool's weight. (For the situation of the high-fee Balancer pool, please see this article
article
With low fees, whenever any one token changes in price relative to another, arbitrageurs are incentivized to restore the pool value distribution between tokens to the original predefined weights.
An interesting effect of the flexible choice of weights for each token is that reserve pool liquidity providers (LPs) can control the level of risk they wish to take on each asset. For example, if they are bullish on MKR (vs. ETH), they can choose to add liquidity to a reserve pool with a high MKR weight and a low ETH weight. If no such reserve pool exists, they can also create one themselves. That way, when MKR rises relative to ETH, they will get most of the upside of MKR.
Of course, this advantage is not equivalent to holding 100% MKR, but it will be much better than having a 50/50 reserve pool between MKR and ETH. The screenshot below shows what happens in practice.
Some key questions you may ask when providing liquidity to a Balancer reserve pool are:
If the price of MKR doubles, and ETH stays the same, how much will the value of a reserve pool holding 75% MKR and 25% ETH (similar to the screenshot above) increase?
in
If the price of a token with a weight of 10% falls by 80%, what is the reserve pool loss?
A very simple formula that provides answers to all of the above questions. The value of the Balancer pool (calculated in USD for example), changes according to the (USD) price change of the same reference for each of its underlying tokens:
inis the weight of token i.found in .
The long form proof of this equation is available on our website at
detailed article
With this formula, we can easily answer the question mentioned above, note that regardless of the weight of the token, the constant token price will not affect the value of the reserve pool (ΔP_usd^w = 1^w = 1 ), regardless of the weight of these tokens. So we have:
If the token price of MKR doubles, the total value of a reserve pool with 75% MKR and 25% ETH will increase by 68.2% (=2^0.75=1.682), while the total value of a 50/50 ratio reserve pool will increase by 41.4% ( =2^0.5=1.414).
If a token in a reserve pool has a weight of 10% and its price collapses by 80% (or ΔP_usd = 0.2), then the total value of the reserve pool will only drop by about 15% (=0.2^0.1=0.8513).secondary title。
Liquidity Provider's Immutable Loss (IL)
The term "impermanent loss" was widely circulated after the launch of Pintail's article. If you’ve never heard the term before, read Pintail’s article on Uniswap reserve pool returns
important article
By definition, impermanent loss (IL) describes the loss of assets in the reserve pool as a percentage of what would be lost if those assets were out of the pool, expressed as:
The above formula considers the case of a reserve pool with 0 fees. Balancer's value function without fees is path-agnostic (that is, the order of transactions does not change the final state of the pool). This means that if a liquidity provider (LP) removes liquidity from all their associated tokens at the same price as when they added liquidity, the impermanent loss will be zero: they will own the tokens they invested in. Tokens with exactly the same number of coins.
Adding fees to the equation, the final dollar gain for a liquidity provider (LP) will be the accumulated fees (as a percentage of the total reserve pool value), less impermanent losses.
We can extend the above formula for impermanent loss by changing the change in value held in the pool using the following definition:
As mentioned above, impermanent loss can also be represented by changes in reserve pool value and holding pool:
Therefore, replacing the above formula, the final expression of the impermanent loss in the Balancer pool can be obtained:
Note that the impermanent loss will always be zero or negative due to the convexity of the value function. This can lead to a confusion where negative losses are interpreted as gains. This is not the case: what the impermanent loss (IL) is always negative really means is that any relative change in token price will always result in some transient loss.
secondary title
Slippage on the Balancer Reserve Pool
By definition, slippage is the percentage change in the price actually paid relative to the spot price in a transaction.
In the Balancer reserve pool where fees exist, the spot price is defined as follows (note that from here on, i refers to the input token, i.e. the token sent/sold by the trader to the reserve pool):
By definition, the effective price of a trade is the ratio of the amount a trader sells (amountIn) divided by the amount they get in other tokens (amountOut):
Using the amountOut formula derived from our white paper, we can rewrite this as:
Note that even though we are dealing with transactions where the user defines the amount to sell (amount in), the entire derivation below can be done when the user defines the amount to buy (amountOut), as detailed in the next section.
We can define slippage as the percentage by which the effective price exceeds the spot price. This is a function of the transaction amount (Ai) as it affects the effective price:
So if the effective price of a trade is 102 and the spot price is 100, the slippage is 2%.
This linearization is useful for many algorithm optimizations, including our Smart Sequential Router (SOR).
Through linearization, we can rewrite the slippage as a linear function of the transaction amount:
The sliding slope (SL) is simply the derivative of the sliding formula defined above when Ai = 0. It can be calculated in different ways, but the final solution is:
secondary title
Slippage Calculation Example
Take a 70% AST / 30% WETH reserve pool as an example. At the time of writing, the reserve pool has 4.147 million AST and 491 WETH:
Let's use the formula derived above to calculate the slippage a trade would cause to this reserve pool. The fee set here is 0.0099 (0.99%), Bi is the balance of tokens sold to the reserve pool (491 WETH), Wi is the weight of tokens sold to the reserve (0.3), and wo is the weight of tokens purchased from the pool ( 0.7). So the linear slippage formula for this reserve pool is:
The linear slippage of trading AST with WETH can be written as:
That is, if we were to trade 1 WETH, then a price slip of 0.14% would be expected. This is exactly what we got when we simulated trading on balancer.exchange:
Another case of slippage:
For completeness, let us derive the slippage formula for amountOut(Ao) when buying a token. The formulas are very similar, we start with the same effective price formula:
But this time we extend Ai to be a function of Ao, as we got in our white paper:
Slippage can be written as a function of Ao:


