VIRUS

The fee math, from the Pons base fee and the VIRUS creator tax to the 40/24/16 split, parity, rounding and a worked example.

§Who controls what

A virus trade pays two things, both collected by Pons:

The Pons base fee. On the curve this is curveFeeBps; in the graduated pool it is hookFeeBps. Pons keeps protocolFeeShareBps of it and pays the rest to the launch's creator fee recipient.
The creator tax, creatorTaxBps, fixed at launch. Pons pays all of it to the creator fee recipient.

For a virus the creator fee recipient is its VirusFeeder. Everything the feeder receives is the controlled share, and the feeder splits it 50% burn, 30% developer, 20% treasury.

VIRUS sets only one number in this chain: the creator tax. Pons sets the base fee and the protocol share, per launch config and fee policy, and can change them for future launches (BLOCKED_BY_PONS B3, B7).

§The 80bps target

Parasite charges 1% per trade, gives 20% of the fee to Meteora and controls the other 80% (VERIFIED_PARASITE P3, P4). In share-of-volume terms, Parasite controls 80 basis points of every trade.

VIRUS keeps that controlled share as its target: 80bps of volume reaches the feeder (TARGET_CONTROLLED_BPS = 80, VIRUS_ADAPTATION A2). It keeps the same 50/30/20 split of that share. What it cannot keep fixed is the venue's cut, because Pons, not VIRUS, decides it.

§The creator tax

With buybacks disabled, as they are on every virus, Pons pays the creator fee − floor(fee × protocolShare / 10,000) of each swept base fee: in rate terms, baseFeeBps × (1 − protocolShareBps / 10,000). The creator tax tops that up to the target. VIRUS computes the smallest whole-bps tax that does it, on chain, at launch, from live Pons values (VIRUS_ADAPTATION A3):

requiredCreatorTax(baseFeeBps, protocolShareBps)
  = max(0, ceil((80 × 10,000 − baseFeeBps × (10,000 − protocolShareBps)) / 10,000))

In code (VirusEconomics.requiredCreatorTax):

uint256 target = TARGET_CONTROLLED_BPS * BPS;                      // 800,000
uint256 base   = baseFeeBps * (BPS - protocolShareBps);            // creator's scaled share of the base fee
if (base >= target) return 0;
return (target - base + BPS - 1) / BPS;                            // ceiling division

The tax is solved against the curve phase (baseFeeBps = curveFeeBps), because every virus starts on the curve.
Rounding up guarantees the controlled share is at least 80bps. It can be slightly above 80bps when the protocol share does not divide evenly.
The tax is zero when the Pons base fee alone already gives the creator 80bps or more. The controlled share is then above target.
The launch reverts with CreatorTaxUnreachable if the tax exceeds Pons's maxCreatorTaxBps, or if curveFeeBps + tax or hookFeeBps + tax exceeds 2,000bps (the Pons combined-fee ceilings, VERIFIED_PONS F20). When the live values make that true, the app shows "VIRUS FEE TARGET EXCEEDS PONS CREATOR-TAX CAP" and stays in LAB MODE.

The tax you sign is pinned: the coordinator reverts with CreatorTaxMismatch if its live computation differs from the value you were shown.

§Phase fees

For each trading phase, VIRUS describes the fee as three shares of gross volume:

ponsScaled   = baseFeeBps × protocolShareBps
feederScaled = baseFeeBps × (10,000 − protocolShareBps) + creatorTaxBps × 10,000
totalScaled  = (baseFeeBps + creatorTaxBps) × 10,000

These are scaled figures: basis points multiplied by 10,000, so one unit is 1e-4 bps, or one part in 10^8 of volume. 110bps is 1,100,000 scaled. Scaling keeps fractional-bps shares exact; for example, a 33.33% protocol share of a 100bps fee is 333,300 scaled, exactly 33.33bps.

ponsScaled + feederScaled == totalScaled always.

The feeder's share is split in fixed proportions compiled into the feeder implementation:

Share of feeder income	Constant	Of an 80bps controlled share
50% burned from host supply	`BURN_SHARE_BPS = 5000`	40bps of volume
30% booked to the developer	`DEV_SHARE_BPS = 3000`	24bps of volume
20% to the VIRUS treasury	`TREASURY_SHARE_BPS = 2000`	16bps of volume

So at the target, every trade burns host equal to 0.40% of its volume, and books 0.24% to the developer and 0.16% to the treasury, all in host.

§Parity: EXACT or PONS-NATIVE

VIRUS labels each virus's economics against the Parasite reference (VIRUS_ADAPTATION A4):

EXACT: in both phases, the total cost is exactly 100bps, Pons's cut is exactly 20bps, and the feeder's share is exactly 80bps. This reproduces Parasite's 1% fee with a 20% venue cut.
PONS-NATIVE: anything else. The app shows the signed difference from 1.00% in full: deltaScaled = totalScaled − 100 × 10,000, displayed as a percentage, for example +0.10%.

EXACT requires baseFeeBps × protocolShareBps = 20bps and baseFeeBps + creatorTaxBps = 100bps in both the curve and pool phases, with the same creator tax. A 100bps base fee with a 20% protocol share is one such combination (tax 0). Whether any live Pons configuration meets it is decided by Pons, not VIRUS (BLOCKED_BY_PONS B3).

§Worked example

Example only. The inputs below are Pons published-source defaults, not live values: a 100bps base fee (the published default hookFeeBps, also used as the curve base fee in this example) and a 30% protocol share (the published default protocolFeeShareBps). The live site computes the same figures from the live launch config, the live fee policy and, for an existing virus, the fee policy Pons froze at its launch.

§Creator tax

creator share of base fee = 100 × (10,000 − 3,000) = 700,000 scaled = 70bps
shortfall to target       = 800,000 − 700,000     = 100,000 scaled
creatorTaxBps             = ceil(100,000 / 10,000) = 10

§Rates

	Scaled	Percent of volume
Pons (100bps × 30%)	300,000	0.30%
Feeder (70bps + 10bps tax)	800,000	0.80%
of which burned	400,000	0.40%
of which developer	240,000	0.24%
of which treasury	160,000	0.16%
Total cost to the trader	1,100,000	1.10%

Parity is PONS-NATIVE, delta +0.10%. With a 100bps pool hook fee as well, the pool phase shows the same figures.

§One trade of 1,000,000 host tokens

Computed exactly as Pons charges one trade (fee and tax each floored, protocol share floored) and as the feeder splits it (workedExample in packages/chain/src/economics.ts):

Line	Formula	Host tokens
Base fee	floor(1,000,000 × 100 / 10,000)	10,000
Creator tax	floor(1,000,000 × 10 / 10,000)	1,000
Total cost	fee + tax	11,000
Pons protocol share	floor(10,000 × 3,000 / 10,000)	3,000
Feeder receives	10,000 − 3,000 + 1,000	8,000
Burned from host supply	floor(8,000 × 5,000 / 10,000)	4,000
Booked to developer	floor(8,000 × 3,000 / 10,000)	2,400
To VIRUS treasury	8,000 − 4,000 − 2,400	1,600

For comparison, Parasite's own example is a 1,000,000-host-token trade paying a 10,000 fee, 4,000 of which leaves host supply forever (VERIFIED_PARASITE P5). Under these example Pons terms, the burn is the same 4,000; the trader pays 1,000 more, and that difference goes to Pons.

§The 100-cell fee grid

The app draws each trade's fee as 100 cells, one per 1% of the fee, as Parasite does (VERIFIED_PARASITE P6), with values from live data. Cells are shares of the total fee rounded to whole cells by largest remainder, so they always sum to 100. For the example above: Pons 27, burn 36, developer 22, treasury 15.

§Rounding rules

Where	Rule	Direction
Pons base fee per trade	`floor(amount × feeBps / 10,000)`	Down
Pons creator tax per trade	`floor(amount × creatorTaxBps / 10,000)`, separate from the fee	Down
Pons protocol share at sweep	`floor(pending × share / 10,000)`; the creator receives the remainder plus the tax balance	Down for Pons
VIRUS creator tax	Ceiling of the shortfall to 80bps, in whole bps	Up
Feeder split	`burn = floor(gross × 5,000 / 10,000)`, `dev = floor(gross × 3,000 / 10,000)`, `treasury = gross − burn − dev`	Remainder to treasury
Inoculation fee	`ceil(spent × 250 / 10,000)`; zero for a zero first buy	Up
Scaled readouts	bps × 10,000	Exact

burn + dev + treasury == gross for every feed (security invariant 29). Pons takes its protocol share when fees are swept, from the accumulated balance, so per-trade figures like the example above are exact per trade but can differ by rounding dust from what an aggregated sweep produces.

§Curve phase and pool phase can differ

Pons snapshots curveFeeBps on the curve and hookFeeBps in the fee policy separately, and the creator tax is solved against the curve. If the two base fees differ, the pool phase has a different total and a different controlled share:

pool feederScaled = hookFeeBps × (10,000 − protocolShareBps) + creatorTaxBps × 10,000

The app never merges the two. The ECONOMIC SPECIMEN panel shows a curve row and a pool row, each with its own total, Pons cut, burn, developer and treasury shares, parity and delta.

In the pool phase, fees on buys are taken in the virus token and reach the feeder in host only after the Pons fee sweep operator converts them (see Feeding). The host actually delivered then depends on that conversion.

§Frozen per virus

Every figure above is fixed for an existing virus:

curve.feeBps() and curve.creatorTaxBps() are set at launch.
factory.getLaunchFeePolicy(virus) returns the fee policy Pons froze at launch: protocol fee recipient, protocol share, buyback burn share, hook fee and max internal price impact. The per-virus economics display reads this, not the live policy.
The 50/30/20 split is compiled into the feeder, and clones cannot be upgraded.

Pons fee policy changes apply to future launches only. VIRUS's own constants cannot be changed at all.

§The inoculation fee

Separate from trading fees, a virus launched with a first buy pays 2.5% of the host actually spent on that buy to the VIRUS treasury, rounded up. It is charged once, inside inoculate. No first buy, no inoculation fee. See Launching.

§Burns are real burns

The burn half of every feed calls the host's own burn(uint256). The feeder records totalSupply() before and after and reverts with BurnNotReflected(expected, actual) unless supply fell by exactly the burned amount (security invariants 7 and 8). Nothing is sent to a dead address, and nothing can recover burned tokens. VirusRegistry emits HostBurned(host, virus, amount, hostTotalSupplyAfter) for every non-zero burn.

Fees and burns