Fees

One pool fee, three shares, and yours is the largest of them.

The split

Every trade pays the pool fee of the tier you launched at — 1% at tick spacing 200, 2% at 220 — and Cetus takes its cut before any liquidity provider sees the rest. Cetus's GlobalConfig sets protocol_fee_rate to 2,000 of 10,000, so 20% of every fee never reaches a position. Your launch's position earns the other 80%, and that is what Maelstrom splits:

It is easy to read "80% to the creator" and multiply it by 1%. That gives 0.80%, and it is wrong by exactly Cetus's share. The figure to hold on to is 0.64% of volume at the 1% tier.

The Cetus row is Cetus's to change: its administrators can move the protocol fee rate (up to 3,000 of 10,000) and an individual pool's fee rate, which would move every percentage above except the first column. The first column is the launchpad's, and for an existing launch it does not move.

Fees accrue on both sides of the pair. A buy pays its fee in the pair asset, a sell pays it in your coin — so a coin that trades in both directions earns you both.

Where the protocol's 20% goes

Launchpad.buyback_bps of it goes to the buyback sink, the rest to the treasury. buyback_bps is 10,000 today, so all of it goes to the sink — the stream set aside for $MAELSTROM — and the treasury receives none. The treasury's income is the launch fee: 2 SUI per launch.

Your share cannot be cut after the fact

Launch.creator_fee_bps is copied onto your launch from the launchpad at the moment it happens. The owner's set_creator_fee_bps changes the figure for future launches only; collect_as_a and collect_as_b read the launch's own copy, never the global one. A creator commits to a launch on the strength of a number, and a protocol that could revise that number later would not really have given them anything. You can read any launch's figure off its object, or with launchpad::launch_creator_fee_bps.

The protocol's own buyback_bps is not snapshotted, because it only divides the protocol's money.

The honest limit of this guarantee: it is a property of the launchpad's code as published, and the launchpad package can be upgraded. An upgrade cannot touch your liquidity, but it could change how fees are split. Who holds that power, and why the package has to stay upgradeable at all, is in Contracts.

The dev buy's fee

A computed first trade pays no pool fee, so the launch charges the part the protocol would have received explicitly: take_dev_buy_fee takes seed × fee rate × (1 − creator share) from the seed before it moves the price — 0.2% of the seed at the 1% tier — and splits it between the buyback sink and the treasury like any other protocol fee. Your own share of that fee is not taken, because it would only have been paid back to you. Cetus receives nothing on the computed trade.

What you can do with your share

Two settings on your Launch, both creator-only, both effective from the next collect — so you can change either one later, without relaunching.

Where it goes

set_fee_recipient(pad, launch, recipient) sends your share somewhere other than the wallet you launched from — a multisig, a treasury, a splitter. 0x0 resets it to you. It moves only your share.

Or: buy back and burn

set_fee_route(pad, launch, 1) stops paying you and destroys your share instead:

• The part in your coin is burned directly. Coins launched here have a burn-only supply, so Currency::burn_balance really shrinks the coin's total supply; Launch.burned counts every coin destroyed this way.
• The part in the pair asset buys your coin in its own pool — a flash swap against your launch's pool — and burns what it buys, so the buyback walks the price up through the same range your launch seeded.

The buy sets no price limit beyond the pool's own extremes. The input is a small amount of fees and the output is destroyed, so the worst a trader can do by moving the pool around it is make it burn fewer coins than it otherwise would; no principal is exposed.

An amount too small to buy even one base unit of your coin is not wasted and does not abort the sweep: it waits in Launch.pending_buyback and joins the next collect's buy.

Either route also burns the launch's dust — the few coins the first deposit's rounding left behind — at the first collect.

Each such collect also emits BoughtBackAndBurned, with what was spent, bought and destroyed.

set_fee_route(pad, launch, 0) switches back to being paid, and anything still waiting in pending_buyback goes out with the next payout rather than sitting in the launch forever.

Collecting

collect_as_a and collect_as_b are permissionless. Anyone can call them for any launch — a bot, a buyer, you — and it does not matter who does, because the proceeds can only reach the recorded fee recipient, the buyback sink and the treasury, or the burn. There is no path by which the caller pays themselves. A collect with nothing earned is a no-op, not an abort.

Nothing on chain calls them on a schedule, so the project runs a keeper (keeper/ in the repository) that sweeps every launch owed more than a dollar, in batches. If it stops, fees keep accruing in the pool and the next collect, from anyone, sweeps all of it.

There is no "owed" balance and no claim step. A transfer on Sui is a new object in the recipient's name; there is no receiving contract that can refuse it. The one exception worth knowing is a regulated pair asset — USDC on Sui is one — whose issuer can deny an address: from the next epoch a denied address cannot receive that coin, and a collect paying it aborts. Nothing is lost — the fees stay in the position — and the creator can point set_fee_recipient elsewhere.