Who Actually Holds the Points? Five Checks You Can Run on Any Points Program, Run Here Against Our Own.

A points program is a promise with a fraction in it. Your points over total points, times some pool. Every program states the numerator, because the numerator is yours and it is on the dashboard. Very few state the denominator with any precision, and almost none tell you who is inside it.

That omission is not cosmetic. If the issuing team's own wallets sit in the denominator, then the pool you are competing for is not the pool that was advertised, and the difference is not marginal at the sizes involved. It is also one of the few things about a points program that is genuinely checkable before you commit capital, because points boards are usually public and wallets are usually identifiable.

Below are five checks. They take a few minutes each and they work on any program that publishes a board. Then we run all five against Kerne's own program, which fails the first version of the test badly enough that we had to publish a rule to fix it, and then created a second problem we had to publish a second rule to fix. Both are in here, including the numbers we would rather not print.

Check 1. Is the leaderboard readable without connecting a wallet?

Most points dashboards render your row after you connect. Some render a global board. The distinction matters more than it looks, because a board that only ever shows you your own position makes every question below unanswerable by construction. You cannot audit a denominator you are never shown.

The test is mechanical. Open the board in a private window with no wallet, or call the API directly. If the response requires an address, the program has chosen not to be checkable on this dimension, and that is a finding on its own rather than a reason to give up.

Kerne's board is a public GET with no wallet, no key and no signature:

curl -s https://app.kerne.fi/api/opal/leaderboard

That endpoint is the source for every Kerne figure in this post. It is also, deliberately, the same endpoint our own on-site calculator reads, so a reader can check the page against the API rather than against a screenshot.

Check 2. Can you name the issuer's own rows?

Having the board is not the same as understanding it. The next question is which of those addresses belong to the team. There are four cheap ways in, and you usually only need one:

• The program labels them. Rare, and worth noticing when it happens.
• The deployer. Take the contract address from the docs, pull its creation transaction on a block explorer, and look for the deployer among the top rows.
• The treasury or multisig, which is normally published somewhere in the docs or the governance forum for unrelated reasons.
• Shape. A wallet that has held a position continuously since the first block of the program, at a size nobody else matches, on a board with very few rows, is usually not a stranger.

On Kerne's board the rows are labelled, and the two labels are ours.

Check 3. Excluded from what, exactly?

When a program does publish an insider rule, read the verb. "Excluded" can mean at least three different things and they are not close to equivalent:

• Excluded from earning. The insider wallets accrue nothing. Cleanest to state, hardest to verify from outside, because you are being asked to believe an absence.
• Excluded from the denominator. They keep accruing and keep their visible rank, and their points simply do not divide the pool. Verifiable, because you can see the rows and do the subtraction yourself.
• Excluded from conversion. Same as above at the moment that matters: whatever they hold, they claim none of the distribution.

The second and third are the ones a reader can check. The first requires trust, and a program that deletes its own rows from a published history has made its own rule unauditable in the name of fairness.

Check 4. Where does the excluded share go?

This is the question that decides whether an exclusion rule is real, and it is the one most often left unanswered.

If insiders are removed from the denominator and the pool size is unchanged, the excluded share does not vanish. It is redistributed across everyone who remains. That is usually the intent and it is fine. But the same mechanic run on an unclaimed tranche is not fine, and the distinction is worth carrying around: if a gated portion of a pool falls back into the ungated portion when nobody qualifies, the gate is decorative. A reader can compute "nobody will clear that bar, so it all falls back to me anyway" and be right, and the rule has changed nothing except the length of the documentation.

So the question to ask of any tiered or gated points pool is simply: if the gated tranche goes unclaimed, is it issued to anyone at all? A program that will not answer that has not designed the tranche, it has described one.

Check 5. Do the spec page and the rules page agree?

A rule adopted on one surface and contradicted on another is not adopted. This sounds like pedantry and it is the most productive check of the five, because it is the one that catches programs whose fairness rule was a blog post rather than a change.

Search the site for the formula itself. Look for the denominator word: "total" versus "eligible" versus "qualifying". If the announcement says eligible and the docs page, the FAQ, the whitepaper or the structured data behind the FAQ still says total, then at least one published surface is still telling a reader the issuer collects its full share.

We know this one from the inside. When we adopted our own exclusion rule on August 4 we shipped it and then found the un-excluded formula still live on two more surfaces, including the spec page whose entire job is to state the formula. Two days later, after a second change to the same denominator, a grep of the rendered HTML found eight more, including the homepage FAQ, the JSON-LD behind that FAQ, a transactional email body and two social preview images. Every one of them had survived the sweep before it. If you are auditing someone else's program, the corollary is that the marketing page is the least reliable place to read the rule, and the machine readable surfaces are the most revealing, because nobody remembers to update them.

The worked example, which is us

Read from the public endpoint at 2026-08-11T23:19:09.787Z. Four wallets, which is the whole board.

Applied literally, the formula this program launched with sent roughly ninety-nine percent of a fixed 50,000,000 KERNE allocation to the wallets that issued it. Nobody had to be dishonest for that to happen. The accrual rule is size times time, we were the first depositor and for a while the only one at any size, and points programs compound. It is the default outcome for any program whose issuer seeds its own product, which is most of them at the start.

The rule we published on August 4 removes both of our wallets from conversion, and deliberately not from accrual. They keep accruing, they keep their rank on the board above, and they claim none of the allocation. That shape was chosen for a reason worth stealing: the accrual path carries six regression tested controls against point inflation, and a conversion side rule reads the ledger without ever writing to it, so it cannot regress any of them. Deleting insider rows from a published history would also have been a second problem rather than a fix for the first.

What it costs, stated plainly because a rule whose cost is not stated is not a rule: it removes about 97 percent of a 50,000,000 KERNE claim from the founder's own wallet. Any future narrowing of it has to be published before the next snapshot on the same terms.

The second problem, which honest exclusion creates and nobody warns you about

Here is the part we did not see coming, and it is the most useful thing in this post for anyone designing a program rather than auditing one.

Removing insiders fixed the numerator and broke the denominator. Removing them took our denominator from essentially the whole board down to about one percent of it: as read above, 2,182,168 fragments out of 219,380,251, held by two wallets holding roughly ten dollars between them. A pro rata share of a fixed pool cannot exceed all of it, so against a denominator that small the arithmetic saturates almost immediately. On our own published numbers, stamped to a deposit made on August 6: about sixty dollars took half of the entire allocation, about five hundred and fifty took ninety percent, and a million dollars took 99.99 percent. The last $999,456 of that million bought roughly eleven percent more than the first $544 already had.

Read literally, our own program was telling an allocator that the rational deposit was five hundred dollars. Every dated urgency we published rested on a snapshot that our own arithmetic made pointless to show up for at size. That is not a presentation problem and it is not fixable with wording. It is a computable argument, derivable in a minute from our own ungated endpoint, for never depositing at scale.

The generalisation: insider exclusion is only safe in a program that already has a real depositor base. A large program can exclude its team and barely move the denominator. A small one that excludes its team honestly discovers that its remaining denominator is a rounding error, and a fixed pool divided by a rounding error rewards the first small deposit and nothing after it. Every young program that does the right thing here inherits this, and most will find it after an allocator does.

There is a companion point that cuts the other way, and it should be said in the same breath. A small deposit dominating an eligible pool is a measurement of how few depositors a program has, not of what the pool is worth. "A thousand dollars takes most of the community tranche" and "there is essentially no community" are the same sentence read twice.

The fix, and the one property that makes it real

On August 6 we split the fixed allocation. The total did not change, no new tokens were created, and nothing was taken from any other allocation.

• 5,000,000 KERNE, community tranche. Exactly the existing rule, unchanged: pro rata by eligible fragments, no minimum position, every multiplier and bonus still applies. A wallet holding one dollar has the same unimpaired claim it had the day before, against a pool one tenth the size.
• 45,000,000 KERNE, scale tranche. Allocated pro rata by qualifying dollar hours. For each hour, a wallet's qualifying amount is the part of its exposure above a $100,000 position floor. No multipliers of any kind apply here. Not the cohort ladder, not referral, not liquidity or quest bonuses. Size times time and nothing else.

Three properties in that are load bearing, and any of the three being softened would make the whole thing cosmetic.

The floor is a deductible, not a cliff. Only exposure above $100,000 qualifies, so $99,999 earns zero, $100,001 earns one dollar hour per hour, and there is no discontinuity anywhere. It also means splitting a position across wallets can never manufacture qualifying exposure: one position of $1,000,000 qualifies on $900,000 of it, two of $500,000 qualify on $800,000 between them, and ten of $100,000 qualify on nothing at all. A cliff would have been both a gaming surface and an arbitrary looking exclusion.

An unclaimed scale tranche is not redistributed. If nothing qualifies, the 45,000,000 is not allocated and stays unissued. It does not fall into the community tranche. This is check 4 above, answered against ourselves, and it is the single property the fix rests on: with a fallback, a reader would correctly compute that nobody will qualify, so it all comes back, so the small deposit still takes ninety percent of everything, and the split would have been an elaborate way of changing nothing.

Nobody is excluded from the program. The floor gates one tranche, not participation. Accrual still has no minimum and the community tranche still has none, which is why "no minimum" remains a true sentence on our own FAQ rather than one we had to quietly retire.

As of this writing no position has ever qualified for the scale tranche, and the reason is arithmetic rather than policy: the entire kUSD supply is about $1,145, so if every kUSD in existence sat in one wallet it would still be about 87 times short of the floor. The qualifying denominator is zero, and it will stay zero unless capital that does not currently exist in this system arrives before the window closes. We are publishing that rather than describing the tranche as though it were contested.

One more thing has to be said next to a dollar figure and a token count on the same page, because the two sitting together is the shape of a price quote even when no price is stated anywhere. A deposit here is not a purchase. kUSD mints and redeems 1:1 through the peg stability module. Nothing is spent to acquire a position, so dividing a token count by a dollar figure produces a number that does not refer to anything, and no KERNE price is stated, implied or endorsed by any of the above.

What none of this fixes

A post about auditing points programs that ended on our own fix 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 other program you audit.

• No Sybil resistance. The exclusion rule matches on a list of addresses and labels. It cannot detect a Kerne controlled wallet nobody added to the list. Our written commitment is that any such wallet appearing on the board is added before the next snapshot it would count toward.
• Fragments are off chain. They are maintained by us and are not independently verifiable on a public chain, and our own terms say so. That is exactly why the scale tranche is measured in dollar hours instead: kUSD balances derive from public Transfer events and vault share prices are public reads, so a holder can reconstruct that figure without trusting us. The community tranche does not have that property.
• A multiplier gap we chose not to close. The cohort multiplier keys on when a continuous hold started, and that start is preserved across top ups, so a dollar held today locks today's rate on an arbitrarily large balance added later. Fixing it would have meant editing six regression tested anti inflation controls days before a snapshot. Instead the multiplier's reach shrank by construction, because no multiplier touches the tranche that now carries ninety percent of the pool. The gap is real, it is disclosed, and it is not fixed.
• None of it makes a distribution more likely. A fragment standing is a share of a pool, not a token. Conversion to $KERNE depends on a token generation event that is not scheduled and not guaranteed, and if no distribution ever happens fragments convert to nothing. A fairer rule for dividing something that may never be divided is still just a fairer rule.

Run it yourself

Every number above comes from one unauthenticated call. Sum the balances, subtract the two labelled rows, and you have the eligible denominator that any published share has to divide by.

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

The second call returns the earning window, including the instant it ends. For the current window that instant is 2026-08-19T19:59:17.805Z, and it is enforced in two independent places rather than announced: every credit path clamps its clock to the minimum of now and that instant, and a migration flips the window inactive at the same moment. Either one alone stops the board moving. We mention the mechanism because "standings lock at the snapshot" is a sentence we were not allowed to write until something implemented it, and for six days in early August we wrote a weaker one instead.

The rule in full, with the calculator that reads the same endpoint, is on the token disclosure page. The argument that forced the split, with the arithmetic, is on the anchor tier page.