Every Points Calculator Has an Expiry Date and Nobody Gets an Alert When It Passes. One Check, Run Against Our Own.

A points program is a promise with a fraction in it. Your points over the points that count, times some pool. We wrote about the denominator of that fraction three weeks ago: who is inside it, whether you can read it without connecting a wallet, and whether the people running the program are in it themselves. That is the check most programs fail.

This post is about the failure that comes next, and we did not go looking for it. A program can publish its denominator on every surface it owns, keep it live, compute it from a public endpoint, and still have nothing anywhere that answers the only question a prospective participant actually has: what does my position get. The denominator is an input. Something has to divide by it.

The thing that divides by it has to know which earning window is running. There are two ways to tell it. One is to hand it a date. The other is to hand it the published list of windows and let it ask which one is open. These look identical for the entire life of the first window, and they diverge silently at the first snapshot, because a date does not know that it has passed.

The check

Open the program's calculator, projection tool, or "what will I earn" panel on a day after one of its published snapshots, and read what it says. Not the server HTML, which for most of these is a loading state. The rendered page, after the scripts have run.

You are looking for one of three answers. It quotes a figure against the window that is currently earning, which is correct. It says plainly that nothing is open, which is correct if nothing is. Or it talks about a window that has already closed, in the past tense, as though that were the whole program. The third is the failure, and it is worth knowing about because of how it fails: the page still loads, the layout is intact, no request errors, no monitoring fires. It is a live surface confidently answering a question nobody asked.

The reason to run this on someone else's program is that it is cheap and it tells you something about how the program is maintained. The reason to run it on your own is that nothing else will.

What it found here

Our capture calculator sits on the token disclosure page. It reads the same public leaderboard endpoint anyone else can read, computes the eligible denominator from it, and shows what a given deposit would take by the snapshot, along with a table of how fast that share decays when other people deposit. The post we published on August 11 ends by pointing readers at it.

Between the Genesis Extended snapshot at 2026-08-19T19:59:17.805Z and this read, it rendered no figure at all. In place of the deposit projection it rendered three sentences, and they are worth quoting in full rather than in part, because the third one is the interesting one:

The August 19, 2026 at 19:59 UTC snapshot has passed, so a deposit made now earns nothing toward it. The standings below are what the window counted. Fragments earned from here count toward Opal Window 3, which runs to September 28, 2026 at 19:59 UTC on its own ladder.

Every sentence there is true. The panel even names the window that was open and the date it closes. What it does not do, anywhere, is divide by the denominator: no projection, no share, no token count, no decay table, for a window it had just correctly identified as running. It knew which window was open and it still answered nothing, because the arithmetic underneath was keyed to a different instant than the prose was.

That is the part worth taking away, and it is why "does the page mention the current window" is not the check. Opal Window 3 opened at the Genesis Extended instant, by construction, so that there would be no gap. It runs forty days on a fresh cohort ladder, which opened at 2.0x and stepped down to 1.75x on August 26. For eleven days and twenty hours, on a window that was open and accruing every hour, the one surface built to tell a prospective depositor what a deposit earns showed them no arithmetic at all.

Two other surfaces were pinned the same way and are repaired in the same change as this post: the search description on our Opal page, and the share card on the rewards page, both of which went on naming the August 19 snapshot as the one to lock a share at. Neither is a calculator, so neither showed a wrong number; they advertised a dead deadline instead. That is three surfaces, and the honest reading is that this is a class rather than an incident.

What did keep working is the half that never took a date as an input. The leaderboard was live, the countdown on the Opal page was counting down to the right instant, the mint page was naming the right window and the right multiplier, and the eligible denominator itself was published and current in four places. One of those four, the strip on the rewards board, was rendered only in the browser, so it existed for a reader running scripts and not for a crawler, an answer engine or an agent reading the page on someone's behalf; that is also fixed in this change. Every surface that held up asks which window is open. Every surface that did not was handed a date.

Why a date does this, and why it is not a typo

The pinned constant was not careless. It was there for a specific and correct reason: an earlier version of the same panel resolved the window it named from the clock while resolving the gate that decided open-or-closed from a constant, and the two disagreed at the boundary. The fix at the time was to make both come from the same place, and the place chosen was the constant. That produced a panel whose two halves agree with each other perfectly and agree with the calendar for exactly as long as one window lasts.

The general shape is worth naming because it is not specific to points programs. A surface keyed to a constant is correct until the constant's own date, and it degrades into confident past tense rather than into an error. Anything that would have caught it has to be something that knows the date has meaning: a test that runs with a clock set past the snapshot, or a person opening the page. Type checking will not. A build will not. Uptime monitoring will not, because the page is up.

The version that survives asks the published sequence which window is open, and treats "closed" as meaning the last window in that sequence has passed with no successor behind it. Appending a window then requires no edit to the surface at all. That is the property worth having, and it is the property to ask about when you find one of these on someone else's site: not "is this number right today" but "what makes it right in six weeks".

The arithmetic that was not being shown

Read from the public endpoint at 2026-08-31T16:00:04.677Z, which is the ledger's own last accrual time and not the time of our request. Four wallets, which is the whole board.

At that read there were 675 whole hours to the Opal Window 3 snapshot and the live cohort rung was 1.75x. Fragments accrue at 100 per kUSD per hour, so a position held from then to the snapshot projects as follows. Your own projection joins the denominator, because a new depositor is part of the eligible set.

Read that table for its shape rather than its headline. The interesting figure is not that a hundred dollars takes eighty percent of the community tranche. It is that ten thousand dollars, a hundred times the size, takes 99.76 percent, which is 1.23 times what the hundred dollars took. A pro rata share of a fixed pool cannot exceed all of it, so against a denominator this small the arithmetic saturates almost immediately and the marginal dollar buys close to nothing. That is not an opportunity. It is a measurement of how few depositors we have.

Three things bound it, and all three run the same direction. The share is an upper bound, not a reservation: nothing is allocated or held for any wallet, the two existing eligible wallets keep accruing every hour exactly as a new one would, and every fragment anyone else earns before the snapshot lowers it. It is a share of the 5,000,000 KERNE community tranche and not of the whole 50,000,000: since August 6 the other 45,000,000 is a separate scale tranche divided by dollar-hours on the part of a position above 100,000 dollars, with no multiplier of any kind, and fragments do not divide it at all. No position has ever qualified for it, and if none ever does that tranche is not allocated rather than shared out among everyone else.

And the condition on all of it: no token generation event is scheduled, announced or dated, no contract that converts a fragment into KERNE has been written or deployed, and if no distribution ever happens these fragments convert to nothing.

Do not read the deposit and the token count as a price

The table above puts a dollar figure in one column and a KERNE count in another, which is the shape of a price quote, and a reader can divide the two without any help from us. So it is worth saying what that quotient would mean, which is nothing.

A deposit here is not spent. kUSD is redeemable one for one through the peg stability module and you keep it. The KERNE count is a share of a fixed pool that a position earns by being held, not something the deposit purchases, and the deposit is still yours either way. KERNE has no market to price it against in any case: no pool, no listing, no price source. We do not publish a KERNE price and we do not stand behind any number derived by dividing one of those columns by the other.

What none of this fixes

A post about auditing points surfaces that ended on our own repair would be an advertisement. Here is what is still open on our side, all of it published elsewhere on this site, and all of it worth checking on any program you run this against.

• The denominator being small is not good news. It is the same fact as almost nobody having deposited. A large share is what a program looks like when it has not worked yet, and any program showing you one is telling you the same thing about itself.
• Fragment balances are not independently verifiable. They are an off-chain accrual we maintain against the on-chain kUSD supply. You can read the board, you can recompute every share on it, and you cannot audit the accrual itself from a block explorer. Our terms say so. The scale tranche is measured in dollar-hours precisely because those come from public chain state and fragments do not.
• The cohort multiplier attaches to when a hold started, not to its size. One dollar held today locks today's rate on a much larger balance added later, and only a full exit to zero resets it. That is a real gap, it is disclosed rather than fixed, and its reach is bounded by the split: multipliers touch the community tranche only.
• The public leaderboard is served one page at a time, capped at one hundred rows. A board longer than that would be summed short, which would make the denominator too small and every share above too large. Both panels now refuse to quote a share off a full page rather than quietly summing it. Today the whole board is four rows, so this has never bitten; we are naming it because it is exactly the kind of thing that is invisible until it is not.
• This check has no automation behind it. The calculator now resolves its window from the published sequence instead of a date, so appending a window needs no edit to it. That removes this instance. It does not remove the class, and we do not currently have a test that opens these surfaces with a clock set past a snapshot.

Run it yourself

Every figure above comes from two unauthenticated calls. Sum the balances, subtract the labelled rows, and you have the eligible denominator any published share has to divide by. The second call returns the window that is actually earning, which is the thing a pinned surface does not ask.

curl -s 'https://app.kerne.fi/api/opal/leaderboard?pageSize=100' | jq '.data.entries'
curl -s https://app.kerne.fi/api/opal/epoch/current | jq '.data'

Then open the surface that does the dividing and compare the window it names against the window that second call returns. If they disagree, you have found the same thing we did. It costs nothing to check and there is no program, including this one, where somebody checking it is unwelcome.

The exclusion rule in full, with the calculator that reads the same endpoint, is on the token disclosure page. The live board, the eligible denominator and the same arithmetic are on the Opal page.