How a token launch works

A game raises money and mints a token. This is the whole mechanism, in plain words, so you can check it instead of taking our word for it.

The two things people get wrong

A refund has to be claimed within 7 days of the pool opening. Do nothing and it expires and you keep your tokens. Tokens you give up by refunding are transferred to the developer. Nothing is ever burned.

The one number

A developer picks one number: the raise. Everything else follows from it. The supply is always 1,000,000,000 tokens: 70% to the developer, 10% to the pool, 20% to backers. The price is the raise divided by the backers' 200,000,000 tokens, the same in every phase, so the token's full valuation at launch is five times the raise. The pool opens at that same price.

Total supply
1,000,000,000, minted once. No second mint, no inflation.
Developer
70%, locked through the refund window plus any longer period published at scheduling.
Pool
10%, paired at launch with half the raise to open the pool.
Backers
20%, sold across five phases at one price. A $20,000 raise prices the token at $0.0001 and values the supply at $100,000.

USDC or SOL

The developer picks the raise's currency when they schedule: USDC or SOL. It is fixed from then on. You contribute in that asset, refunds are paid in it, the pool is quoted in it, and the trade fee accrues in it.

A SOL raise is held on-chain as wrapped SOL, an ordinary SPL token. Your transaction wraps what you spend and unwraps what comes back, so your wallet only ever shows SOL. The only visible difference is the allowed size of the raise: 100 to 10,000,000 for USDC, 0.5 to 50,000 for SOL.

Five phases, one price

The raise runs in five equal bands of 20%. A phase advances when it fills, never on a clock. Every phase pays the same price for the same 40,000,000 tokens. The only difference is the refund right:

PhaseShare of the raiseTokensRefund right
120%40,000,000100%
220%40,000,00080%
320%40,000,00070%
420%40,000,000None
520%40,000,000None

Backing early is not a discount. It is a bigger share of your money you can ask back. Phases 4 and 5 have no refund right, so they can take their tokens the moment the pool opens instead of waiting out the window. (The block of tokens a contribution buys is called a tranche in the launch program and on the chain; here it is just called your tokens.)

Where the money sits

Across the five phases, 50% of the raise goes into escrow and 50% into the pool. The escrow is what refunds are paid from, and it stays funded and untouched until the refund window closes.

The developer is not paid out of escrow.

Escrowed money goes to a backer or into the pool. Nowhere else. The developer is paid in tokens: their own allocation, the tokens refunding backers give up, and the tokens bought on the pool with the escrow of backers who keep theirs. The pool does charge its 2% fee on those purchases like any other trade, and 0.8% of each trade accrues to the developer's locked liquidity position. That fee income, earned from trading after launch, is the only way any of the raise's money reaches the developer.

If the raise does not fill by its deadline, everyone gets their full contribution back. You withdraw it yourself, from your own wallet; it does not depend on us.

What happens at launch

1

The pool opens

The 10% inventory is paired with half the raise in a Meteora pool. The token now has a market price, and it is the price backers paid, not a new one.

2

The developer's allocation locks

Through the refund window at minimum, plus any longer period they published at scheduling. It is not their choice at the time: without the lock the real float would be several times the sale.

3

A 7-day refund window starts

Seven days, hardcoded, never extended, for anyone. Phases 4 and 5 have no refund to wait on and take their tokens immediately.

4

Backers with a refund right choose

Two options, below. Doing nothing is also a choice: it keeps the tokens.

The choice

Take the refund
You are paid the refundable share of your contribution, from escrow, in the raise's asset. Your tokens go to the developer. You must claim it inside the window: it is a right that expires, not a setting.
Keep your tokens (or do nothing)
You keep your tokens, and your escrowed contribution buys the token on the pool at the market price. The bought tokens also go to the developer. This runs the same way for everyone; nobody buys at their own discretion.

Nothing is destroyed

Refunded tokens are not burned, and neither are the tokens the escrow buys. Both go to the developer, under the same lock as the rest of their allocation.

When the window closes, anyone who never chose keeps their tokens by default, and the on-chain record of the backing is closed. That is why a settled launch shows no contribution record for a wallet that took part.

The deadline only removes the refund. Taking delivery has no deadline: you can send that instruction during the window or long after it, without waiting for the default to be filed for you. The button is on the launch's page, and indie.fun/claim builds the same transaction straight from the chain if this site is down.

How those purchases are made

The escrow of every backer who keeps their tokens is spent buying on the pool. That is a lot of buying into a market that is hours old, so it is deliberately not one big buy. The rules are enforced by the launch program, not by this site, so they hold whoever sends the transaction:

Capped
Each purchase is limited to half the size at which buying in front of it and selling behind it would break even, computed from the pool's depth and fee at the moment of the trade. That makes each purchase not worth trading around, and it is why the figure is read live rather than fixed at launch.
Spaced
The program refuses the next purchase until a set number of Solana slots have passed, about a minute on mainnet. A standard raise takes roughly ninety minutes to spend, a larger one longer. Without the gap, several capped buys in a row would add up to the one big buy the cap prevents.
Sent only by indie.fun
Nobody else can trigger a purchase, so nobody outside can fire one off and trade in front of it. Every destination is fixed by the program; the sender only picks the moment.
At a random moment
Each purchase lands at a random point within its minute, and goes through a private relay where one is configured rather than being broadcast first. Both exist so the next purchase is not something to wait for.
With no price floor
Deliberately. A slippage limit cannot improve the price; it can only refuse the purchase and leave the escrow stuck. When a purchase executes badly, the party receiving fewer tokens is the developer, not a backer. The size cap does the protecting.

These purchases raise the price on the pool: a buy against a constant-product pool moves the price it executes at. The pool trades throughout the window, so anyone buying there is buying into the same pool these purchases arrive in. How much escrow is committed, how much has been spent and what it bought are all readable on the launch account on chain.

Two things that are true at any raise size

Whatever the raise, and however many backers refund, both of these hold. They are checkable on chain rather than promised here:

At least 50% of the raise ends up as pool liquidity
Half the raise is deposited at launch, and every escrowed unit that is not refunded is spent buying on the pool, which leaves it there too.
Nearly all of what the circulating tokens cost stays in the pool
The pool charges its 2% fee on the escrow's purchases, so with no refunds the money behind the circulating tokens is about 99% of what they cost, at the launch price. Refunds push it above 100%: a refund removes tokens from circulation without removing anything from the pool.
Neither is a floor under the price or a promise about what the token is worth. Liquidity is not a buyer, a figure at launch is not a figure next month, a pool cannot be emptied at the price it opened at, and the token can trade far below what it sold for. What they do say: 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, not refundable. Plus Solana rent for the accounts a backing opens, a fraction of a cent each.
To raise
Nothing. indie.fun takes no share of the raise.
To trade
2% per trade, inside the pool. Meteora keeps a fifth of that; the rest is split evenly between the developer and indie.fun, 0.8% of the trade each. Each share accrues in the raise's asset to a permanently locked liquidity position and is claimed by the wallet that owns it (the developer's, from their game's Token tab), never out of the liquidity itself.

Trading afterwards

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

What can go wrong

The plain version:

  • The token can be worth less than you paid, immediately and permanently. The refund right covers a share of your contribution for seven days, then it is gone.
  • Miss the window and the refund is gone. It is never extended, for anyone, for any reason.
  • The developer's allocation unlocks eventually. That is 70% of the supply, 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 with a TEST MODE banner runs on Solana devnet, where 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, and how much escrow is funded, refunded and spent on the pool; any explorer will confirm them independently of us. The rules are enforced by the launch program: we cannot extend a window, move escrow, or unlock an allocation early, and neither can the developer. See Tokens for what the SDK exposes to a game's own code.