That's how Mellow ALM works for Velodrome Slipstream

Velodrome Slipstream: Recap

Slipstream is a concentrated liquidity AMM, a fork of Uni v3 with gauges to direct VELO emission and reward liquidity providers. Gauge rewards are distributed over time and only in the active tick, unstaked liquidity earns trading fees rather than emissions. The active tick is the liquidity around the current price that traders trade against. Slipstream redesigned the minimal price range boundaries, tick space, based on the liquidity factors of paired assets to reduce the effort for rebalancing a deposit to remain in the active tick.

Tick Spacings: Larger tick spacings will make the pools more user-friendly and reduce the frequency at which ALMs will need to rebalance liquidity. The pools will still be more capital efficient than v2, but potentially slightly less efficient than a UniV3 pool of the same tick size and fee. However, because emissions will be able to attract more liquidity, Velodrome will still offer better trade execution at lower levels of concentration. In addition, since Velodrome will be using custom fee algorithms, it can still maintain another advantage here: e.g., stable pool depegs and the fees go up, Mellow clAMM pools become more attractive to LP in versus the alternatives.

---

How Mellow ALM works for Velodrome Slipstream:

Once the Slipstream race begins, it never stops, but what if you want to be in an active tick even while asleep? That’s where Mellow ALM comes in. MALM offers a comprehensive solution for automated liquidity management in DeFi. Its modular architecture leaves room for adaptability, while its rebalancing mechanisms aim to optimize returns and minimize the effort for liquidity providers. The system's ability to interface with concentrated AMMs and employ various strategies positions it as a powerful tool for those who maximize yields.

To commemorate the launch of strategies deployed on top of Velodrome Slipstream, this piece provides an in-depth look at the user-facing processes of deposit and withdrawal, as well as the automated rebalancing of concentrated position and reward harvesting mechanisms.

The Mellow ALM system is built on a modular framework of smart contracts, deployed on EVM-compatible blockchains. Key components do the following:

1. Core Module is a central hub for integration/communication between modules.

2. AMM Modules connect to various DEXes: Uniswap, PancakeSwap, Velodrome.

3. DepositWithdraw Module handles partial deposits and withdrawals.

4. Strategies Module houses different liquidity management strategies.

5. Oracles provide price data and MEV protection.

6. LP Wrapper enables multiple LPs to pool resources into a single strategy.

In a top-level overview, when user deposit to Mellow ALM, their assets go to a separate velo ERC-721 token representing their CL position. The rebalance of this VELO-CL-POS is then managed by ALM strategy. Withdrawal is initiated by the user and triggers claim rewards and exit from the position.

Automated Processes: Rebalancing and Harvesting Rewards

While user deposits and withdrawals are crucial, the automated processes of Mellow ALM play a significant role in maintaining CL position in between. The primary automated function here is rebalancing, which ensures that the asset ratios within the pools remain in the active tick most of the time.

The rebalancing process begins with continuous monitoring of the liquidity pools. The rebalancer operates with a focus on minimizing slippage and transaction costs. By executing trades, the protocol can maintain a stable environment for the LPs. Rebalance occurs not exactly at the moment the active tick moves outwards position range, but shortly after, in about 30 to 60 minutes, to reduce price manipulation risks. This automated mechanism not only prefers moving single-side out-of-range positions closer to active tick to minimize swap fees but also optimizes for the risks associated with transforming impermanent loss to permanent one by not rebalancing in an abnormally volatile environment.

In addition to rebalancing, Mellow ALM automates the harvesting of rewards generated from gauge incentives. The Pulse Bot periodically assesses the accumulated rewards and executes a harvesting process. Let’s dive into rebalance details:

Rebalance Process

The rebalance process in Mellow ALM is a critical function that ensures strategy stays in an active tick and remains in an efficient range in the liquidity pool. This process involves several components, including the Rebalancer, Core, Strategy Module, Oracle, and AMM Module, all of which are implemented as smart contracts. Below is a detailed description of each step in the rebalance process as illustrated in the sequence diagram:

Step 1: Initiating the Rebalance

The rebalance process begins when the Rebalancer initiates the rebalance() function within the Core contract. This function serves as the entry point for the rebalance operation, indicating the need to adjust the asset allocations within the liquidity pools to align with the desired targets set by the strategy.

Step 2: Authorization Check

Upon receiving the rebalance request, the Core contract performs an authorization check to ensure that the action is being initiated by an authorized operator. This is done through the _requireAtLeastOperator() function, which verifies that the Rebalancer has the necessary permissions to execute the rebalance operation. This step is crucial for maintaining security and preventing unauthorized changes to the liquidity pools.

Step 3: Verifying Managed Positions

With authorization confirmed, the Core contract enters a loop to process each managed position within the liquidity pools. For each position, the Core contract interacts with the Oracle to verify that the pool is not distorted, ensuring that conditions such as price manipulation or significant market volatility are accounted for. This verification is executed through the ensureNoMev() function, which checks for potential issues that could affect the integrity of the rebalance operation.

Step 4: Retrieving Target Information

After confirming that the pool is stable, the Core contract requests information about the new target positions from the Strategy Module by calling the getTargets() function. This function retrieves the optimal asset allocations based on the current market conditions and the strategy defined for the liquidity pool. The Strategy Module responds with the new rebalance targets, which indicate the desired ratios of assets within the pool.

Step 5: Validating Targets

Once the Core contract receives the new targets from the Strategy Module, it performs a validation check using the _validateTarget() function. This step ensures that the proposed targets are feasible and meet the price impact constraints to the liquidity pool. The validation process helps to prevent errors that could arise from inappropriate asset allocations.

Step 6: Fetching Current Prices

Following the successful validation of targets, the Core contract interacts with Oracle again to obtain the current market price of the assets involved. This is done through the getPrice() function, which provides real-time price data necessary for executing the rebalance effectively. The Oracle responds with the current price, allowing the Core contract to make informed decisions regarding the adjustments needed.

Step 7: Unstaking Positions

With the targets validated and current prices obtained, the Core contract enters another loop to manage the existing positions within the liquidity pools. For each position, the Core contract communicates with the AMM Module to unstake the position from any farming or liquidity provision activities. This action is executed through the _beforeRebalance() function, which prepares the assets for the upcoming adjustments by ensuring they are no longer locked in any active strategies.

Step 8: Transferring Positions

After unstaking the position, the Core contract transfers the assets back to the Rebalancer. This transfer is a critical step that allows the Rebalancer to take control of the assets and execute the necessary adjustments. The Core contract also fills out the minimum liquidities required for benchmarking the rebalance.

Step 9: Transferring Control for Rebalance Actions

Once the position is transferred, the Core contract hands over control to the Rebalancer by invoking the call() function. This transfer of control allows the Rebalancer to perform the actual rebalance actions based on the new targets and current market conditions.

Step 10: Returning Control and New Position IDs

After executing the rebalance actions, the Rebalancer returns control to the Core contract along with the new position identifiers in a two-dimensional array format. This information is crucial for the Core contract to update its records and reflect the changes made during the rebalance process.

Step 11: Finalizing the Rebalance

The Core contract then enters another loop to process each managed position again. For each position, it verifies the parameters to ensure they are consistent with the new targets. The Rebalancer transfers the adjusted positions back to the Core contract, which then communicates with the AMM Module to stake the positions in the appropriate farming or liquidity provision activities using the _afterRebalance() function.

Summary

The rebalance process in Mellow ALM is a sequence of actions that ensures liquidity pools remain efficient and aligned with market conditions. By facilitating multiple techniques performed by contracts — authorization checks, position verification, target validation — the protocol effectively manages the complexities of asset reallocation in a decentralized finance environment.

Deposit Process

The deposit process in Mellow ALM is a structured sequence of interactions that ensures the seamless integration of a user’s assets into the liquidity pools. This process involves several components, including the Depositor, Core, AMM Module, Oracle, and Strategy Module. Below is a verbose description of each step in the deposit process as illustrated in the sequence diagram.

Step 1: Initiating the Deposit

The process begins when a user, referred to as the Depositor, decides to contribute tokens to a liquidity pool. The Depositor initiates this action by calling the deposit() function within the Core contract of the Mellow protocol. This function serves as the entry point for the deposit process, signalling the intent to provide liquidity.

Step 2: Validating Parameters

Upon receiving the deposit request, the Core contract makes three validation checks to ensure that the deposit can proceed without issues:

1. The Core contract first communicates with the AMM Module to validate the parameters of the deposit. This includes checking whether the specified token is supported, confirming the liquidity pool’s current state, and verifying that the deposit amount meets any minimum requirements.

2. The Core contract interacts with Oracle to validate the parameters related to market conditions. Oracle provides real-time price feeds and other relevant data that inform the protocol about the current market environment. This step is crucial to ensure that the deposit aligns with market dynamics and that the risk of impermanent loss is assessed accurately.

3. The Core contract then reaches out to the Strategy Module to validate the parameters concerning the investment strategy. The Strategy Module outlines the rules and guidelines for managing liquidity, including risk management strategies and claiming rewards.

Step 3: Validating the Position

Following the parameter validations, the Core contract enters a loop to validate the specific position being deposited. This involves checking the integrity and eligibility of the position. The Core contract performs a series of checks to ensure that the position is valid and that it adheres to the protocol's requirements.

Step 4: Transferring the Position

Once the position is validated, the Depositor transfers the position to the Core contract . This transfer is executed through a secure transaction that moves the specified tokens from the Depositor's wallet into the control of the Core contract. This step is critical as it formalizes the deposit and allows the protocol to manage the assets on behalf of the Depositor.

Step 5: Staking the Position

After the transfer is complete, the Core contract proceeds to stake the position in various farming or liquidity provision opportunities. This action is facilitated by calling the _afterRebalance() function in the AMM Module. By staking the position, the protocol actively engages the deposited assets in generating returns, contributing to the overall liquidity of the market.

Step 6: Writing Information About the Managed Position

Finally, the Core contract updates its internal records to reflect the new managed position. This involves writing information about the Depositor's contribution, including the amount deposited, the specific tokens involved, and any associated parameters that define the management of this position. This record-keeping is essential for maintaining transparency and ensuring that the Depositor can track their investment over time.

Summary

By involving multiple components — Core, AMM Module, Oracle, and Strategy Module — the protocol guarantees a secure and efficient process that streamlines liquidity provision and enhances user experience.

Withdrawal Process

The withdrawal process in Mellow ALM is a structured sequence of interactions that allows users, referred to as Withdrawers, to reclaim their assets from liquidity pools managed by the protocol. This process involves several components, including the Withdrawer, Core, and AMM Module, all of which are implemented as smart contracts. The following is a detailed description of each step in the withdrawal process as illustrated in the sequence diagram.

Step 1: Initiating the Withdrawal

The process begins when the Withdrawer decides to retrieve their assets from the liquidity pool. This action is initiated by calling the withdraw() function within the Core contract of the Mellow protocol. This function serves as the entry point for the withdrawal process, signalling the intent to remove liquidity and reclaim tokens.

Step 2: Validating Ownership

Upon receiving the withdrawal request, the Core contract  performs a critical validation step to ensure that the Withdrawer is the rightful owner of the liquidity tokens they are attempting to withdraw. This validation is essential to prevent unauthorised access to funds. The Core contract checks the ownership records associated with the liquidity tokens to confirm that the Withdrawer has the right to execute the withdrawal.

Step 3: Removing Managed Position Data

Once ownership is validated, the Core contract proceeds to remove any data related to the managed position from its internal records. This step involves clearing out the information that tracks the Withdrawer’s contribution to the liquidity pool, including details such as the amount of tokens deposited, accrued fees, and any other relevant metrics. This action ensures that the protocol's records are up-to-date and accurately reflect the current state of the liquidity pool.

Step 4: Unstaking the Position

Following the removal of managed position data, the Core contract enters a loop to handle the un-staking of the Withdrawer’s position. During this phase, the Core contract communicates with the AMM Module  to execute the _beforeRebalance() function. This function is responsible for removing the Withdrawer's assets from any farming or liquidity provision activities in which they were previously engaged.

The un-staking process involves several steps:

1. Communicating with AMM Module: The Core contract sends a request to the AMM Module to un-stake the Withdrawer's position. This action ensures that the assets are no longer locked in the liquidity pool or any associated farming contracts.

2. Executing Unstaking Transactions: The AMM Module processes the unstaking request by executing the necessary transactions to release the Withdrawer’s tokens. This may involve interacting with various smart contracts that manage the liquidity pools and farming strategies to ensure that the tokens are correctly un-staked and made available for withdrawal.

Step 5: Transferring the Position

After successfully un-staking the position, the Core contract transfers the Withdrawer’s tokens back to their wallet. This transfer is executed through a secure transaction that moves the specified amount of tokens from the liquidity pool to the Withdrawer’s address.

The transfer process is designed to ensure accuracy and security, with the Core contract confirming the amount being sent and verifying that the transaction adheres to the protocol's rules. Once the transfer is complete, the Withdrawer receives a notification confirming that the withdrawal has been successfully executed.

Methodology choosing optimal strategy parameters

The process of calculating the optimal width of strategy positions involves several key steps that leverage extensive historical transaction data.

1. Data Collection: The first step involves loading the complete history of swap event transactions for the desired liquidity pool. This data excludes burn and mint events, as these do not directly contribute to the earned fees from swaps. The focus is on the sqrtPriceX96 values from the swap events, which provide critical insights into price movements and liquidity dynamics. By analyzing these transactions, the algorithm can simulate the behavior of the liquidity pool under various market conditions.

2. Simulation of Swaps: A test script is implemented to apply all swaps sequentially. This script simulates the execution of each swap event as it occurred historically, allowing the protocol to reach the actual state of the pool without needing to perform real swaps. During this simulation, the script triggers a rebalance of the position whenever necessary, reflecting the dynamic nature of liquidity provision in response to market fluctuations. This step is crucial for understanding how different width parameters affect the pool's performance over time.

3. Performance Evaluation: The final step involves running a comprehensive analysis to calculate the fees earned from the position and the total amounts at the end of the simulation. By varying the width of the positions during these tests, the protocol can identify which widths yield the best returns. This iterative process allows for a thorough comparison of performance across different scenarios, ensuring that the selected parameters are optimized for profitability.

Selection of Optimal Width

The choice of width for the position is the result of extensive backtesting that reveals how liquidity behaves under various conditions. The optimal width is selected based on the simulation outcomes, focusing on maximizing returns while managing the risks associated with impermanent loss and market volatility. The backtesting approach ensures that the chosen parameters are robust and reflective of real market dynamics, rather than theoretical assumptions.

Want to know more about Mellow Protocol? Find us at:

Discord: https://discord.com/invite/mellow/

X/Twitter: https://x.com/Mellowprotocol/

Website: https://mellow.finance/

Docs: https://docs.mellow.finance/

GitHub: https://github.com/mellow-finance/