The unit

One token held for one second is one token-second. That is the only unit in this codebase, and the only thing the money is ever divided by.

banked(wallet) = Σ balance × Δt   over every stretch it held

1 token   × 1 second  = 1
1,000,000 × 1 hour    = 3,600,000,000

Between two balance changes a balance is constant, so the seconds earned over that stretch are exactly balance × Δt — a multiplication of two integers. There is no approximation anywhere in the accrual and no float anywhere in the path.

Nothing decays and nothing expires. Selling never reaches backwards: seconds already earned were earned, and selling only stops you earning more.

Why there is no clock

Every other design in this category starts by choosing a moment. A snapshot picks one. A window picks two. An epoch picks a repeating one. And the instant a design has a moment in it, that moment is worth planning around — which is why the optimal play against a snapshot is always buy just before and sell just after.

This one has no moment. Buying a second earlier earns exactly one more second; selling a second later earns exactly one more second. There is nothing to stand on because there is no edge.

What decides when money moves is not a schedule but the money: an arrival is settled when a creator-fee claim actually lands in the treasury. The gaps between arrivals are uneven, and the site does not pretend otherwise.

The consequence, stated

Someone who holds for forty seconds earns forty seconds' worth. That is not a hole in it — it is the mechanism being proportional instead of gated. What stops it being farmed is arithmetic: a round trip costs 1% in and 1% out, and a few seconds of accrual does not come close to covering that.

And your share of an arrival is your share of the holding that arrival's money covers. Two wallets that held the same amount since the last arrival take the same share of the next one. Holding since launch does not inflate a single payout — it means you were paid at every arrival there has ever been, which is a much larger number.

The split

An arrival is divided strictly in proportion to banked seconds. No tiers, no multipliers, no bonus for a streak, no second term.

your share = your banked seconds ÷ every banked second

Linearity is the whole anti-splitting argument: two wallets each holding half a bag bank exactly what one wallet holding the whole thing banks. So splitting across addresses gains nothing, there is no reason to go looking for people who have, and nobody honest gets caught by a clustering heuristic that guessed wrong. Square-root weighting sounds fairer and is farmed by precisely that split.

Integer division leaves a remainder, and it is handed out by largest remainder with a deterministic tiebreak on the address — so two people running the settlement produce byte-identical files.

A payment that lands under the cost of sending it is not kept and not lost. It stays as credit on the wallet, is named in the ledger, and goes out the moment the wallet's total crosses the floor. A holder small enough to fall under it every single time still accumulates rather than being quietly dropped forever.

Burning what was paid for

When an arrival settles, every second it divided by is consumed. That is the property which makes "there are no epochs" safe rather than sloppy: no second can ever be paid for twice.

The past is not estimated. On boot, the book is rebuilt in one pass over the transfer events and every settled arrival in order — carried forward to each arrival's moment, burned there, credited with whatever that arrival paid or left owing, and then the events resume. The number on the page and the number in the published ledger are the same number, computed the same way.

Where the pot comes from

Pons charges 1% on the pool and splits it 70/30 with the creator. The creator's side is claimed in ETH to one address, and the pot is whatever has actually arrived there since the last settled arrival.

Every claim counted is a transaction that was looked up and checked to land at the configured treasury. A claim that lands anywhere else is not counted. Money leaving is never counted — only money arriving. Netting off a withdrawal would let a spender quietly shrink what the holders are owed.

It is not money from new buyers. There is nothing to stake, nothing to lock, nothing to bond, and no contract holding anyone's tokens. If volume is zero the pot is zero; it is not a yield.

What the reader sees

Balances are rebuilt from Transfer logs, which are deltas rather than balances. Miss one and the number is wrong permanently, and nothing inside the reconstruction would notice.

So every wallet is checked against a live balanceOf before anyone is paid. A wallet that disagrees is held back — named in the ledger, paid nothing — rather than paid on a number nobody can defend.

A second does not care why a balance moved, which turns out to matter a lot: no swap decoding, no venue-specific event shape, nothing to break when a venue changes its ABI. It only needs to know when a balance changed, which is the one thing a transfer log actually says.

The native-claim blind spot

An ERC-20 transfer always emits a log, so a fee arriving that way is read exactly. A native transfer made inside a contract call emits no log and is invisible without a trace API. When the fee arrives that way the pot is reported as a floor rather than a total, and the page says so, rather than printing a number it cannot stand behind.

Arithmetic

Integers throughout. Token-seconds are token wei multiplied by whole seconds, so they get very large — a million tokens held for an hour is 3.6×10²⁷ before display — and BigInt carries them exactly. The shortened forms on the page (520.97B) are display only and are never fed back into anything.

The invariant, asserted before any settlement is returned:

pot + creditIn  ===  paid + creditOut

Money that arrives is either sent or still owed. There is no third place for it to be, and no rounding step anywhere that could invent or lose a wei. It is checked across four hundred randomly generated arrivals in the tests, and an arrival that does not balance does not publish.

The ledger goes up before the money moves; the payment transactions go up after. The two can be held against each other by anyone who kept a copy.

The API

Read-only, GET only. A POST gets a 405 and nothing else. Nothing is written to disk and no request can choose what the server fetches.

Running it

npm run dev              # the engine over invented history, on :8100
npm test                 # 48 engine checks + 31 server checks
npm start                # the deployment; see the settings below
npm run settle a013      # write an arrival's ledger and payment file

There is no interval to configure, because there is no interval. The only clock this has is the chain's, and the only thing that settles anything is money turning up.

What it can't do

There is no custody here. No keys, no signing, no connect-wallet button, no account, and no record of who looked up what. No route in the codebase can spend anything, and test-http.mjs greps the source for private keys, seed phrases and signing calls and fails the build if it finds one. It also checks that neither page loads a font or a script from anyone else.

Payments are sent by a person, from their own wallet, using a file settle-arrival.js writes. Every custody failure in this category began with something that held funds briefly on somebody's behalf.

Two more, plainly. The pool and treasury addresses are configured, not detected — get them wrong and they appear in the standing as enormous banks. And money that arrives while nobody holds anything has nobody to pay, so it is carried forward rather than vanishing.

Rewards depend on fees earned. Nothing here is financial advice.