> For the complete documentation index, see [llms.txt](https://docs.aqua.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aqua.network/amm-and-pools/system-limitations/aquarius-amm-token-address-migration-limitations-and-mitigation-strategy.md).

# Token address migrations

### Introduction

In DeFi, token contracts occasionally migrate to new addresses due to upgrades, bug fixes, or protocol changes. While such migrations can be necessary, they present challenges for AMMs like Aquarius.

Aquarius liquidity pools are initialized with fixed token addresses and cannot automatically adapt when a token's contract migrates. This page describes the limitation and the recommended way to handle migrations.

### The limitation: fixed token addresses

When an Aquarius liquidity pool is created, the token addresses are hardcoded into the pool's structure. The pool's unique address is derived from a hash of these token addresses. This means:

* Token addresses cannot be changed once a pool is created.
* If a token migrates to a new contract address, the pool cannot recognize or switch to the new token.

#### Risks to liquidity providers

* **Locked value** — liquidity associated with a migrated token stays in the pool as the old token, which may lose value or utility after migration.
* **Trading disruptions** — pools with migrated tokens may see reduced liquidity and trading activity as funds are withdrawn.
* LPs who don't react promptly to a migration may suffer losses if their deposited tokens become obsolete.

Withdrawals always remain functional: an LP who deposited an old token and a second token can still withdraw both even after the migration.

### Handling a migration

When a token migration is detected or announced:

1. **Aquarius notifies LPs** — through UI prompts, email updates, or social media announcements. If a token is known to have frequent upgrades or planned migrations, users may see a warning before creating or adding liquidity to a pool.
2. **The affected pool can be paused** — the pool admin can pause the pool, preventing further deposits or trades involving the obsolete token.
3. **LPs withdraw liquidity manually** from the old pool.
4. **A new pool is created** with the updated token address, and LPs redeposit their liquidity there.

#### Possible future automation

To simplify the process, Aquarius may introduce a migration contract that automatically withdraws liquidity from the old pool, deposits the equivalent liquidity into the new pool, and issues new LP tokens — reducing manual effort for LPs.

#### Coordination with token issuers

The Aquarius team collaborates with token issuers to plan migration events in advance, notify LPs early with step-by-step instructions, and coordinate on strategies that minimize disruption and losses.

### Recommendations for liquidity providers

* **Stay informed** — monitor official channels of both the token issuer and Aquarius, and be aware of tokens likely to migrate due to frequent upgrades or protocol changes.
* **Act during migrations** — withdraw liquidity from the affected pool promptly, then redeposit into the new pool to continue earning rewards.
* **Assess migration risk before providing liquidity** — consider how likely a token is to migrate and plan ahead for possible redeployment.