PowerPool Dynamic AMM strategies and other Tech Updates
This article is devoted to dynamic weights changing strategies in PowerPool indices and other tech updates
Last two weeks we worked on developing tech devoted to three main directions — Dynamic AMM strategies, Productive usage of assets (staking), and xCVP. In this article, we will share an update for every point.
Introduction
The development of efficient rebalancing strategies is one of the core tasks for PowerPool, the protocol for indices and automatically managed portfolios. In PowerPool we utilize the AMM concept, within which the portfolio is rebalanced by profit-seeking agents — arbitrageurs. However, AMM with static weights often is not efficient for automatically traded portfolios since arbitrageurs buy tokens whose value is growing from the AMM and deposit tokens decreasing in value. It is profitable for arbitrageurs, but not for the liquidity providers. This is why we initially developed dynamic weights changing model in November 2020 and implemented the first Dynamic AMM pool — ASSY after that. Additionally, the CVP community co-funded the grant together with Balancer Labs aimed at Balancer Pools simulations, including Dynamic AMM research for PowerPool. We expect the first release of the simulation model from the research group tomorrow.
Efficient portfolio management comes down to the proper implementation of weights changing strategies
Strategies of weights changing: design and implementation
Weights changing in indices and portfolios are handled by PowerOracle v2, a system that allows fetching necessary input data for the weights changing strategy by means of Poker Agent. Weights are updated one time in 24 hours.
Weight changing strategies depend on the nature of assets and index purpose
Typical weights changing strategy has two main parts:
- Weight changing algorithm, processing input data. It is the logic of how weights are adjusted and the value of this adjustment.
- Correction coefficients, making this strategy more accurate. Such coefficients can be found empirically or simulated in simulation experiments. For example, weights can change with additional increment or decrement to value, calculated by the weight changing algorithm.
Developing infrastructure for weights changing strategies we kept in mind that in portfolio management flexibility is the king. Nobody knows how complex strategies we will implement in the future. So we decided to make this architecture as generalized as possible for easy to develop future implementations.
We decided to locate the code containing algorithms for (1) storing and setting pool parameters (2) sorting and setting weights (3) checking the maximum and minimum rate of change, as well as external methods called by Poker in the general contracts WeightValueAbstract.sol and WeightValueStrategy.sol.
The algorithms for calculating new weights based on input data are specified in contracts, which are inherited from mentioned above.
At the moment three strategies are already implemented:
- MCapWeightStrategy.sol
This strategy uses the price feed from the PowerOracle v2 to calculate the market caps of tokens. Only circulating supply is taken into account for calculations (addresses that aren’t accounted for as a part of circulating supply are excluded; the list is updated if necessary). The process of changing weights from the previous values to new ones is started through the Pool Controller (it is called by Poker Agent). The speed of change for any weight cannot exceed the maximum possible value defined in the contract. The strategy was implemented and successfully operates for ASSY. - VaultBalanceWeightStrategy.sol
This strategy was implemented for the Yearn Lazy APE (YLA) index. It receives TVL in Yearn v1 Vaults as input data and shifts weights according to the share of every Vault in the overall TVL - MCapWeightStrategyRebinder.sol
This strategy was implemented for cases when weights should be changed rapidly and the value of this change is significant. In such cases arbitrage value drain can be >> swap fees, so LP capital can be partly drained by arbitrageurs. Contract calculates new target weights and balances, trades necessary amounts of tokens to other ones, and sets new weights. Note, that trades are executed via 1inch using front-run protection. The pool reaches its target state in just a few transactions with minimal losses, using an integrated mechanism instead of paying a premium to arbitrageurs.
The code of all strategies is open-sourced here: https://github.com/powerpool-finance/powerindex/tree/b85879498b58a06989fddc10e61113e6300ca09d/contracts/weight-strategies
Update: Productive assets usage
The productive usage of assets stored inside the AMM pool is one of the key pieces of PowerPool strategy for maximizing profit for LPs. During the last two weeks all audit issues and comments for AAVE, SUSHI, YFI staking were addressed. It is ready for release.
xCVP implementation
The contract contains the following functions: the possibility to deposit CVP, mint xCVP, and redeem xCVP for CVP. The amount of CVP in the pool is always growing based on the conversion of protocol fees into CVP. Some tokens are directly swapped to CVP inside PowerPool indices, or DEXes such as uniswap. For every asset, a swapping strategy is specified by multi-sig. Also multisig sets cvpAmountOut — this is the amount of CVP that should be received as a result of the swap process. The contract is called every 24 hours, so additional CVP is added to the xCVP pool at this frequency.
Other updates: The Snapshot: PowerPool edition and UI improvements
Recently, we developed a special edition of snapshot that allows voting using LP tokens, containing CVP (Uni V2 CVP-ETH, PIPT, YETI). It allows our LPs to use their tokens for voting without polling out the liquidity. Last two weeks we updated it and fixed some bugs found during the first snapshot votings. Additionally, we improved UI/UX and fixed some bugs at powerindex.io.
