COAL
COAL HAULAGE ROAD LOADED TUB · 20 IN GAUGE · LIGHT FROM THE UPPER LEFT WHAT A CUT BLOCK IS WORTH · 60% OF THE PERIOD, DIVIDED BY THE BLOCKS CUT TUB No. 4
The tub, hauling60% of the period, divided by the blocks cut

Economics

Where a period’s trading tax goes, and what the project actually takes.

The split constants have no setter. What varies is which of them the project address collects on — and that is why its take is a range rather than a single number.

Status

Nothing is deployed. No address exists on any chain.

There is no factory address, no vault address and no mine address, on mainnet or on any testnet. No transaction has been broadcast. What exists is source, a test suite, the measurements on these pages — and a deploy script that has not been run.

01  /  From a trade to the vault
9,000bpsOf the tax reaching the vault — measured
60%Wages, across the blocks cut
30–98%The project’s range, by period
2%To whoever calls settle

2% on each side — the figures we would fix at launch.

No token exists and nothing has traded. These are the values we would write into the launch payload if we launched: a 2% buy tax and a 2% sell tax, mktBps at 10,000 so the entire non-Flap part of the tax would go to the vault, dividendBps at 0 so there would be no dividend leg, and commissionReceiver left at address(0). They are our intent, not a live configuration.

Flap’s own fee is 1,000 bps — measured on chain from a launch the fork suite really executes, and now pinned to that number by an assertion, so the day Flap changes it the suite goes red instead of quietly invalidating every figure below. At 1,000 bps, every 100 units of trading tax would leave 90 for the vault.

Naming any commissionReceiver drops the vault’s share from 9,000 bps to 8,700, and those 300 bps come out of the vault’s own share — the wage bill — not out of Flap’s fee and not out of anyone else’s slice. The mainnet-fork test asserts that as the identity zeroShare − namedShare == namedBps rather than as a comparison.

Launch parameters we would set — not a deployed configuration

Buy tax, intended2% — buyTaxRate 200
Sell tax, intended2% — sellTaxRate 200
mktBps, intended10,000 — all of it to the vault
dividendBps, intended0 — no dividend leg
commissionReceiver, intendedaddress(0)
Flap’s fee, measured1,000 bps
Would reach the vault9,000 bps
If a receiver is named8,700 bps, and 300 bps of wages
Quote assetnative BNB only

The two bps figures are measured on a BSC mainnet fork in Commission.mainnet.t.sol; the rows marked intended are launch parameters nothing has yet been launched with. Source: FACTORY.md

A boundary, stated plainlycommissionReceiver is a launcher parameter

commissionReceiver is a field of the launch payload supplied to Flap’s VaultPortal by whoever launches. It is not a property of this factory, and the factory cannot constrain it: newVault is never given it, and neither is the normalised payload the launch hook validates. There is no hook on the factory side where it could be rejected, so any launcher through this factory can name a receiver, and pay for it out of the wage bill.

Our own launch will pass address(0). That is a promise about the transaction we send, not a constraint the code enforces, and it is stated that way on purpose.

Source: FACTORY.md — Commission

Fig. 07 — from one trade to four payeeswidths are the shares
ONE TAXED TRADE — 2% ON THE BUY AND 2% ON THE SELL100% of the tax · 2.000% of the tradeFLAPTHE VAULT — 9,000 BPSTHE VAULT — 90% of the tax · 1.800% of the tradeFLAP’S FEE, MEASURED — 10% of the tax · 0.200% of the trade8,700 bps if a commissionReceiver is named, and those 300 bps come out of the wage billWAGEPROJECTREFERRALBOUNTYWAGE 54% · 1.080%   PROJECT 27% · 0.540%   REFERRAL 7.2% · 0.144%   BOUNTY 1.8% · 0.036%OF THE TAX · OF THE TRADEEVERY WIDTH IS THE SHARE ITSELF, AND NOTHING HAS TRADED.ONE TAXED TRADE100% of the tax · 2.000% of the tradeTHE VAULTFLAP’S FEE, MEASURED10% of the tax · 0.200% of the tradeTHE VAULT — 9,000 BPS90% of the tax · 1.800% of the trade8,700 bps if a commissionReceiveris named — out of the wage billWAGE — 54% of the tax · 1.080% of the tradePROJECT — 27% of the tax · 0.540% of the tradeREFERRAL — 7.2% of the tax · 0.144% of the tradeBOUNTY — 1.8% of the tax · 0.036% of the tradeEVERY WIDTH IS THE SHARE ITSELF,AND NOTHING HAS TRADED.

Flap’s 1,000 bps is measured on a BSC mainnet fork and pinned by an assertion; the four constants have no setter. The share-of-trade column is a derivation from those two facts and the 2% buy and sell tax we would set at launch — not an observation. No token exists and nothing has traded.

02  /  Inside the vault

Four constants, no setter, and a snapshot taken at funding time.

The vault’s share splits on hardcoded constants: WAGE 6000, PROJECT 3000, REFERRAL 800, BOUNTY 200. There is no function that changes them.

Tax arriving in period N funds period N+1, so nobody can cut a block and then dispatch a backlog of tax into the period they just proved work in. The project address, the referrer and the integer remainder all resolve from a snapshot taken when that period was first funded, so changing the project later cannot redirect a period that is already funded.

The 2% settlement bounty is paid on the spot to whoever calls settle, which is why payday never waits on us: settlement is a permissionless public call.

WAGE6000 bps
PROJECT3000 bps
REFERRAL800 bps
BOUNTY200 bps
Setter for any of themnone exists
Tax arriving in period Nfunds period N+1
Snapshot takenwhen a period is first funded
Settlementpermissionless, pays its caller
A funded period’s bucket
SliceShareGoes to
WAGE60%across the blocks cut in that period
PROJECT30%the project address snapshotted at first funding
REFERRAL8%referrers, carved from the pot, not from a wage
BOUNTY2%whoever calls settle, paid immediately
Integer dust—the funding-time project, never a later period

Constants: WAGE 6000 / PROJECT 3000 / REFERRAL 800 / BOUNTY 200. No setter. Source: FACTORY.md, README.md

Fig. 04 — where a period’s tax goes, repeatedthree states, one set of constants
Blocks cut, every miner referredWAGEPROJECTREFERRALBOUNTYPROJECT TAKES 30%Blocks cut, nobody referredWAGEPROJECT + THE UNREFERRED 8%BOUNTYPROJECT TAKES 38%Nobody cut a blockPROJECT — NO WAGE, NO REFERRAL TO PAYBOUNTYPROJECT TAKES 98%ONE PERIOD’S BUCKET, LEFT TO RIGHT — CONSTANTS WITH NO SETTERBlocks cut, every miner referredWAGEPROJECT60% WAGE · 30% PROJECT · 8% REFERRAL · 2% BOUNTYPROJECT TAKES 30%Blocks cut, nobody referredWAGE60% WAGE · 38% PROJECT · 2% BOUNTYPROJECT TAKES 38%Nobody cut a blockPROJECT — NO WAGE, NO REFERRAL TO PAY98% PROJECT · 2% BOUNTYPROJECT TAKES 98%ONE PERIOD’S BUCKET — CONSTANTS, NO SETTER

WAGE 6000 · PROJECT 3000 · REFERRAL 800 · BOUNTY 200 bps, and no function changes them. What varies is which slices have a payee: an unreferred miner’s 8% and the integer remainder fall to the same project address, and a period nobody cut has neither a wage nor a referral to pay. Rising difficulty makes that last state more common over time, not less.

Fig. 13 — wage per block against blocks cutwageRate = wagePool / cut
WAGE PER BLOCK AGAINST BLOCKS CUT — THE POT IS FIXED BY THE TAX, NOT BY THE HEADCOUNT1510203040whole pothalfa quarter0one block cut all period — 100% of the pot to eachfour — 25% of the pot to eachtwelve — 8.3% of the pot to eachforty — 2.5% of the pot to eachFEWER BLOCKS CUT → MORE PER BLOCK. THE CURVE IS THE DIVISION, NOT A REWARD SCHEDULE.WAGE PER BLOCK — THE POT IS FIXED1102030401½¼01 block: the whole pot · 40 blocks: 2.5% each

The pot is 60% of what the trading tax paid into that period. It does not grow with the number of miners and it does not shrink when they leave — _settle divides it by however many blocks were cut. So the wage per block is a hyperbola, and the steep end is the one rising difficulty walks toward. Nothing is minted at any point on this curve; every unit on the vertical axis is BNB the token’s own trading tax already paid in.