dust
Dust motes in a shaft of light
DustFractions too small to be worth moving

01  /  What it is named after

Dust is what is left below the threshold.

The ledger reads two integers, and neither of them is a balance.

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.

02  /  The identity

Every behaviour-mining scheme weights by size.

Airdrops readyour historical volume
TVL programmes readyour deposit
Liquidity programmes readyour LP share
This ledger readstwo integers

The moment the rule contains the number of tokens you hold, the holder of more receives more. That is an identity, not a policy — and every later cap, tier or multiplier is a patch on the fact rather than a change to it. Patches move the slope. They never move the direction.

Eight addresses, one period, one wage bill. Their balances, in launched tokens: 10,000,000 · 1,800,000 · 620,000 · 240,000 · 95,000 · 40,000 · 18,000 · 12,000. Both charts divide the same wage bill and are drawn to one scale.

A size-weighted rule

share ∝ balance held

  1. 177.97%
  2. 214.04%
  3. 34.83%
  4. 41.87%
  5. 50.74%
  6. 60.31%
  7. 70.14%
  8. 80.09%

One address takes 77.97%. The smallest of the eight takes 0.09% — a ratio of 833 to 1, which is exactly the ratio of the balances.

This rule

share = wage bill ÷ headcount

  1. 112.50%
  2. 212.50%
  3. 312.50%
  4. 412.50%
  5. 512.50%
  6. 612.50%
  7. 712.50%
  8. 812.50%

Every address takes 12.50%. The ratio between the largest and the smallest holder is 1 to 1, because no balance entered the expression.

The left chart is the identity, drawn: no cap, tier or multiplier moves the direction of it, only the slope. The right chart is WAGE_BPS 6000 divided by epochSweeps[e], and it is flat for the same reason it is flat at any other headcount.

01  /  What the ledger reads

Presence, and how many others were present.

Did this address press this periodone bit
How many addresses pressed this periodone counter
What this address holdsnever read

One press per address per period. Weight is one, for everybody, and the wage is the period’s wage bill divided by the count. There is no tier to reach and no multiplier to unlock, because there is no input for size to enter through.

Balance blindness  /  twelve wallets, one period, one number out

The twelve addresses that pressed in period 4118. Left: what each of them holds, on an axis three decades tall — the largest holds 761× the smallest, and four of the twelve hold exactly one entry fee. Right: what each is owed. Schematic: the balances are a worked example, the wage is 6000 bps of that period’s pot divided by twelve, exactly as settleEpoch divides it.

Twelve wallets pressed in one period. Their balances span from twelve thousand tokens to nine million, drawn on a logarithmic axis three decades tall, and every line runs to the same single point: a wage of 0.037060 BNB, identical for all twelve. 9,140,220 DUST 12,000 DUST — one entry fee

Wage

0.037060

BNB, to each
of the twelve

Twelve wallets go in at nine distinct heights — four of them hold exactly one entry fee and share a line — and one line comes out. Nothing collapses them on the way: wageRate = wagePool / epochSweeps[e] has no term the left-hand axis could enter through, so the spread is not compressed, capped or tiered — it is never read. The one balance the ledger does read is the burn address’s, to record what a fee actually landed.

A test asserts this against the source file rather than against behaviour: every call to the token’s balance function in DustLedger.sol must be against the burn address, and balanceOf(msg.sender) must appear zero times. The break used to prove that test works was a single require that reads the caller’s balance to produce a friendlier error. It went red.