Aquarius AMM: Token Address Migration Limitations and Mitigation Strategy

1. Introduction

In decentralized finance (DeFi) platforms, token contracts sometimes undergo migrations to new addresses due to upgrades, bug fixes, or protocol changes. While such migrations are essential for the evolution and security of tokens, they can pose challenges to Automated Market Makers (AMMs) like Aquarius. In particular, Aquarius liquidity pools are designed with fixed token addresses at initialization, making it difficult for the protocol to adapt when a token’s contract is migrated to a new address. This document outlines the limitations of Aquarius AMM regarding token address migration and provides a mitigation strategy for handling such cases.

2. System Limitations: Token Address Migration

2.1 Fixed Token Addresses in Liquidity Pools

When a liquidity pool is created in Aquarius, the token addresses involved are hard-coded into the pool's structure. The pool address itself is derived using a hash that includes the token addresses. This ensures that the pool can efficiently track and manage liquidity and trading with those specific tokens. However, it also means that:

• Once the pool is created, the token addresses cannot be changed.

• If one of the tokens in the pool undergoes a migration to a new contract address, the pool cannot automatically recognize or switch to the new token address.

2.2 Risks to Liquidity Providers (LPs)

The primary risk posed by this limitation is that LPs who have deposited liquidity into a pool that includes a migrated token may find that:

• The liquidity associated with the old token becomes locked, as the token is no longer recognized or used in the wider ecosystem.

• Withdrawals may still be possible, but the token itself may have lost value or utility.

• Slow or unaware LPs could face financial loss if they do not react in time to the migration.

2.3 Impact on Users

• Loss of Liquidity: If a token migrates to a new address, LPs need to manually withdraw their liquidity from the affected pool and deposit it into a new pool that recognizes the new token address.

• Disruption to Trading: Pools with migrated tokens may see disruptions to trading, as the old token becomes obsolete and liquidity is withdrawn.

3. Mitigation Strategy: Handling Token Migrations

Aquarius AMM does not support automatic token address migration. However, the following mitigation strategies can help protect LPs and ensure smooth transitions when token migrations occur.

3.1 Communication and Alerts for Token Migrations

To reduce the risks of token address migration, the Aquarius protocol will provide clear communication to LPs and users when a token migration is detected or announced. This includes:

• Alerts and Notifications: Inform LPs through the UI and other communication channels (e.g., social media, email, etc.) when a token migration is pending or has occurred.

• Warnings on Pool Creation: If there is any known risk of token migration (e.g., for tokens that frequently upgrade or have planned migrations), users may be warned when creating or adding liquidity to such pools.

3.2 Manual Withdrawal and Redeployment of Liquidity

In the event of a token migration:

1. Pool Pause Option: The pool admin has the ability to pause the affected pool to prevent further deposits or trades involving the obsolete token. This allows LPs to safely withdraw their liquidity.

   • Example: The pool admin can issue a command to pause the pool when a token migration is detected.

2. Liquidity Withdrawal: LPs will be required to manually withdraw their liquidity from the old pool. The withdrawal process will remain functional even if the token has migrated, allowing users to retrieve their share of liquidity.

   • Example: An LP who has deposited Token A (which has migrated to a new address) and Token B into a pool can still withdraw their liquidity as Token A (old) and Token B.

3. New Pool Creation: A new liquidity pool can be created using the new token address. LPs can deposit their withdrawn liquidity (including the new version of the migrated token) into the newly created pool.

   • Example: Once Token A migrates to Token A (new), the pool admin or community can create a new pool that uses Token A (new) and Token B.

3.3 Migration Assistance via Contract

To facilitate a smooth migration process for LPs, the Aquarius protocol could provide a migration contract that automates the withdrawal of liquidity from the old pool and redeposit into the new pool. This contract would:

• Automatically withdraw liquidity from the old pool on behalf of the user.

• Deposit the equivalent liquidity into the new pool that uses the updated token addresses.

• Ensure the user receives the appropriate LP tokens for the new pool.

Example Pseudo-code for Migration Contract:

fn migrate_liquidity(user: Address, old_pool: Address, new_pool: Address) -> Result<(), Error> {
    // Step 1: Check user’s LP balance in old pool
    let lp_balance = old_pool.share_id().balance(user);
    
    // Step 2: Withdraw user's liquidity from old pool
    let withdrawn_tokens = old_pool.withdraw(user, lp_balance)?;
    
    // Step 3: Deposit liquidity into new pool with updated token addresses
    new_pool.deposit(user, withdrawn_tokens, lp_balance)?;
    
    Ok(())
}

This contract ensures that LPs can easily transition from the old pool to the new one without manually managing the withdrawal and deposit processes.

3.4 Timely Communication with Token Issuers

In cases where tokens plan to migrate, the Aquarius team should establish communication with the token issuer to:

• Coordinate migration events.

• Inform LPs in advance about the upcoming migration and provide instructions on how to withdraw liquidity and migrate to the new pool.

• Collaborate on migration strategies to ensure smooth transitions and minimize losses for liquidity providers.

4. Recommendations for Liquidity Providers (LPs)

4.1 Stay Informed About Token Migrations

It is crucial for LPs to stay informed about any potential or upcoming token migrations. This includes:

• Monitoring communication channels for updates from the token issuer and the Aquarius protocol team.

• Understanding the risks of providing liquidity to tokens that may migrate to new addresses in the future.

4.2 Act Promptly During Token Migrations

In the event of a token migration:

• Withdraw Liquidity Promptly: LPs should withdraw their liquidity from the affected pool as soon as possible to avoid being stuck with an obsolete token.

• Redeploy Liquidity in New Pools: Once a new pool with the migrated token is available, LPs can redeposit their liquidity to continue earning fees and rewards.

4.3 Plan for Migration Risks

When adding liquidity to a pool, LPs should assess the likelihood of token migrations and understand the potential impact. For tokens that frequently upgrade or have planned migrations, LPs should be prepared to migrate their liquidity as necessary.