Creating Liquidity Strategies With Balancer Managed Pool Controllers | by 0xEvan | Balancer Protocol

Developing controllers on Balancer Managed Pools unlock a variety of novel DeFi applications to manage treasury risk, automate trading strategies, and automate liquidity management. Balancer Pools are multi-token Liquidity Pools offering a great deal of flexibility to manage on-chain liquidity. Managed Pools are a relatively new pool that have started to gain developer attention in 2022. Both Pools use the Balancer weighted math formula, which is a generalization of the constant product formula made popular by Uniswap. Managed Pools build on the functionality as Weighted Pools; they have added functionality such as pool managers, circuit breakers, and active token reweights.

The nature of these Balancer Pools has led to a lot of interest and development in various controllers built to handle different use cases. Implementing controllers can optimize the performance of Liquidity Pools, manage treasury risk, and automate trading strategies. In addition to the Managed Pool controllers, there is active development on controllers for Managed Pools. Managed Pool controller design solutions are being explored and built both off-chain and on-chain. Additionally, implementing these controllers can also manage other sources of liquidity by taking inputs from those sources of liquidity, such as bonding curves and AMMs.

Two controller designs being used in production are Olympus Range Bound Stability (RBS) system on vanilla Weighted Pools and Aera’s risk aware treasury manager on a Managed Pool. Additionally, on Ethereum, Valory is building a smart Managed Pool (SMP) based on their off-chain autonomous agent bot infrastructure. Orb is building a Managed Pool controller (MPC) to manage Managed Pool state parameters on the chain directly. On Celo, GoodDollar and Symmetric are building a Managed Pool controller for bonding curves.

Weighted Pools have several critical advantages in decentralized finance. They can be used to create a rebalancing index fund that automatically adjusts the proportions of its assets to maintain a consistent investment strategy. They can also reduce the risk of impermanent loss, which occurs when the value of an asset in a Liquidity Pool fluctuates while the asset is being held in the Pool. Additionally, Weighted Pools allow liquidity providers to take a directional view of the market in the Pool to reflect their expectations about the future performance of those assets.

Managed Pools extend Weighted Pool functionality to include LP whitelists, the ability to include up to 50 tokens in a Pool, gradual swap fee updates, dynamic token weights, and circuit breaker mechanics on Pool tokens. The flexibility of Managed Pools can also be overwhelming, and additional infrastructure is being built to support automated liquidity management.

The Olympus Range Bound Stability (RBS) system is an off-chain controller design for Balancer Pools that is used to help control Olympus emissions with respect to price movements. It does this by maintaining a spread of deep liquidity in the market to enforce a price range for the OHM token. The goal of RBS is to dampen market volatility to stabilize the OHM price within a predetermined range. Olympus uses a vanilla Weighted Pool in its RBS system, which currently lacks weight rebalancing capabilities. Currently, manual rebalancing is required to maintain a 50/50 weight balance. In the future, Olympus will automate this process for larger rebalances by using the Balancer TWAMM.

The Range Bound Stability (RBS) controller has a number of parameters that define its behavior. The numeracy of the variables shows that there is no theoretical limit to the variables that one can put in a controller design. Instead, the limit is purely computational, and the more controller variables there are, then the greater the likelihood the controller will suffer from the curse of dimensionality.

To set up the RBS parameters, non-agent based simulations were used to optimize for the best parameter variable values.

• Reserve Factor: Determines the total capacity (budget) that the protocol can spend on market operations. Expressed as ask/bid factor in the charts. Directly related to treasury holdings of reserves.
• Cushion Factor: Allocates a percentage of the total market operation capacity to the cushions (the rest is used when the walls are activated).
• Wall Spread: Determines the price offset of the walls from the target price (simple moving average, chosen to be 30d MA). Expressed as wall in the charts.
• Cushion Spread: Determines the price offset of the cushions from the target price (simple moving average, chosen to be 30d MA). Expressed as cushion in the charts.
• Reinstate Window: Determines the required amount of epochs that the price should spend inside the range before resetting the capacity for the market operations when previously depleted.
• Max Liquidity Ratio: Establishes the treasury ratio between liquidity and reserves. The treasury will dynamically adjust its composition based on this ratio.
• Moving Average Duration: Determines how fast/slow the price target is adjusted by setting the length of the moving average. This lever hasn’t been explored in the initial RBS simulations and has been hardcoded to 30 days based on the Policy team’s knowledge of the protocol and past price action.
• Mint and Sync: Activates mint and sync above a certain treasury premium.
• Reward Rate: Apart from the framework approved in OIP-18, more advanced reward rate controllers have also been tested.

The Aera vault is designed to be used by decentralized autonomous organizations (DAOs) to manage their treasury balance sheets. Aera allows DAOs to deposit various ERC20 tokens into a treasury manager vault. The Aera vault also has safety features such as trade pausing, weight-invariant withdrawals and deposits, and a withdrawal validator module with a notice period to withdraw all funds.

Aera vault contracts live on-chain but have an off-chain component to calculate the optimal parameters for the vault strategies before the parameters are submitted to the vault on-chain. The Aera team uses agent-based simulations via a Python domain-specific language (DSL) on Gauntlet’s proprietary platform to test and submit vault parameters. Parameter submitters are rewarded with Aera inflation for submitting risk parameters. At the same time, arbitrageurs may receive Aera bonuses for trading against the vault.

The Aera vault uses a two-speed incentive mechanism that has a “fast” and “slow” path to optimize its rebalancing strategy. The slow path represents a portfolio strategy path that arbitrageurs do not impact whereas the fast path introduces arbitrageurs who trade against the vault to rebalance the portfolios.

The Aera vault has two versions: V1, which is live on Polygon and supports ERC20 tokens, and V2, which is in development and plans to add price oracle circuit breaker support and ERC4626 vault shares. Aera V1 uses Balancer’s Managed Pool on Polygon and has essential circuit breaker support and arbitrage controls. It is vulnerable to arbitrage if spot prices do not agree with current market prices.

Valory is a team that focuses on building open-source autonomous applications on distributed ledger technology. Their Autonolas application uses the Open Autonomy framework to manage multi-agent services off-chain, extending smart contract functionality and allowing complex operations to be executed in a decentralized, trust-minimized, and transparent way. Autonomous sources can pull data from various sources, such as AWS storage buckets and crypto-native data sources like IPFS, Ceramic, or The Graph. Agents that run services must agree on servicer terms similar to service level agreements (SLAs) and achieve consensus using the tendermint library, which is the same consensus method used by the Cosmos ecosystem. Valory recently received a Balancer grant to extend the current Managed Pool structure to include automation via smart Managed Pools (SMPs), which use autonomous agent software to create robotic MP managers.

Source for diagram

Orb Collective is leading the development and adoption of Managed Pools and has developed the MP controller V1 with features including the ability to add/remove tokens, an emergency stop, token trading and reweighting, adjusting the Managed Pool management fee, transferring manager rights, and updating circuit breakers. The Managed Pool state is managed by state parameters under the direction of a controller smart contract.

One complex feature that the Managed Pool controller V1 provides is the ability to add or remove tokens from a Managed Pool without providing initial seed capital. This mechanism relies on arbitrageurs to fill or drain the pool’s token balance and restore the Managed Pool to its desired composition.

When initial token liquidity is being added from a Managed Pool, the Managed Pool controller has to consider two distinct states. The first state occurs when a token’s liquidity weight is going from 0% to the minimum 1% weight. The current mechanism enables trading by using the Managed Pool controller to set a virtual balance to get around the initial 0 liquidity weight. A swap fee is then used to incentivize further rebalancing and smooth arbitrage opportunities as the new token is added or removed. The second state occurs when the token is going from the 1% minimum weight to the desired weight. Arbitrageurs are incentivized by a gradual weight shift until the desired weight is reached.

The flexibility of Managed Pools allows for multiple techniques for adding and removing tokens. For example, token replacement could involve trading all of Token A for Token B. Another technique, which involves trust and custody assumptions for the manager, is for the Managed Pool controller to add Token A, then provide the minimum Token A liquidity denominated in Token A as seed liquidity.

A canonical bonding curve is a trading function that determines the swap rate between two different assets, setting the price between the ratio of the assets being traded. Bancor initially popularized the concept. Bancor’s bonding curve uses a constant reserve ratio (CRR) to calculate the price of a bonding curve swap. A higher CRR means there is more supply in liquidity to absorb volatility. In comparison, a lower CRR means there is less liquidity and less in circulation, which can be considered as a “credit” compared to the original amount. However, this bonding curve design is susceptible to sandwich attacks and encourages speculation.

An allocation curve design is a more general bonding curve that improves the canonical bonding curve sandwich attack flaw. Allocation curves introduce harbinger-like taxes to make token allocation between investors and speculators. The investment efficiency becomes more efficient for investors than speculators and aims to make token allocation more equitable.

Recently, there has been interest in providing controllers for bonding curves to extend DeFi composability and liquidity depth around bonding curve token liquidity. Carbon, created by the Bancor team, manages bonding curve liquidity across multiple bonding curves on-chain using an asymmetric liquidity design. Instead of providing liquidity to a single curve that trades symmetrically in both directions, users provide liquidity to two curves that each trade in one direction. This design gives users greater control to express their trading preferences.

Asymmetric liquidity allows for the creation of individual user strategies composed of two bonding curves, where each curve executes irreversible trades. This allows users to create automated trading strategies consisting of one or two on-chain limit or range orders for any given token pair. Each order is represented by a unique, adjustable bonding curve.

The specifics of Carbon require Bancor DAO governance approval and are subject to change, with voting occurring via Carbon’s proposed governance token, vBNT. Although Bancor governance might make Carbon adoption difficult outside of Bancor, the ideas of asymmetric liquidity are similar to Managed Pool liquidity, where the token weight composition is mapped to a range of buying and selling price ranges for tokens within the Pool.

Unlike Carbon, which can only manage liquidity between bonding curves, the Balancer Managed Pool controller can operate between different sources of liquidity such as a bonding curve and a Managed Pool. The Managed Pool controller can act as a bridge between the two sources of liquidity, thereby creating a unified framework to manage on-chain liquidity.

This section examines how Managed Pool controllers can unify liquidity in a Managed Pool and a bonding curve under a single controller design. We explore design considerations and tradeoffs to adapt a Managed Pool controller. We incorporate bonding curve state parameters, such as circuit breakers, the ability to add and remove tokens, token weights and fees, and constant reserve ratios.

Circuit Breakers

The circuit breaker allows automatic predefined responses in emergency situations, such as when a highly volatile market is affecting the underlying liquidity in either the Managed Pool or the bonding curve. The circuit breaker is designed to block the acquisition of a token if it falls below a certain threshold such as in a hack that drains a token in the Pool or another catastrophic event. Suppose the CRR between two tokens in a bonding curve is unstable. In that case, the circuit breaker in the Managed Pool would halt trading. If the Managed Pool is the primary source of liquidity, enabling the circuit breaker would cause liquidity to freeze and prevent the reserve ratio from deteriorating further. Although the circuit breaker does not solve the issue directly, it provides time to develop a solution to restore the reserve ratio to a more stable level.

Add/Remove Tokens

There are many cases where the Managed Pool token index needs to be changed. For example, when new partner tokens need to be added to the Managed Pool or when liquidity migration occurs and old tokens need to be removed. Orb is researching and developing best practices for adding and removing tokens through the on-chain Managed Pool controller. For example, many tokens may need to be transferred from the Managed Pool to the bonding curve to adjust the reserve ratio.

Dynamic Token Weight and Fee Management

Finally, dynamic token weight management is a more general controller feature that enforces the monetary policy set by the controller. There is flexibility to automate token weight management around desired reserve ratios or other economic conditions that a DAO sees fit by modifying the controller.

The canonical bonding curve typically has ways to collect fees. However, suppose the Managed Pool holds most of the liquid tokens from the bonding curve. In that case, the Managed Pool’s swap fees could also be used to collect fees for the bonding curve if they are added to it regularly. Creating a dynamic fee policy for the Managed Pool controller also makes a dynamic fee policy for the bonding curve.

Weighted and Managed Pools offer a versatile solution for managing multiple sources of on-chain liquidity. The use of controllers to automate and optimize these pools is actively being developed. These controllers also allow for managing external sources of liquidity, such as bonding curves and AMMs, by taking inputs from those sources. They provide a powerful design paradigm for creating new DeFi applications that offer new liquidity strategies across various tokens and assets ranging from automated trading to treasury management.

Learn Crypto Trading, Yield Farms, Income strategies and more at CrytoAnswers
https://nov.link/cryptoanswers