@1saf let's current APR and earning for the last two values for the version on the 28th. The tooltips should both read "This information will be updated based on gauge votes on April 7th"
Closed this issue · 0 comments
@1saf let's current APR and earning for the last two values for the version on the 28th. The tooltips should both read "This information will be updated based on gauge votes on April 7th"
Then on the 7th April (launch phase 2) we have to show the APR based on the gauges calculations that Tom shared in slack. Copying it below for reference. The new tooltips should read respectively: "The potential APR is based on the gauge votes this pool has from veBAL holders." and "The potential earning is based on the APR above and the amount of liquidity you have staked."
RE calculating the APRs for a given pool.
Calculating total BAL payable to gauge over a week
BAL payable to gauge = global BAL inflation per week * fraction payable to gauge
= (global BAL inflation per second * 7 * 86400) * (gauge relative weight / 1e18)
= (bal_inflation_rate * 7 * 86400) * (gauge_relative_weight / 1e18)
gauge_relative_weight can be pulled from the GaugeController.gauge_relative_weight(gauge_address, timestamp).
https://github.com/balancer-labs/balancer-v2-monorepo/blob/d7eb4a6d99d32dd3e3e7c9648ecb1037412b926b/pkg/liquidity-mining/contracts/GaugeController.vy#L376-L387
If you want this week's APR then pass a timestamp in the current week, to estimate next week's APR pass a timestamp in the next week. (remember that weeks start on thursday)
bal_inflation_rate can be pulled from BalancerTokenAdmin.getInflationRate
https://github.com/balancer-labs/balancer-v2-monorepo/blob/d7eb4a6d99d32dd3e3e7c9648ecb1037412b926b/pkg/liquidity-mining/contracts/BalancerTokenAdmin.sol#L213-L218
Calculating BAL received per week.
If we're calculating for a particular user the fraction of the gauge's BAL they receive will simply be the fraction of the working supply which they make up. That said it's simpler to just calculate the BAL which a new depositor with zero boost would receive and then apply the relevant boost afterwards.
With zero boost, depositing 1 BPT will give the user a working balance of 0.4 which gives us
weekly rewards per BPT = (working balance / (total working supply + working balance) * BAL payable to gauge
= 4e17 / (working_supply + 4e17) * BAL payable to gauge
working_supply can be pulled directly from the relevant LiquidityGaugeV5 contract
https://github.com/balancer-labs/balancer-v2-monorepo/blob/d7eb4a6d99d32dd3e3e7c9648ecb1037412b926b/pkg/liquidity-mining/contracts/gauges/LiquidityGaugeV5.vy#L137-138
We then just need to do the standard scaling
APR = weekly rewards per BPT * boost factor * 52 * BAL price / BPT price
I forgot to mention how to calculate this for extra reward tokens (i.e. not BAL)
LiquidityGaugeV5 has a reward_data(token_address) function which returns a Reward struct. This Reward struct has a rate field which is the amount of the reward token to be distributed per second.
https://github.com/balancer-labs/balancer-v2-monorepo/blob/3faeebbcef8fcccd68b6c0a[…]1d07d/pkg/liquidity-mining/contracts/gauges/LiquidityGaugeV5.vy
https://github.com/balancer-labs/balancer-v2-monorepo/blob/3faeebbcef8fcccd68b6c0a[…]1d07d/pkg/liquidity-mining/contracts/gauges/LiquidityGaugeV5.vy
Reward tokens don't use the working balances like BAL but the standard ERC20 balances so users will receive tokens proportional to the fraction of staked BPT they hold.
Originally posted by @FernandoMartinelli in balancer/frontend-v2#1467 (comment)