Designate Balancer as the platform to host the majority of Olympus’ Protocol Owned Liquidity in an OHM-DAI-ETH pool. Balancer fulfils all the requirements to facilitate the upcoming core upgrade to the protocol, namely Range Bound Stability. Furthermore, Balancer is also fit to serve as the primary hub for business development, being compatible with Olympus’ liquidity services – incurDebt and Mint&Sync – with the goal of strengthening our relationship with existing partner protocols and positioning for growth of the network in the intermediate-term.
This proposal aims to designate one main liquidity platform and pool on that platform. The purpose is to reduce liquidity fragmentation (reducing arbitrage costs), increase liquidity depth (lower price impact and slippage) and improve the value for partner protocols pairing with OHM.
Observing the historical data, it has become evident that among liquidity depth, counter-asset pairing, and the AMM/DEX platform, the platform itself is the least conducive to trading activity. As an example, OHM-wETH has generated 40-60% of the total volume with 20-30% of total liquidity over time.
With regards to core protocol upgrades, the mint & sync functionality isn’t compatible with Uniswap v3 or Curve; while the native Uniswap v2 router was inefficient, or rather, completely unsuccessful in capturing volume within OHM pools.
Over the last four months, Olympus has tested the four main liquidity platforms. A selection of OHM-ETH and OHM-USD stable pools was maintained, iterating from the initial state of OHM-DAI on Sushi, to Uniswap v3, Balancer and Curve. Diversifying the liquidity profile across different pairs and exchanges leads to liquidity fragmentation – this creates arbitrage opportunities which Olympus had been unable to capitalize on, resulting in value drain.
Aggregators (e.g. 1inch, CowSwap and Matcha), as well as third party front ends (e.g. OlyZaps) are driving more and more of the total end user trade volume. Tight integration and compatibility with aggregators is a must.
Designating the main liquidity hub
One thing that stood out during the liquidity platform testing period was the ease of collaboration with the Balancer team, which allows forward planning and influence over platform features.
Utilizing Balancers’ core features, Olympus is able to consolidate its liquidity while retaining pairing against ETH. Moving forward, Olympus would be able to utilize other features that Balancer offers, increasing Protocol Controlled Value capital efficiency while improving trading conditions, eliminate liquidity fragmentation, arbitrage costs and minimize price impact for end users. The Balancer routing system is also favorable for routing via OHM, a key requirement for partners creating additional OHM paired pools.
The proposal is to concentrate liquidity to a Balancer multi asset pool in order to simplify management, simplify upcoming mint & sync, to be more capital efficient on the OHM side and to capture exchange wide ETH-DAI trades as well.
Sizing the liquidity pools
Many factors influence the decision on which assets to pair OHM with. Of highest importance is to make OHM accessible to as many potential users as possible. On Ethereum, ETH is the highest volume asset with the highest number of paired assets. On the other hand, ETH is a volatile asset and the price of OHM will potentially be higher correlated to ETH if more liquidity is ETH paired.
With several liquidity pools, similar volume/liquidity depth ratio minimize arbitrage (no pool is leading or lagging the pricing action in another pool which would generate arb opportunities). This proposal aim to prioritize arb minimization by reducing the number of protocol owned pools and by maintaining a similar volume to liquidity ratio in the main pools.
The long term goal is to pair OHM with a many volatile assets and it is expected that over time the volatile pairs will greatly outsize OHM-stable pairs. The proposal is to meet this expectation of increased protocol and non-protocol owned liquidity by making the Balancer pool balanced between the two counter assets. This way it is as capital efficient as possible and priorities minimum slippage for all trades and users in the pool. The pool is proposed to be weighted 50/25/25. In simulations with two separate 50/50 pools, 33/33/33 and 70/15/15 pools as alternatives the 50/25/25 pool allowed for greater upside, lower price impact and similar ROI on price upswing and downswings as the other options. When selling OHM these pool weights absorb excess supply better as well.
Additionally, the current Curve OHM-ETH pool will also be adjusted to a similar vol/liquidity ratio (currently 0,87, this will be part of ongoing operations).
Over time, it is suggested that all liquidity pools are regularly monitored. The total liquidity to market cap ratio should be around 0.2 when combining all liquidity pools and the volume to liquidity ratio across pools should be adjusted on a monthly basis.
How to execute
Migrating all liquidity at once is a potential chock to end users and other market participants alike. Therefor the migration needs to be planned ahead, well communicated and executed in steps.
Create a new managed pool on Balancer (where weights can be changed over time and assets in the pool can change). Initial weights and assets should be OHM-ETH-DAI 50/25/25.
Migrate the current Balancer OHM-ETH-DAI to the new pool.
Prepare a migration script that will draw a given amount of Sushi OHM-DAI (e.g. 20% of the pool), Sushi OHM-WETH and Treasury OHM and WETH to bring the ratio up to 50/25/25 and deploy to the Balancer pool.
Run this script over 10 weeks (5 times) to migrate the entire Sushi pools to Balancer.
When to execute
Execute the first step in the migration as soon as possible. It has long been discussed that Olympus is actively subsidizing other pools on Sushi (via trading fees to sushi stakers). With the current market reset it is a good opportunity to move liquidity as soon as possible so that new users coming into the OHM ecosystem are primed on the new liquidity hub without the need for a migration down the road.
Any liquidity move should however be clearly communicated and not executed until at least two weeks after the initial announcement.
Designate Balancer as the main liquidity hub
Designate Balancer OHM-DAI-ETH as the main liquidity pool
Create a managed OHM-DAI-ETH pool initialised with pool weights at 50/25/25
Migrate the current Sushi OHM-DAI and OHM-ETH liquidity to the Balancer pool in five batches, adding ETH and OHM from reserves to match the DAI amount in each batch
The polling process begins now and will end at 02:00 UTC on July 3rd 2022. After this, an OIP proposal may be added to Snapshot for final vote.
For: In support of proposal above
Against: Not in support of proposal