How a token launch works

A game raises USDC and mints a token. This is the whole mechanism, including the parts that are easy to get wrong, so you can check it rather than take our word for it.

Read this part twice

Phases 1 to 4 carry a refund right you have to exercise, within 7 days of the pool opening. Do nothing and it lapses and you keep the tokens. Tokens that a refund gives up are transferred to the developer. Nothing in this design is ever burned.

The one number

A developer picks a single figure, the raise in USDC, and everything else follows from it. The supply is always 1,000,000,000 tokens, split three ways: 65% to the developer, 10% as the pool's opening inventory, 25% to backers. The price is the raise divided by the backers' 250,000,000 tokens, and it is the same price in every phase, so the fully diluted valuation at launch is exactly four times the raise.

Total supply
1,000,000,000, minted once, at scheduling. There is no second mint and no inflation.
Developer
65%, locked through the refund window and for any further period they published at scheduling.
Pool
10%, which becomes the pool's token side at launch alongside the USDC committed from the raise.
Backers
25%, sold across five phases at one price. A $20,000 raise prices the token at $0.00008 and values the whole supply at $80,000.

Five phases, one price

The raise runs in five equal bands of 20% each, and a phase advances only when it fills, never on a clock. Every phase buys the same 50,000,000 tokens for the same money. The single thing that differs is the refund right each one carries:

PhaseShare of the raiseTokensRefund right
120%50,000,000100%
220%50,000,00085%
320%50,000,00070%
420%50,000,00045%
520%50,000,000None

So backing early is not a discount, it is a larger share of your contribution that you can ask for back. Phase 5 carries no refund right at all, which is why it can take delivery of its tokens the moment the pool opens instead of waiting out a window.

Where the money sits

Summed across those five bands, the ladder puts 60% of the raise in escrow and commits 40% to liquidity. The escrowed 60% is what the refund rights are paid from, and it stays funded and untouched until the window closes.

No USDC from the raise reaches the developer. Ever.

Escrowed money goes to a backer or into the pool, and there is no third destination and no instruction that creates one. What the developer receives is tokens: their own allocation, the tranches that refunding backers give up, and the tokens bought on the pool by the contributions of backers who keep theirs.

A raise that does not fill by its deadline pays everyone back in full instead. Backers withdraw their own contribution themselves; nothing about a failed raise depends on us doing anything.

What happens at launch

1

The pool opens

The 10% inventory and the committed 40% of the raise become a Meteora pool. That is the moment the token has a market price, and everything below is measured from it.

2

The developer's allocation locks

Through the refund window at minimum, plus any longer period they chose when they scheduled, which is published before anyone backs. It is not their choice at the time: without it the real float would be several times the sale and every number on the page would be false.

3

A 7-day window starts

Seven days, hardcoded, never extended. There is no field for it and no argument that moves it. Phase 5 has no right to exercise, so it takes its tokens immediately.

4

Every phase 1–4 backer chooses

Two options, described below. Choosing nothing is also a choice, and it is the one that keeps the tokens.

The choice, and what each one does

Exercise the refund
You are paid the refundable share of what you contributed, in USDC, out of escrow. Your tranche of tokens goes to the developer. It has to be actively exercised inside the window: it is a right that expires, not a setting.
Keep the tranche (or do nothing)
You keep your tokens, and your escrowed contribution buys the token on the pool at the market price. Those purchased tokens go to the developer as well. It is a disclosed mechanic that runs the same way for everyone, not discretionary buying by anybody.

Nothing is destroyed

A refunded tranche is not burned and neither are the tokens the window's buys purchase. Both are transferred to the developer, where they are subject to the same lock as the rest of the developer's allocation. If you have read otherwise anywhere, that description was wrong.

When the window closes, anyone who never chose is defaulted to keeping their tranche, automatically, and the on-chain record of the backing is collected. That is why a settled launch shows no contribution record for a wallet that took part: the record has done its job and been closed.

Two things that are true at any raise size

Whatever the raise, and whatever share of backers exercise their refunds, the arithmetic lands on both of these. They are the design's actual claims, and they are checkable on chain rather than promised here:

At least 40% of the raise ends up as pool liquidity
The committed 40% is there from the start, and every escrowed dollar that is not refunded is spent buying on the pool, which leaves it there too.
Every circulating token is covered at least 1:1 by pool USDC at the launch price
Refunds remove tokens from the float at the same time as they remove USDC from the pool side, so the ratio cannot fall below one however the window goes.
Neither of those is a floor under the price. Liquidity is not a buyer, a ratio at launch is not a ratio next month, and a token can trade far below what it was sold for. What they say is narrower and worth exactly what it says: the pool is really funded, and the sale did not create tokens with nothing behind them.

What it costs

To back
1% of your contribution, on top of it, taken at the time and not refundable. Backing also pays Solana rent for the accounts it opens, a fraction of a cent each.
To raise
Nothing. indie.fun takes no share of the raise itself.
To trade
2% of each trade, inside the pool, split evenly between the developer and indie.fun. Each half accrues in USDC to a permanently locked liquidity position and is claimed by the wallet that owns it — the developer’s from their game’s Token tab, and never out of the liquidity itself.

Points

Keeping your tranche rather than refunding it earns 10 points per USDC held. Points are deliberately off-chain and are not a claim on this launch, its token, or its escrow: they are a record of having backed a launch and stayed in it, which future raises can recognise. One row per wallet per launch, written when the tranche is kept.

Trading afterwards

The token trades like any other SPL token once its pool is open. The swap box on a launch's page routes through Jupiter, and falls back to the launch's own pool when Jupiter has no route for it, which is usually the case in the first hours. You can equally trade it anywhere else that lists it; nothing about the token depends on this site after the window has closed.

What can go wrong

The plain version, because a page that only lists the good parts is not documentation:

  • The token can be worth less than you paid, immediately and permanently. The refund right covers a share of your contribution for seven days and then it is gone.
  • Missing the window costs you the right. It is never extended, for anyone, for any reason.
  • The developer's allocation unlocks eventually. 65% of the supply reaching a market is a fact you can plan around, and the unlock date is published before you back.
  • A game is not a business yet. Backing a launch is not a share of the game, a claim on its revenue, or a promise that it ships.
  • Test launches are play money. Anything wearing a TEST MODE banner runs on Solana devnet, where the USDC and the tokens are free to mint and worth nothing.

Checking it yourself

Every number above is on chain. A launch's page shows the mint address once the raise succeeds, the pool address, how much escrow is still funded, how much has been refunded, and how much has been spent buying on the pool, all of which any explorer will confirm independently of us. The rules are enforced by the launch program rather than by this site: we cannot extend a window, move escrow, or unlock an allocation early, and neither can a developer. See also Tokens for what the SDK exposes to a game's own code.