Dynamic weights changing model for PowerIndex — the AMM pool of 8 tokens
The idea of arbitrage-based dynamic weights changing model for AMM pool was developed by the PowerPool team in collaboration with Anton Bukov, 1inch.exchange co-founder.
This article is devoted to the problem of optimal dynamic weights changing procedure in the AMM pool entirely governed by the community.
The described model is already developed, tested, and will be implemented as an uncapped version of PowerIndex after a security audit.
Definitions:
AMM: automated market maker
PIPT: Power Index Pool Token. The derivative ERC20 token of the Pool, allowing to claim a share of the pool and de-facto acting as a basket of ERC20 tokens (analog of BPT token in any Balancer Pool)
CVP: Concentrated Voting Power ERC20 token
Introduction
PowerIndex is an AMM pool consisting of 8 governance tokens, acting as an index for them. It is defined as an ETF-like Smart Defi index. This index has two main features:
- It can use pooled tokens for voting in composite protocols (meta-governance). Additionally, it can use them for fund management purposes, executing simple Vault-like strategies. It allows it to generate additional income (cashflows) for PIPT token holders.
- It is entirely governed by the community based on on-chain governance.
Governance is based on the voting of CVP token holders (including all derivative tokens containing CVP as part of their composition, for example, PIPT). So, index liquidity providers can govern the index.
Currently, the basket of tokens is as follows: YFI LEND* SNX COMP MKR UNI WNXM CVP. Each token has a 12.5% initial share in the pool. The index composition is maintained by arbitrageurs — profit-driven agents as in the case of any AMM-based pool.*will be replaced by AAVE in the uncapped PowerIndex version
The AMM model used in PowerIndex is a generalized version of the constant invariant introduced by Balancer:
The motivation for weights changing
The community can change token weights and token set via governance proposals due to different reasons:
- Undervaluation or overvaluation of certain assets. If some asset is overvalued it is rational to decrease its weight in the index to avoid risks of losing index value. The same is applied to undervalued assets, which can add value to the index on a period if their weight will be increased.
- Hedging index from volatility/decrease possible losses. In the case of market turbulence, it is quite rational to increase the weights of assets with strong fundamentals and strong support and decrease the weights of relatively “weak” tokens.
- Optimizing the profitability of using tokens in Vault-like strategies. Tokens pooled into the index are participated in Vault-like strategies generating cashflows for the PIPT holders. In the case of new long-term farming opportunities for certain tokens (new staking programs, etc) the community can increase their weights to improve PIPT profitability and decrease weights of tokens with limited opportunities to generate cashflows.
Imagine that PowerIndex has $100m liquidity and each token has a 12.5% share. For example, changing Token1 share from 12.5% to 10% and Token2 from 12.5% to 15% will result in delivering $2.5m worth of Token1 to the market and absorb into the pool $2.5m worth of Token2 from the market. This is why the procedure for changing index weights has to be designed carefully as it can result in significant price changes of assets as consequently the pool capital size.
The goal for the design of the weights changing procedure: transit index state to a new one as fast as possible remaining the pool capital safe.
Several procedure designs were proposed to tackle this problem:
Incentify Defi users to add an additional amount of necessary token to the pool and withdraw excess of the other token from the pool (excess and additional amounts are calculated according to the new desired pool state community was voted on).
The main drawbacks of this approach are relying on the end-users and uncertainty in the proper motivation scheme for that. Also, it adds an additional level of complexity to the pool design.
Buy and sell assets on Uniswap (or any other major DEX/DEX aggregator like 1inch) using pool smart-contract (trades, automatically executed by the contract). So, in case of weights changing the contract can simply sell the necessary amount of one asset and buy another one.
The main drawbacks of this approach are: (1) selling of one token and buying another one in such amounts will affect the market (2) there are several possible attacks, for example, speculators can preliminary dump Token1 and pump Token2 (token, which share increases). Due to this, the pool will lose part of the capital, selling Token1 for a lower price and buying overpriced Token2 to the pool, de-facto transferring the share the capital to speculators (3) slippage in the cases of buying and selling also will lead to losing part of the pool capital.
Both mentioned ideas add a new level of complexity to the system design and can lead to losing part of the pool capital. Due to this, we decided to develop an approach based on usage of the arbitrageurs’ capital and profit-based incentives for achieving the transition of the AMM pool to a new desired state without exposing the pool capital to risks.
Dynamic weights changing model
This model is based on the ability of the AMM pool to achieve the token balance of the pool via arbitrage. It is a historically-proven approach for balancing Uniswap and Balancer pools in cases of changing the price of pool tokens.
The idea is simple and related to changing pool weights step-by-step, balancing index via arbitrage. There are State1 and State2 of the pool. For example, State1 is (12.5,12.5) and State2 is (10,15) in case if weights of other tokens aren’t changed in this transition. The time for transition is accounted for in seconds. The weights changing rate is accounted for in weight/sec, and based on the block timestamp the new weight is applied every block. For executing such a transition, the pool weights are slightly changing each block, creating arbitrage opportunities for external traders. Trading these opportunities, the pool is balanced back. It is important to note that a similar process takes place in every AMM-based pool in case of changing asset prices, and it works correctly.
The example of application the dynamical weights changing model
The share of Token1 has to be decreased from 12.5% to 10% and the share of Token2 has to be increased from 12.5% to 15% in 3 days (or 259,200 seconds). As the weight changing rate is accounted for in seconds, the weight will be changed for 2.5/259200 = 0.0000096% each second. The timestamp of the new block minus the timestamp of the previous one determines the weight changing per this particular block. The weight changes possess an arbitrage gap and in case of available liquidity on the market arbitrageurs balance the pool back once the arbitrage gap is enough profitable for them. Basically, they would just buy one type of asset and sell another one for that (assuming that nothing else changed on the market during the specified period).
Advantages of this approach:
(1) Risks for the pool capital are minimized as the pool capital isn’t directly used for transition (all risks are taken by arbitrageurs and rewarded by profits they earn)
(2) There is no pressure on the markets of pooled tokens as a transition is stretched out in time
(3) there is no necessity for additional motivation community members at all. The “arbitrage job” can be taken by any trader(s) on the market (the pool will be integrated into 1inch for this purpose). So, TAM for executing this transition entirely covers Defi traders
(4) any Uniswap/Balancer pool undergoing such procedure every time one of the pool’s asset has more volatility than another one, so it is approach proved by the years of market operation
It is important to point out that this model also works for changing weights of several tokens at the same time.
For adding a new token and removing a previously added one the execution of this model needs additional clarification since the weight of the token in AMM cannot be strictly zero.
The case of adding a new token into AMM
When the transition to a new AMM state starts, the new token is added with a very low weight above zero (0.000000001). The necessary amount of this token is deposited to the AMM pool at the same time via the Controller contract. Anyone can preliminarily send the necessary tiny amount of tokens to the contract address. After that transition begins based on block-by-block weight shifting, leading to the arbitrage gap growing every block. This gap is filled by arbitrageurs who bring the index to the target state.
The case of removing an existing token from AMM
In case of removing an existing token, its weight is decreasing block-by-block according to previously mentioned logic until the minimal weight will be reached (0.000000001). When the minimal weight is reached, anyone can pull the method in the contract which completely removes the token from the AMM pool. The remaining tiny amount of tokens is deposited to the Community Pool or can be automatically sold.
The current stage of development
The described model is already developed, tested, and will be implemented as an uncapped version of PowerIndex after a security audit. You can check the current version of the contract here. A detailed technical review of the contract will be published soon.
