> ## Documentation Index
> Fetch the complete documentation index at: https://docs.burst.trade/llms.txt
> Use this file to discover all available pages before exploring further.

# Graduation & Merge

> How Burst selects canonical tokens and merges duplicates at graduation.

Graduation is the decision point where Fusion takes effect. When a token's bonding curve fills, Burst checks its identity cluster and determines whether it becomes canonical or gets absorbed.

## Canonical market selection

If no canonical market exists yet for that identity cluster, the graduating token becomes canonical. It moves into a Meteora DAMM v2 pool normally.

If a canonical market already exists, the graduating token is merged into it.

## How the merge works

When a duplicate token graduates and a canonical market already exists, the full bonding curve raise (`85 SOL`) flows into the canonical token's liquidity pool.

<Steps>
  <Step title="Bonding curve fills">
    The duplicate token completes its bonding curve, raising `85 SOL` in the process.
  </Step>

  <Step title="SOL is injected into the canonical pool">
    Instead of creating a new Meteora DAMM v2 pool, the entire `85 SOL` raise is added as liquidity to the canonical token's existing pool.
  </Step>

  <Step title="Holders are airdropped canonical tokens">
    Every holder of the duplicate token receives an airdrop of the canonical token. The amount is proportional to the SOL value of their position at the time of migration.
  </Step>

  <Step title="Duplicate token is delisted">
    The non-canonical token is removed from primary discovery. The canonical market is now the only active market for that identity.
  </Step>
</Steps>

## Where the liquidity goes

The `85 SOL` raised by the duplicate token's bonding curve is not burned, lost, or sent to a treasury. It goes directly into the canonical token's Meteora DAMM v2 pool.

This has two effects:

* **Higher market cap** for the canonical token, since real SOL is being added to its liquidity.
* **Thicker liquidity** in the pool, which means less slippage and more stable trading for everyone.

<Note>
  Every merge makes the canonical market deeper. The more duplicates that graduate and get merged, the stronger the canonical token becomes.
</Note>

## What happens to holders

Holders of the duplicate token are not rugged. They are rewarded.

Each holder receives an airdrop of the canonical token equal to the SOL value of their position at migration. This means:

* **Duplicate holders** get exposure to the canonical token with deeper liquidity, making it easier to sell at fair prices.
* **Canonical holders** benefit because `85 SOL` of fresh liquidity just got injected into their pool, pushing the market cap higher and making liquidity thicker.

Both sides win. Duplicate holders get a better market to trade in. Canonical holders get a stronger token.

## Example

Suppose `$DOGE2` is the canonical token with an existing Meteora pool, and `$DOGE2COPY` just filled its bonding curve.

1. `$DOGE2COPY` raises `85 SOL` through its bonding curve.
2. That `85 SOL` is injected into `$DOGE2`'s Meteora DAMM v2 pool.
3. Every `$DOGE2COPY` holder gets airdropped `$DOGE2` tokens proportional to their SOL value at migration.
4. `$DOGE2` now has deeper liquidity and a higher market cap.
5. `$DOGE2COPY` is delisted from discovery.

## Why this stabilizes the canonical token

Injecting `85 SOL` of real liquidity into the canonical pool does two things:

* It raises the floor price, because the pool now has more SOL backing the same supply.
* It reduces price impact on sells, because the pool is deeper.

This creates a flywheel: the more duplicates that merge, the stronger the canonical token becomes, which attracts more attention and trading, which makes it even harder for future copycats to compete.

## Merge flow

```ts title="mergeIntoCanonical.ts" theme={null}
await mergeIntoCanonical({
  sourceMint: newTokenMint,
  canonicalMint,
  sourceTokenAccount,
  canonicalTokenAccount,
  user: payer.publicKey,
  meteoraPool: canonicalPool,
})
```

## Rules

* Name and ticker resolve from dominant merged representation.
* Image resolves from the dominant visual cluster.
* Overrides require dominance, margin, persistence, and multi-deployer support.
* Only graduated and merged variants are part of the decision set.