Said plainly, because it cannot be fixed.

A hundred addresses can press. We do not claim one address is one person — we claim the price of an address is the same for everybody.

Status

Nothing is deployed. No factory, vault or ledger address exists on any chain, no transaction has been broadcast, and the repository carries no git remote. ./submission/check asserts all three.

05 / The honest part

Sybil pricing, not Sybil resistance.

A hundred addresses can press. We do not claim one address is one person. What we claim is that the price of an address is the same for everybody, and that the price is paid to the people being diluted: each press burns a fee, the token is taxed on transfer, and so the burn itself pays tax into the pot. totalBurned records what landed at the burn address rather than what was charged — where the token taxes that transfer the difference is exactly its tax rate, and recording the charge would overstate the burn every time it does. Charged against landed, drawn.

a sweeper spends fee and receives about 0.6 × pot / N

so pressing stops paying once N > 0.6 × pot / value(fee)

Headcount is therefore capped by what the trading tax can support. That is arithmetic, not an allowlist, and it is why the vault carries no Sybil defence at all.

The equilibrium / where the curve meets the fee

The pot does not grow when more addresses press, so what one sweeper receives falls as 1/N. A press costs the same flat fee at every headcount. Where the two meet is the headcount the period settles at — and the only thing that moves it is the size of the pot, which is the trading tax. Schematic: the pot and the fee are the same ones drawn on the home page; the division is the contract’s, 6000 bps of the pot over the headcount.

07 / Measured, not claimed

Numbers from the last run, not from the pitch.

tests passed, 0 failed, 0 skipped, on an archive endpoint

of them against a live BSC mainnet fork, nothing mocked

guards broken on purpose and watched to fail

108,115

gas for receive() inside a real TaxProcessor.dispatch(), against a 1,000,000 ceiling

Read the audit page, including what is not proven.

07 / The open item

The project share needs approval, and we are not netting it out.

Rule 001 recommends fee = msg.value * 6 / taxRateBps for a factory-created vault — 3% at a 2% tax. This vault credits 30%, ten times that, and 30% is the floor rather than the take. It is not a hardcoded developer address and it is snapshotted per period, but the number is flagged rather than defended quietly.

Nor is it neutral to the rest of the design. The wage is 0.6 × pot / N, so the split directly sets how many participants the same tax revenue can support. Anybody computing the payout from “30% / 8%” gets it wrong the moment one person presses without a referrer, which is why the range is written out above instead.

The project’s share / one period, three ways it can land

Each bar is one period’s pot, and the project’s slice is drawn first so the three can be read against each other — and against the dashed line, which is what rule 001 recommends. The four constants have no setter; what changes between the bars is who was referred and whether anybody pressed.

Somebody pressed, and everybody had a referrer

30 project 60 wage bill 8
Somebody pressed, nobody was referred — the 8% and the remainder fall through to the same address

38 project 60 wage bill
Nobody pressed — there is no headcount to divide by

98 project
Rule 001’s recommendation for a factory-created vault

3 recommended

8each sweeper’s referrer — the third segment of the first bar, and the slice that falls through in the second
2whoever calls settle, paid on the spot — the last segment of all three

The wage bill is the same 60% in the first two bars: what moves between them is the referral slice, not the payroll. The third bar is a period with nobody in it, where the payroll has nobody to pay. And the counterfactual is worth drawing in your head: a smaller project segment would make the wage segment longer, which would push the crossing on the curve above further right — the split is what sets how many addresses the same tax revenue can carry.

On our side this is settled, not pending: the number is submitted as it stands, for Flap to accept or reject.

What was tested

07 / What is not proven

The list nobody puts on a landing page.

The fork suites are not pinned to a block, because no free BSC endpoint we probed serves archive state — every one of them prunes within about 96 seconds. A run is self-consistent but not reproducible across runs, and without an archive endpoint three of the 83 skip instead of running.not reproducible

The contract cannot see whether anybody swept anything. It measures that something pressed a button every period without missing one.unobservable

This is Sybil pricing. A hundred addresses can press, and we do not claim one address is one person.by design

The Guardian owns the beacons, so an upgrade reaches both contracts, including the ledger. That reach is the emergency mechanism and the custody risk at once.disclosed

The project share is submitted for Flap to accept or reject.open item

Anyone can deploy an unregistered ledger and vault pair; only the portal-guarded factory route attaches one to a Flap tax stream.inert helpers

A self-audit is not a substitute for Flap’s review or for an independent third-party audit, and this page does not pretend to be one.

08 / Status

Nothing is deployed.

Said once at the top of this page and again here, because it is the fact everything above depends on. ./submission/check asserts the three parts of it — no address, no broadcast, no remote — rather than taking our word for them.

Nor is deploying entirely ours to do. Registering the factory needs Flap’s VAULT_ADMIN_ROLE, and the project’s 30% is submitted for Flap to accept or reject. What was tested, and what is not proven.