$PULSE

$PULSE

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

01The stream

Every trade on every coin launched here pays a fee. The creator takes 70%. The protocol takes 30%, and four fifths of that is earmarked for buying $PULSE back and destroying it.

1% trade fee ──┬── 70%  →  creator                0.70% of trade volume
               └── 30%  →  protocol
                            ├── 80%  →  buy $PULSE, burn it   0.24% of volume
                            └── 20%  →  operations           0.06% of volume

Just under a quarter of all fee revenue funds the burn. At the default 1% pool fee that is 0.24% of everything ever traded through the launchpad — not of profit, of volume. There is an 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 today: buybackBps is 10000, so the whole protocol share is transferred to the buyback sink on every collection.

02Where it goes right now

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

That is the whole of it, and it is worth being plain: nothing is being bought and nothing is being burned today. The 24% 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 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 $PULSE 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. The setter 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.

03What switching it on requires

The deployer creates $PULSE, then names it once, then calls setPool(token, pool) 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 one has to be named for each fee stream — 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 $PULSE itself need no pool at all: the sink burns them directly.

04What 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.

05Related

The creator's own share has an equivalent, and that one is shipped: a creator can route their their whole share 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 $PULSE will only partly escape.