Maelstrom
Launch coin

$MAELSTROM

The protocol's own token, and the fee stream set aside to buy it back.

Status: the token does not exist, and neither does the contract that would buy it. The stream is built into the launchpad and will flow from the first collect. What happens to it after that is, for now, a wallet. Everything below separates what the code does from what is only intended, because the difference matters.

The stream

Every trade on every coin launched here pays a pool fee. Cetus keeps a fifth of it; of what the launch's position earns, the creator takes 80% and the protocol 20%. Of the protocol's part, Launchpad.buyback_bps goes to the buyback sink and the rest to the treasury — and buyback_bps starts at 10,000, so all of it goes to the sink.

1% pool fee ──┬── 0.20%  →  Cetus
              └── 0.80%  →  the launch's position ──┬── 0.64%  →  creator
                                                   └── 0.16%  →  buyback sink

At the 1% tier that is 0.16% of everything traded through the launchpad; at the 2% tier, 0.32%. Not of profit — of volume. The protocol's share of each dev buy's fee (0.2% of the seed at the 1% tier) goes the same way. The treasury's income is the launch fee, and nothing from trading.

This part is not a promise about a future contract. It is how collect_as_a and collect_as_b split every collect, and how the tests check it: with buyback_bps at 10,000, the treasury receives nothing from fees.

Where it goes right now

To an ordinary address — whatever buyback_sink was set to when the launchpad was deployed, a wallet the deployer controls. Anyone can read it off the Launchpad object.

It is worth being plain about what that means: nothing is bought and nothing is burned. Fees arrive at the sink in whatever coins they were paid in — every pair asset, and every launched coin — and sit there. The sink is a parameter the owner can change with set_buyback_sink, so today the stream is earmarked by intention, not by code.

What switching it on would take

A Sui object can own coins sent to its own ID and pull them in later with transfer::receive. So the sink can become a shared buyback object without changing the launchpad at all: deploy it, then point set_buyback_sink at its ID. Coins already sitting in the interim wallet would be sent over once.

What that object has to get right, and why it is not written yet:

  • The token. $MAELSTROM would come from the same coin template as everything launched here, which gives it a burn-only supply: bought tokens can be destroyed through its Currency, shrinking the real supply, rather than parked at an address.
  • Selling a basket. Fees arrive in dozens of coin types. Stablecoins, SUI and the majors can be routed into $MAELSTROM through the Cetus aggregator. Fees paid in launched coins are the hard part: the only market for each is its own pool, so selling the protocol's share of a creator's coin is selling into that creator's chart. Whether to sell those, hold them, or burn them outright is an open decision, and a buyback that got it wrong would work against the creators it is meant to sit alongside.
  • The way out. Until the token exists, the owner has to be able to move what has accumulated, or the stream is locked in a contract that cannot yet act. Once the token is named, that exit should close for good, in code rather than by promise.

What this is not

It is not a claim on protocol revenue, not a governance right, and not a security. Before a buyback contract exists, the routing is a setting the owner can change. The intended design is that once the token and its buyback are in place, the parts that matter can no longer be undone — and until then, this page should be read as describing an intention, with the stream itself as the only part in code.

Related

The creator's own share has an equivalent, and that one is built: a creator can route their 80% into buying their own coin back and burning it, per launch, changeable at any time. See Fees. It is the same idea one level down, and it is simple there because a single coin has one pair asset and one pool to buy in — which is exactly the constraint $MAELSTROM does not have.