$STAIN

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

Status: the token does not exist yet. The stream is live and accruing from the first launch, and the contract that will spend it is written and tested. What is missing is the token itself. Everything below separates what is running from what is not, because the difference matters.

The stream

Every trade on every coin launched here pays a fee. The creator takes 80%. The protocol takes 20%, and all of it is earmarked for buying $STAIN back and destroying it.

1% trade fee ──┬── 80%  →  creator
               └── 20%  →  buy $STAIN, burn it     0.20% of trade volume

A fifth of all fee revenue funds the burn. At the default 1% pool fee that is 0.20% of everything ever traded through the launchpad — not of profit, of volume. There is no operations cut taking a slice first; the protocol keeps nothing for itself.

This is not a promise about a future contract. It is how the deployed FeeVault splits every collect: buybackBps is 10000, so the whole protocol share is transferred to the buyback sink on every collection.

Where it goes right now

To the treasury wallet, where it accumulates untouched until $STAIN exists.

That is the whole of it, and it is worth being plain: nothing is being bought and nothing is being burned today. The 20% is separated on every collection and sent to a wallet. Anyone can check by reading buybackSink() on the vault.

The contract that will spend it — PairBuyback — is written and tested but not deployed. Standing it up before the token exists would move the money somewhere less convenient without making any claim on this page truer, so it waits. What it will bring, when it is deployed alongside the token, is that three things stop being promises:

The destination will not be a parameter. Bought $STAIN goes to 0x…dEaD, in code, with no argument and no setter — sent by the pool straight to the burn address, never touching the contract's own balance.

The token can be named once. setPair reverts if it has already been called.

The way out closes when the token arrives. Until then the owner can withdraw, because fees accrue before the token ships and locking them inside a contract that cannot yet act would be its own kind of loss. The moment the token is named, that function reverts forever.

What switching it on requires

The token is created, then setPair(address) is called once, then setPool(token, pool) for each currency the fees should be sold through — a Uniswap V3 pool holding that currency and $STAIN, which the contract checks. Then the vault's buybackSink is pointed at PairBuyback. No redeployment, no migration, and no change to any existing launch.

The honest limit. A swap needs a pool. So the burn is automatic for any currency with a configured pool, and impossible for one without. In practice fees concentrate in a handful of pair assets, and those are the ones that will be configured. Fees denominated in $STAIN itself need no pool at all: the sink burns them directly.

What this is not

It is not a claim on protocol revenue, not a governance right, and not a security. Before the token is named, the routing remains a decision the owner can unmake. After it is named, the parts that matter cannot be unmade — that asymmetry is the whole design.

Related

The creator's own share has an equivalent, and that one is shipped: 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 works from day one because a single coin has a single pair asset and one pool to buy in.