$Bee4Bee

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, and the contract that will spend it is deployed. 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 70%. The protocol takes 30%, and four fifths of that is earmarked for buying $Bee4Bee back and destroying it.

1% trade fee ──┬── 70%  →  creator                0.70% of trade volume
               └── 30%  →  protocol
                            ├── 80%  →  buy $Bee4Bee, 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.

Where it goes right now

To the deployer wallet, where it accumulates untouched until $Bee4Bee 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 — VortexBuyback — 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 $Bee4Bee 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. setVortex 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 $Bee4Bee, then calls setVortex(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 Pancake Infinity 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 $Bee4Bee 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 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 $Bee4Bee will only partly escape.