What it is
Liquidity migration is the process by which a token's tradable liquidity moves from one venue — typically a bonding curve or a purpose-built launch pool — to a different, more permanent venue like a standard AMM pool, once predefined conditions are met (e.g., a market cap threshold or raise target). It's the bridge between "this token is still finding its price via a launch mechanism" and "this token trades on normal open markets like everything else."
How it works
- A token launches on a bonding curve or bootstrapping pool, where price is set programmatically as a function of supply sold or time elapsed, rather than by an open order book or standard AMM.
- As buyers purchase the token, the curve's underlying reserve (e.g., ETH or a stablecoin collected from buyers) accumulates inside the launch contract.
- Once a migration trigger is hit — a target market cap, a raise amount, or a time limit — the contract (or an authorized keeper) stops trading on the curve.
- The accumulated reserve, plus a portion of the token supply, is deployed into a new AMM pool (commonly on Uniswap or a similar DEX), setting the initial price to match where the curve left off.
- LP (liquidity provider) tokens representing this new pool are often burned, locked, or sent to a treasury/timelock, so the liquidity can't simply be removed by the deployer immediately after migration (a common rug-pull vector this step is meant to prevent).
- From this point on, the token trades on the open AMM market like any other token, with price discovery happening through normal swaps rather than the original curve's formula.
Why designers use it
- Lets a token bootstrap price and initial distribution cheaply via a simple curve, then "graduate" to deep, composable AMM liquidity once it has proven demand.
- Reduces the risk of a project launching directly into an AMM with too little liquidity, which would make the token extremely volatile and easy to manipulate from day one.
- Gives the community a visible, credible milestone ("graduation") that signals the token has real traction, which itself becomes a trust and marketing signal.
- Automating the migration (rather than a manual deployer action) removes a point of discretion where a team could otherwise pull liquidity or delay indefinitely.
Failure modes
- Migration liquidity theft: if the contract logic or permissions around who triggers migration and where funds go are exploitable, an attacker or dishonest deployer can redirect the reserve instead of forming the pool.
- Price discontinuity at migration: if the new pool's initial price doesn't match the curve's final price precisely, arbitrageurs can extract value at the migration moment at the expense of existing holders.
- Never reaching the threshold: many tokens launched via curves never hit the migration trigger, leaving buyers stuck in a low-liquidity curve indefinitely with no path to an open market.
- Post-migration liquidity pull: if LP tokens aren't actually locked or burned as advertised, the deployer can still remove liquidity right after migration, a classic rug pull dressed up as a legitimate launch mechanic.
- Front-running the migration trigger: bots that detect an imminent migration can buy right before it and sell right after, capturing the discontinuity at ordinary participants' expense.
What to check before using it
- Verify what happens to LP tokens after migration — are they burned, locked with a visible timelock, or held by an unaccountable address?
- Check whether the migration trigger and the new pool's parameters are set autonomously by the contract or require a trusted party's action.
- Model the price continuity between the curve's final price and the new pool's opening price to estimate arbitrage risk.
- Confirm what happens to buyers' funds/tokens if the project never reaches the migration threshold.
- Review whether the migration transaction can be front-run or sandwiched, and whether protections (e.g., minimum output checks) are in place.