Curve and fees

A launched token can only be traded on fomo until it graduates

Every token launched here is a Token-2022 mint with a transfer hook attached. No buy, no sell and no wallet-to-wallet transfer settles without a signature from a fomo operator key.

That holds wherever the token was launched from and whatever wallet launched it. Launching through the program is what attaches the hook, so a token created outside fomo's interface is in exactly the same position: it cannot be traded anywhere, by anyone, including its creator, until it graduates.

At graduation the hook is removed from the mint for good and the token trades freely everywhere. See What happens at graduation.

A creator chooses two things and nothing else: a tier, which sets how much the curve raises before it graduates, and a fee rate between 1.25% and 5% that applies for the life of the token. Everything else is fixed by the launchpad program, which creates the token's Meteora DBC config itself.

Every launch gets its own config. That is what lets the rate and the fee recipients differ per token, and it is also how a pool is recognised as ours: the config's fee_claimer is the PDA at ["fees", base_mint] under the launchpad program, derivable from the mint alone.

The shape of a launch#

Supply is minted in full when the pool is created. There is no later minting and the mint authority is not retained. The share reserved for migration is held by the pool, not by the creator.

The five tiers#

Every tier opens at roughly the same valuation. What changes is how far the token has to travel before it graduates, and how much of supply is left in the migrated pool when it does.

Dollar figures are at $100/SOL, and the graduation caps are written here exactly as the create page shows them. The raise in SOL is the fixed quantity; the dollar caps move with the SOL price.

The share falls as the raise rises on purpose. Start cap, graduation cap and supply split are three numbers with two degrees of freedom:

r              = supply to the pool / supply on the curve
price multiple = 1 / r²
start cap      = graduation cap × r²
raise          = graduation cap × share of supply to the pool

Holding the share at 20% across every tier would make Tier E open 16x dearer than Tier A. Falling shares keep the opening price steady instead.

Caps are in the quote token, not dollars

DBC denominates market caps in the quote token, and the quote here is SOL. The dollar figures above float with the SOL price. The tier itself is a raise in SOL, and that does not move.

The graduation price is the raise divided by the migration supply, which is also the price the DAMM v2 pool is seeded at, so there is no step change in price at migration.

Trading fees#

Charged in quote (SOL) only, never in the token, on the curve and after graduation alike. The rate is the same before and after migration. If a creator picks 2.5%, every trade pays 2.5% for the life of the token.

Where each trade's fee goes#

Three shares, in this order:

• Meteora takes 20% of every fee. This is hardcoded in DBC and in DAMM v2 and there is no configuration that changes it.
• hodl takes a flat 0.75% of trade value, not a share of the fee. It does not grow when a creator picks a higher rate.
• The fee recipients take everything else, split by the basis points the launch named.

1.25% is the floor because below it there is not enough left after Meteora's fifth to cover hodl's 0.75%. DBC's own floor is 0.25%, so ours is the stricter one and the launchpad's error is what a creator sees.

The volatility surcharge#

Meteora's dynamic fee is on, on the curve and on the migrated pool. When a token is moving hard the rate rises, to at most 20% above the base, and decays back within a couple of minutes. So a 1.25% launch trades between 1.25% and 1.50%.

Nothing on chain separates the base fee from the surcharge once it has accrued, so the claim splits what it finds proportionally. While the surcharge is active every share scales up together, hodl's and the recipients' alike.

Fee recipients#

A launch names between one and five recipients, with shares in basis points totalling exactly 10,000. They are fixed at launch and stored on the token's ["fees", base_mint] PDA.

Naming more than one recipient, or naming the holder rewards wallet, each require a flag on the launchpad's global config.

What happens at graduation#

When the raise is met, the swap that completes the curve does three things.

The transfer hook is removed from the mint. DBC sets the hook program id to null and then clears the hook authority as well, so it can never be re-attached. After graduation the token is an ordinary Token-2022 token and trades anywhere, with no gate and no co-signature.

The pool migrates to DAMM v2. The migration supply and the raised SOL seed the new pool at the graduation price.

All migrated liquidity is permanently locked, to the same fee PDA. The position is owned by ["fees", base_mint] and 100% of it is permanently locked, so the liquidity can never be withdrawn by anyone. A locked position still earns every fee it would otherwise earn, so the same PDA collects the token's fees before and after graduation and the same split applies to both.

Claiming#

Fees accrue inside the pool and are pulled out by a claim. The claim is a permissionless crank: anyone may call it, and whoever does, it pays hodl and every recipient in that one transaction. There are no per recipient balances and nothing to track between claims.

The instruction is claim_fees, and it takes no arguments. Everything it needs is already on chain: who gets paid and in what proportion comes from the token's own ["fees", base_mint] account, and the rate that sets hodl's cut comes from the token's DBC config. The caller decides nothing, so there is no version of this call that pays the wrong people.

Pass the payout wallets as remaining accounts, all writable, in this order:

1. The global config's hodl_fee_wallet
2. Each fee recipient, in the order the launch stored them

Every one is checked against what the chain says, so a wrong order is rejected rather than mispaid.

What happens inside one instruction:

1. The launch's PDA signs a claim against the pool for everything it is owed.
2. The claim arrives as wrapped SOL, which is unwrapped into plain lamports.
3. hodl's cut comes off first, then the rest is split by the stored shares. The last recipient takes the remainder rather than its own rounded share, so integer division never strands a lamport.
4. Both temporary token accounts are closed and the cranker is refunded the rent it fronted, so cranking costs a transaction fee and nothing else.

The PDA ends the instruction holding exactly what it held before: its own rent and nothing else. That is the whole reason claiming and paying are one instruction rather than two.

Calling it with nothing owed fails rather than paying out zero, so a crank loop cannot quietly burn fees against an idle pool.

This covers the bonding curve. Fees earned by the migrated liquidity position after a token graduates sit in a DAMM v2 position, not in the DBC pool, and are claimed through a different path that is not built yet.

Reading the numbers correctly#

Market cap is not money in the pool. It is the token price multiplied by total supply. A token with a large market cap may have much less liquidity available for selling. The graduation target is a raise measured in SOL; it is not the displayed dollar market cap.

A base fee is not the entire transaction cost. The chosen rate is the base trading fee. The dynamic surcharge described above may increase it. Network fees, priority fees and account-creation rent are separate, and price impact depends on the trade's size and available liquidity.

For example, at a 2% base rate, a trade with 1 SOL of fee-bearing value incurs a 0.02 SOL base fee: 0.004 SOL for Meteora, 0.0075 SOL for hodl, and 0.0085 SOL for the configured recipients together. This example excludes the dynamic surcharge and network costs. Recipient shares divide the recipients' remainder, not the whole trade value.

Locked liquidity and claimable fees are different. A locked liquidity position prevents withdrawal of that position's principal; it does not stop token holders from selling or guarantee a price. Fees earned by the position are separate. The post-graduation claim path remains an implementation gap described above.