Skip to main content
DBC migration is the handoff from launch trading to long-term Meteora liquidity. During the bonding curve phase, traders buy and sell against a DBC virtual pool. When the quote reserve reaches the configured migration threshold, normal curve trading stops and the pool becomes eligible to create a DAMM pool.
For Token 2022 transfer-hook pools, curve completion also revokes the base mint’s transfer-hook program id and transfer-hook authority. DBC does this before DAMM v2 migration so the graduated mint can use DAMM v2 without relying on transfer-hook remaining accounts.

​
Migration Progress

The program tracks migration as a sequence of states. Some launches move from curve completion directly into the migration-ready state. Others need the locker step first, especially when base-token locked vesting is configured.

​
Migration Targets

New DBC configs and new pools must use DAMM v2. DAMM v1 remains available only for existing pools that were already configured with that target. DAMM v2 is the path for Token 2022 launches, transfer-hook launches, and quote mints that needed a DBC token badge. Transfer-hook launches use DAMM v2. The hook is active only during the DBC bonding-curve phase and is revoked when the curve completes. A DBC token badge is valid only inside DBC. DAMM v2 configs used by DBC include the CreatePoolWithoutMintValidation permission so a quote mint that is not permissionless-supported by DAMM v2 can still migrate.
DAMM v1 migration is deprecated for new configs and new pools. Existing DAMM v1 pools can still graduate. Token 2022 launches must use DAMM v2.

​
Transfer Fee Migration

migration_damm_v2 uses a separate deposit path when PoolConfig.version is 1 and either of these is true:
  • The config has a base transfer fee (transfer_fee_flag is 1).
  • The quote mint has a non-zero transfer fee or a live transfer fee config authority.
That path always migrates in compounding mode. It deposits the transfer-fee-excluded amount of each mint. The side whose fee takes the larger fraction of its budget is deposited at that post-fee amount. The other side is scaled by the same ratio: base rounds up, quote rounds down, so the deposited price stays at or below the ratio of the two post-fee budgets. The liquidity that reaches DAMM v2 is lower by the larger of the two fees. The part of the scaled side that is not deposited stays in the DBC vault and is added to protocol_migration_base_fee_amount or protocol_migration_quote_fee_amount. Claim it with claim_protocol_fee2. Each mint is transferred once. The full migrated liquidity is deposited into the first DAMM v2 position. The second position is taken from the first with split_position2, which moves liquidity without another token transfer. Each mint therefore pays its transfer fee once. Config creation checks that the sqrt price from those fee-excluded amounts is within 1% of migration_sqrt_price: abs(migration_sqrt_price - derived_sqrt_price) * 100 <= max(migration_sqrt_price, derived_sqrt_price). A miss returns InvalidCurve. The quote fee in that check is the current epoch. migration_damm_v2 does not run it again. A higher quote fee at migration deposits less, can move the price outside that 1% band, and adds more of the undeposited side to the protocol migration fee. A scaled amount of zero returns AmountIsZero. The badge does not record the fee. A TransferFeeConfig added later, including through the mint close authority, sends migration down this path, which then requires the transfer-fee config restrictions. A legacy config (version 0) uses the original migration path, which does not account for transfer fees. migration_damm_v2 rejects it when the quote mint’s current transfer fee is non-zero (QuoteMintHasNonZeroTransferFee).

​
What Migrates

At migration, DBC uses:
  • The configured quote threshold from the bonding phase.
  • The base token amount allocated for the migrated pool.
  • The migration price discovered by the curve.
  • The configured partner and creator liquidity distribution.
On the standard migration path, the pool is opened at migration_sqrt_price. The transfer-fee path can open below that price when one side loses a larger fraction of its budget to its fee.

​
Liquidity Ownership

DBC can split migrated liquidity between partner and creator buckets. Each bucket can include: The full distribution across partner unlocked liquidity, partner permanent locked liquidity, partner vesting liquidity, creator unlocked liquidity, creator permanent locked liquidity, and creator vesting liquidity must add up to 100%.
DBC requires at least 10% of liquidity to remain locked at day 1 after migration. Vesting lock durations are capped at 2 years.

​
DAMM v1 Liquidity

For DAMM v1 migration, liquidity is represented through LP tokens. After the DAMM v1 pool is created, partner and creator LP-token claims can become available according to the configured distribution. If LP tokens need to be locked, the lock step happens after the migrated pool exists. This path is simpler, but it is also less configurable than DAMM v2.

​
DAMM v2 Liquidity

For DAMM v2 migration, DBC creates position NFTs for the migrated liquidity. The migration flow:
  1. Creates the DAMM v2 pool.
  2. Creates migrated liquidity positions.
  3. Applies configured permanent locks or vesting locks.
  4. Transfers position ownership to the partner or creator owner.
This means DAMM v2 migration is not just a pool creation step. It also finalizes who controls the migrated positions and how much of that liquidity is locked.

​
Protocol Liquidity Migration Fee

DBC applies a fixed 0.2% protocol liquidity migration fee during migration. This fee is tracked as protocol migration base and quote amounts. In product terms, it reduces the amount of base and quote liquidity that enters the migrated pool and becomes part of protocol-claimable balances.
This protocol liquidity migration fee is separate from the configurable partner and creator migration fee.

​
Leftover After Migration

For fixed-supply launches, some base tokens may remain in the virtual pool after migration accounting. Those unused tokens are called leftover and can be withdrawn to the configured leftover receiver after the migrated pool reaches the created state. Leftover is covered in more detail in DBC Surplus and Leftover.

​
Mainnet Migration Keepers

Meteora operates migration keepers on mainnet to help eligible DBC pools graduate automatically. Both keepers migrate eligible pools when the bonding curve is complete and the quote-side threshold matches one of these quote mints: Both keepers also migrate Stock Token quote pairs when the threshold is at least 750 USD equivalent in the quote token. Both keepers also migrate a completed pool when the quote token is Jupiter Verified, has a Jupiter Organic Score greater than 50, and the token’s notional value is greater than 750 USD.
Migration keepers run on mainnet. For testing or manual flows, use the manual migrator, which supports mainnet and devnet.