What makes a token multiply

A launch opens with no liquidity in it and still quotes a real price from the first block. It trades against a constant product, x · y = k, the same arithmetic an automated market maker runs, with one difference that makes the whole thing possible: the quote side of the pair opens at a virtual reserve. Counted in the price, never deposited by anyone.

Q is the quote reserve and T the token reserve. Quote goes in, tokens come out, and the ratio between them moves against the buyer every time: the price is a function of how much has been bought and nothing else. No order book, no counterparty, no listing. Fees come off Δq before the curve prices anything, which is why the curve never sees them.

Under the launch config in use today a token mints 1,000,000,000 units against a virtual reserve of 1.68 ETH, and the curve closes once it has taken 4.2 ETH of real quote. Those three numbers fix everything else, including the part of the supply that never touches the curve.

That slice is held back to seed the Uniswap pool, and it is not an arbitrary number. Run the constant product forward to the moment the threshold is hit and the tokens still sitting on the curve come to exactly the reserved amount: the curve is built to run out at the same instant it fills. The other 71.43% is what it sells on the way. Then buys close, the reserves and the reserved tokens become a Uniswap v4 pool, and the token trades there from then on.

Pons charges two things on a trade: a base fee, split between the protocol, an optional buyback and the creator; and a creator tax, which goes to the creator entire. Both are taken on the quote leg, at the same rate whether the token is still on its bonding curve or has graduated into its Uniswap v4 pool.

Every launch here sets that creator tax to 4% and names a single treasury as the recipient. Neither is offered as a choice, because a rate a creator can lower is a rate a creator will lower, and everything below is downstream of the fee actually arriving.1

A fee does not arrive anywhere by itself. Before graduation it accrues on the launch’s own curve; afterwards on the Pons hook. In both cases it sits there until a sweep moves it into the protocol’s fee escrow, and the escrow holds it until it is claimed. The keeper does both on a schedule.

That creates one accounting problem worth naming. The escrow keeps a single balance per recipient, covering every launch the treasury has ever created, so the claim itself cannot say which token earned what. Attribution is taken from the sweeps instead: the escrow balance is read on both sides of each sweep, and the difference is what that launch actually credited.

What is left, per token, is a budget: everything ever credited to it, less everything ever deployed out of it. That is the only thing the engine may spend.

A budget spent the instant it arrives buys in dribs and pays gas on every one. A budget spent on a fixed timer ignores everything the market says between ticks. The engine is the compromise: one score from four readings, threshold at one.

The weights sum to one, which is what makes the threshold meaningful: a single term reaching 1.0 is by itself sufficient, and several partial reasons add to the same verdict. Each term is normalised so 1.0 means “this reason alone justifies an execution”, and capped at 2.0 so no extreme reading can swamp the rest.

T is the clock: time since the last execution against the mode’s cadence τ. It guarantees a token nobody is trading still gets its burns.

B is the budget measured against the curve it would be spent into. R is the quote reserve and κ the impact cap, so R·κ is the largest execution the mode permits. Reading it this way rather than against a fixed sum in ETH is what lets one mode behave identically on a launch with two ETH of reserve and one with two hundred.

D is the dip: how far the price sits below the size-weighted mean of recent trades. Weighting by size is deliberate, because a dip printed by a handful of dust trades is not a dip.

V is the tape: a day’s volume against the token’s own seven-day baseline. High volume is not a reason to buy on its own; it is a signal the budget is about to refill, which is a reason to deploy what is already standing.

Two gates sit outside the score and cannot be traded against it. A budget below the mode’s floor is held, because an execution costing more in gas than it destroys is a loss dressed as a burn. And a cooldown must have elapsed, however high the pressure reads.

A launch chooses one setting, and that choice is the only parameter it controls. Read the table by its two ends: at ×1 the engine is very nearly a clock, at ×8 very nearly a reflex.

The spend column reads backwards at first glance: the most aggressive mode deploys the smallest share of its budget. That is the point. ×8 fires many times a day and would exhaust a budget in an afternoon at ×1’s sizing; the four are close in what they deploy over a week and far apart in how they space it. Aggression here is a statement about timing, not about generosity.

When the engine fires it deploys the mode’s share of the standing budget, enlarged by the dip, then clipped twice.

The second clip is the one that matters. A buyback large enough to move the price is buying at a premium it created, and the tokens it destroys cost more per unit than a patient execution would have paid. The cap bounds that by construction, and when it binds the remainder stays in the budget rather than being forced through.

The buy routes to the curve, with a minimum-out sized from the quoted rate rather than the total. A buy that would cross the reserved allocation fills to the edge and refunds the rest, and bounding the total instead would make the last buy of a launch revert rather than partially fill.

What arrives is sent to 0x…dEaD. The launch token is a plain ERC-20 with no burn function and a transfer to the zero address reverts, so the dead address is the mechanism the market already reads as destruction. The buyback is recorded before the transfer is sent: a burn that fails leaves an auditable row with tokens bought and none burned, and the next pass sweeps up whatever the treasury still holds rather than stranding it.

The 4% fee and its recipient are fixed on chain at launch, by Pons, and cannot be changed afterwards by us or by the creator. Those hold without trusting anyone.

The engine does not. Modes, weights, cadence and the burn itself are executed by a keeper holding the treasury key; Pons has no idea any of this exists. That makes the schedule a commitment rather than a guarantee, and the honest statement is that the fee is trustlessly unavailable to the creator while its destination is enforced by us. Every execution is on chain and every input to the decision is published on the token’s page, so the commitment is at least checkable.

Buybacks currently route to the bonding curve. A launch that has graduated into its Uniswap v4 pool keeps accruing and claiming fees and its budget keeps growing, but the engine holds rather than executing until pool routing is written.2

1. Pons does expose transferCreatorFeeRecipient, callable only by the current recipient, which is the treasury and not the creator. The creator has no path to it at any point.
2. Pons v2 is unaudited. Three audits were in progress at the time of writing and none had closed. Nothing here changes that.