$PAIR

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

Status: the token does not exist yet. The stream is designed and the contract that will spend it is written and tested. What is missing is the token itself, and the deployment. Everything below separates what the code does from what is live, 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 $PAIR back and destroying it.

1% trade fee ──┬── 80%  →  creator
               └── 20%  →  buy $PAIR, 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 FeeVault splits every collect: buybackBps is 10000, so the whole protocol share is transferred to the buyback sink on every collection.

Where it goes at first

To the deployer wallet, where it accumulates untouched until $PAIR exists.

That is the whole of it, and it is worth being plain: nothing is bought and nothing is burned until the token ships. 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 $PAIR goes to 0x…dEaD, in code, with no argument and no setter — taken from the pool straight to the burn address, never touching the contract's own balance.

The token can be named once. setPairToken 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 deployer creates $PAIR, then calls setPairToken(address) once, then setPool(token, key) for each currency the fees should be sold through. That is all. No redeployment, no migration, and no change to any existing launch.

The honest limit. A swap needs a pool, and in Uniswap v4 a pool has to be named — there is no factory to ask. 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 $PAIR 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 has always worked because a single coin has a single pair asset and one pool to buy in — which is exactly the constraint $PAIR will only partly escape.