How an hour is divided

Why no rate is shown in advance

The obvious design is to publish a rate, "you will receive this much for this hour", and let people decide whether it is worth their time. That design was tried and abandoned, because it cannot be made honest.

To promise a rate before an hour ends, the system has to guess how many people will take part. If it guesses low, it promises more than the hour contains and either overspends or breaks its promise. If it guesses high, it promises too little and quietly keeps the difference. Either way the number shown to a user is a forecast presented as a fact.

It gets worse under load. A system that limits how many sessions it opens only ever observes the demand it admitted, never the demand it turned away. Once it is busy, its own measurements tell it that everything is fine. It cannot correct itself, because it has blinded itself to the thing it needs to measure.

So the rate was removed. There is nothing to forecast, nothing to reserve, and no queue for capacity. Everyone who watches an advertisement gets a session. The division happens afterwards, when the actual number of participants is a known fact rather than a prediction.

The rule

When an hour closes, the server adds that hour's allocation to anything carried over from before, and divides the total by the combined weight of everyone who took part:

Because everything is done in whole points with no rounding up, the amounts distributed can never exceed the pool. Whatever is left, a rounding remainder or the entire pool in an hour when nobody took part, is carried into the next hour rather than lost or reissued.

A worked example

These are real figures produced by the same code that performs settlement, for the first hour of the schedule with ten thousand participants: 9,997 at base weight, and one person each at 1.10, 1.20 and 1.25 from referrals.

Hour allocation

78,579.539798717

Carried in

0

Pool

78,579.539798717

Participants

10,000

The remainder carried forward is 1,719 points, the rounding dust from ten thousand divisions. It is not written off. It joins the next hour's pool, so over time every point reaches someone.

In the app's own counting, the base share of 7.857521816 units in this example is 7,857,521,816 points. The example is the design's first hour with ten thousand participants; it is not a statement about any hour the server has settled, and it is not a prediction of what anyone will receive.

What follows from this

The per-session cap

However quiet an hour is, one session can never receive more than that period's per-session ceiling. In the first period the ceiling is 20 units, and it declines on its own schedule as the years pass. The schedule is in the white paper.

The cap exists so that a very quiet hour cannot hand one person an enormous share, and so that no strategy involving timing, automation or several devices can extract more than the design intends. When the cap binds, the undistributed remainder carries forward exactly as any other remainder does.

Referral weight

Weight starts at 1.00 and increases by 0.05 for each qualified referral, up to a maximum of 1.25 at five referrals. That is the entire range. There is no tier above it, and no way to buy one.

Weight is fixed at the moment your session opens and cannot change afterwards. A referral later found to be fraudulent does not alter an hour that has already settled; it affects the weight of future sessions.

When you find out

Your amount is revealed about one hour after your session started, once the hour it belongs to has closed and settled. Until then the app says, in its own words: No amount exists yet. It is revealed when the hour settles, not while it runs.

It does not show zero, and it does not show an estimate dressed up as a balance. An amount that has not been decided is not a number yet, and saying otherwise would be a small lie that compounds.

What the app then shows is a number of Senkai points. They are in-app points only, with no cash value; the app says so under the balance.