owned this note
owned this note
Published
Linked with GitHub
# Balancer V2 Dynamic Weghts Adjusting Pools
## Research Topic
Related to [Bhargav's Hackmd](https://hackmd.io/9gdOmfnDR6moyai9df25Dg?both)
**Utilising Dynamic Weigths Changing with the goal of minimizing Impermanent Loss (IL) through implementing a open-loop, closed loop system(s) in a Balancer pool.**
**AMM Parameters available for alteration**:
* Balance(s)
* Weight(s)
* Pool Swap fee
For the purpose(s) of this research exercise, we'll only be adjusting the weights parameters of the pool in our simulation(s): $W_i$, $W_o$
Value Function: $V=\prod_{t}{B_t^{W_t}}$
By adjusting the weight parameters in the pool, we're able to manipulate the coinciding spot/effective price that traders are able to perform swaps in the pool at:
Spot Price Formula: $SP_{i}^{o}=\frac{\frac{B_i}{W_i}}{\frac{B_o}{W_o}}$
Effective Price Formula: $EP_i^o = \frac{A_i}{A_o}$
where $A_i$ is the amount of token $i$ being sold by the trader, and $A_o$ is the amount of token $o$ being bought by the trader.
*For a more comprehensive breakdown of each of the formulas revelant to Balancer pools, refer to the [Balancer Whitepaper](https://balancer.fi/whitepaper.pdf).*
Variations of the model determined by the nature of their rulesets/conditions for when weights get adjusted may be categorised into one of **TWO** variants:
**Open-loop variant**:
* Introducing an Oracle price feed to which Pool parameters or Traders are able to interface with. Possibilities include the likes of dynamically adjusting weights in-line with token-pair prices across other exchange(s), whether on-chain or off-chain.
**Closed-loop variant**:
* Using live AMM's internal price action to dictate changes in parameters. Indicators include:
- Volatility
- Volume
## Hypothesis
The hope is that by dynamically adjusting the weights of the pool and correspondingly manipulating the pool's offered swap price to bring it closer in line with an oraclised or 'fair' market price, the pool is able to reduce the potential misprice margin that otherwise will be capitalised on by sophisticated arbitragers that often siphon away net value from the pool.
![alt text](https://github.com/zerogwei/te-balancer-amms/blob/master/assets/effective_rebalance.png?raw=true "Effective Weight Adjustment")
Each swap performed by a trader incurs a fee, usually set to 0.30% of the total transaction size. An example of an effective dynamic weights rebalance would be when the weights adjustment brings the pool's swap price closer in-line with the *real* market price.
![alt text](https://github.com/zerogwei/te-balancer-amms/blob/master/assets/destructive_rebalance.png?raw=true "Destructive Weight Adjustment")
An example of a destructive dynamic weights rebalance would be when the weights adjustment brings the pool's swap price even further away from the *real* market price, and where in the next timestep(block) a trader is able to perform a net profitable arbitrage that takes value away from the pool.
These two examples are an oversimplification of the purpose(s) for dynamic weights adjustments, however shows promise of scenarios where adjustments may serve beneficial in helping the pool retain value over time. And is important not to understate the vulnerability the pool gets put in when oracle price(s) may potentially be manipulated or simply do not reflect the real/fair market price accurately.
## Approach
### Base model build & validation
We'll build our simulation by integrating Nico's Balancer V2 Python library with the cadCAD framework.
The model uses a single price history as the '*true*' price oracle in which all agents source their knowledge from. In our simulation this wil be a 1 minute-granular price history data set sourced from a centralised exchange. In future iterations we could look to add the likes of Chainlink or Uniswap price oracle(s).
The two agent(s) featured in the model:
1) Sophisticated Arbitrage agent
**ALWAYS** acts at the beginning of every timstep (immediately proceeding price oracle(s) update) whenever theres a price discrepancy that exists across exchange(s).
Factors:
- 0.30% Pool swap fee
- 0.10% Cex trading fee
- 0.10% Cex trade slippage (assuming infinite depth)
- Gas fees consideration
2) Weight-adjusting agent
Performs adjustments at regular timely interval(s)
Factors:
- Every 1, 5, 10, 30 minute(s).
- Gas fees consideration
- [ ] Validate python model by comparing with cadCAD-Hacks model simulation that draws on-chain data from Balancer pool(s).
*In order to do this, I must cater for liquidity provisioning that the model doesn't currently account for.*
### Future agent consideration(s):
1) 'Ordinary' market order flow that falls outside the scope of obvious arbitrage.
2) Malicious agent that performs periodic oracle price manipulation.
#### Open-loop model(s)
- Explore the relationship between IL, price action & the impact of dynamic weight adjusting.
#### Closed-loop model(s)
- Introduce weight adjustment post-trades that push the price beyond the
## Results
#### Price History
**No change, Every 30 mins, 10 mins, 5 mins, 1 min**
![alt text](https://github.com/zerogwei/te-balancer-amms/blob/master/assets/price_feed.png?raw=true "Price History")
#### Weights Changes
**No change, Every 30 mins, 10 mins, 5 mins, 1 min**
![alt text](https://github.com/zerogwei/te-balancer-amms/blob/master/assets/weight_changes.png?raw=true "Price History")
#### Impermanent Loss
![alt text](https://github.com/zerogwei/te-balancer-amms/blob/master/assets/imperm_loss.png?raw=true "Price History")
## Resources
- Bancor's blog post on [Dynamic AMMs](https://blog.bancor.network/breaking-down-bancor-v2-dynamic-automated-market-makers-4e90c0f9a04)
- Nico's [Balancer V2 python library](https://github.com/officialnico/balancerV2_Model
- [Article on uniswap IL](https://pintail.medium.com/uniswap-a-good-deal-for-liquidity-providers-104c0b6816f2)
- [Paper on dynamic amm simulations](https://arxiv.org/abs/2101.02778)
- [Calculating arb between CEX and AMMs](https://hummingbot.io/blog/2020-12-amm-arbitrage-uniswap-balancer)
## Thoughts and Future Directions:
There's a tremendous number of factors that impact the feasibility of this approach including:
- Cost of Gas Fees
- Pool's trading fee
- Size of liquidity provided in the pool and the corresponding price impact of making both internally and externally.
## Further Questions (Out of scope)
- Introducting >2 token pair(s) in to the pool
Provided the fact that up to 8 different tokens are able to be featured in any single pool, what impact would dynamic weight adjustments have on these types of pools? More price oracles are also necessary.
- AMM vs CLOB (Discrete vs Continuous)
In similar vein, how would the approach work across different levels of timestep granularity? Would likely be more prone to manipulation..