The removal log.

The three pages said that the live mint-authority values were asserted on a schedule by a workflow named in the text, and that if one of them flipped, the workflow would fail. GitHub Actions is disabled at the repository level. That workflow last ran on June 26, 2026, and its final five runs were all failures. So for roughly seven weeks, three public pages, one of them a risk page and one of them a direct comparison against another protocol's security posture, described a control that was not running.

What was true, and is kept, is the other half: those values are read on every request by /api/risk-status, which is what /risk and the homepage banner render. The pages now say that, and say plainly that the values are checked when someone asks rather than on a schedule.

The reason this went unnoticed is worth more than the fix. The workflow file still exists in the repository, and the tool that lists workflows still reports it as active, because active describes the file and not the repository switch above it. Reading the file, or the listing, tells you nothing. A note now sits beside those files recording that they cannot run, and naming the one command that actually answers the question.

One of the three carried the same claim a second time, inside its own structured data, where answer engines read it and no human ever would. That copy was found only by checking the built HTML rather than the source after the visible sentence had already been fixed. A claim removed from the prose and left in the schema is still being published, just to a different audience.

The repository carries 5,067 open dependency alerts. 4,831 of them, a little over 95 percent, sit in vendored copies of other people's repositories that are excluded from every deployment and are not part of anything Kerne ships. 236 are in code that ships.

Two automatic pull requests were open. Across the repository's entire history, the number of such pull requests that had ever been merged was zero, and with Actions disabled none of them could have been tested anyway. So the automation was producing failure mail and nothing else, into the same inbox where a funding reply arrives.

Alerts were deliberately left on. The thing removed is the automatic pull request, not the visibility. The honest reading of the ratio above is that the signal for the 236 that matter was already buried under the 4,831 that do not, and that is a separate problem this entry does not claim to have fixed.

One of them was titled with its own staging instruction: do not merge before a particular piece of work was done. That work has since been done, several times over. A conditional prohibition becomes an authorisation the moment its condition fires, and nothing in a version control system re-reads the sentence to notice. Kerne has been caught by this shape before, which is why thirty three branches were audited and six neutralised on August 3, 2026; these two were open pull requests rather than branches, and were missed by that pass.

Both were checked against the current main branch before closing. Every file either one would have added is already there, so neither carried unshipped work, and merging either today would more likely have reverted something than added anything.

The oldest content on this site was the most dangerous, and it described a protocol that does not exist. The April 1 article and the docs chapter beside it sold the Kerne Neural Engine: a "proprietary predictive model", an LSTM forecasting module "trained on two years of real hourly funding rate data", a Monte Carlo engine "that generates thousands of synthetic market scenarios", and a venue router that sent orders "to the exchange offering the best net yield after all costs". It closed by saying this was why Kerne could "sustain industry-leading yields while maintaining the capital safety guarantees that institutional depositors require".

None of that was ever running. The forecasting that does exist is a four-parameter linear regression on three inputs, and Kerne publishes its coefficients, its residual standard deviation and its accuracy at /api/forecast: an R-squared of 0.44 against a naive baseline of 0.31. That is a real and modest result on a noisy target, it has been documented honestly at Live APY Math since May, and it is the opposite of a proprietary edge nobody may inspect. The venue router had nothing to route: the hedge is one Hyperliquid account, and /api/por reported its equity at $26.68 on the day these pages came down.

The other three carried the same shape of claim. One asserted a 35 percent cap on how much notional any single exchange could hold, and multi-venue distribution with "centralized backup venues for redundancy", against that one account. The same page promised veKERNE governance lock-in and omnichain deployment, neither of which exists. Another led with a present-tense yield in the low teens that the corrected basis retired on 24 July. The fourth described Kerne as institutional infrastructure "of the kind that manages hundreds of millions in treasury capital", against roughly $1,100 of reserves.

Two of the four had already been given dated corrections, and that is the part worth being uncomfortable about. Those corrections fixed the rate and left the fabricated machinery standing, because whoever wrote them was checking the number rather than the sentence around it. A correction that lands on the one claim you thought to check is not a review.

Deleting these cost nothing in traffic and that is measurable rather than assumed. Across the three months to August 11 the whole site drew 115 organic clicks, of which 71 went to /security. The entire insights archive, more than thirty articles, drew 1,260 impressions and one click. So the argument for keeping them was never distribution. It was that deleting things is uncomfortable, which is not an argument.

They redirect rather than 404 because several were submitted for indexing, captured by the web archive, and linked from posts that are still up. A redirect drops the URL from the index exactly as a 404 does, and still lands a stranger somewhere true.

The chapter stated, in the present tense and under a heading called Governance Scope, that "governance follows a standard of one KERNE equals one vote, with veKERNE providing boosted voting power based on lock duration", that "a minimum proposal threshold prevents spam, and a quorum requirement ensures meaningful participation", and that governance covers emission schedules and gauge weights. There is no governance contract, no voting contract, no veKERNE token, no proposal has ever been made and no vote has ever been held.

What replaced it is shorter and checkable. The KERNE supply is 1,000,000,000 and every one of them sits in the protocol Safe, which is a concentration fact rather than a governance mechanism, and both numbers are on-chain reads rather than assertions. Holding KERNE currently entitles a holder to nothing.

One paragraph was deliberately kept and it is the reason this was a rewrite rather than a deletion. The chapter carries a live custody disclosure: administrative actions need multi-signature consensus, kUSD and all three peg-stability modules have been behind a 48 hour timelock since August 6, emergency pause is exempt from that delay on purpose, and the staking vault is still administered directly by the Safe where two of three signers act immediately. That last sentence is the least flattering one on the page, which is exactly why cutting the chapter for length would have been the wrong move.

The runbook chapter ended its shutdown procedure with: "If any shortfall exists, the Insurance Fund covers the difference before processing withdrawals." The Insurance Fund holds nothing. This site says so, at length, on its own chapter about the fund, and publishes the zero hourly in the signed attestation. So one chapter promised a backstop and another disclosed that it was empty, and a reader who found the first one had no reason to go looking for the second. That is worse than having no backstop, because it converts a known gap into a hidden one.

The getting-started chapter offered institutions "dedicated whitelisted access with dedicated liquidity buffers" and "compatibility with institutional custody solutions". There is no access tier, there are no dedicated buffers, and no custody integration has been built or tested. The word whitelisted was the worst of it: the vault whitelist is currently what keeps depositors out, so a closed door was being sold as a privileged one.

Five chapters carried the sentence "near 3% as of 24 July 2026". On the day they were cut, /api/apy read 4.96%. The figure was not wrong when it was typed and it was wrong three weeks later, which is the whole problem with typing one. All five now point at the endpoint and print no number. This site had already adopted that rule elsewhere and simply had not applied it here.

The first entry on this page records three pages corrected for describing continuous integration that has been switched off since June 26, 2026. There was a fourth, found later the same day, and it was on the page least able to afford it: the article whose entire subject is how a stranger can check Kerne's security claims without trusting anyone here.

It said every commitment was "asserted in a parity test that fails CI when the documentation drifts", and that if the documentation and the contract disagreed "the test fails in CI before the change can ship". The test file is real and still passes when someone runs it. Nothing runs it. It is evidence a reader can reproduce, not a gate standing between a drifted document and production, and the page now says that in a dated correction rather than by quietly swapping the verb.

It survived the earlier pass for a reason worth writing down. That pass searched for pages naming a workflow file. This sentence names a test file instead, so it read as a claim about testing rather than a claim about scheduling. Searching for the artifact rather than the assertion finds the copies that phrase it your way and misses the ones that do not.

The page publishing the kUSD/USDC liquidity rules told a reader that the twenty five percent boost means a liquidity provider always out-earns a passive holder of the same size. The engine comment it was written from says something narrower and correct: an LP earns 1.25x what a passive holder earns on the same exposure, where exposure means kUSD-equivalent. Only the kUSD side of a position accrues, and in a balanced stable pool that is about half of it, so the same dollars provided as liquidity accrue roughly 0.625x what they accrue held directly. The page said the half part two bullets higher up, which means it carried its own refutation and nobody read the two sentences together.

The second sentence said fragments come on top of the pool's swap fees. The pool has recorded no swap, mint or burn since August 2, 2026, so there have been no fees to keep. That correction was made on the Opal page on August 12 after the pool was measured; the rules page was in the other deployment and did not move with it. A correction that reaches one of two projects has not been made.

The third was operational rather than promotional: get kUSD by minting, the page said, or by swapping USDC into it directly in the pool. At the depth that pool now carries, any size beyond dust moves the price against whoever tries. That sentence was true when it was written and was falsified by a withdrawal, with nothing anywhere wired to re-read it.

What was checked and kept: the boost is real, it is credited hourly by the accrual engine, and the page now states it against the comparison a reader is actually making. The risk bullet describing the pool as mostly protocol-owned was also checked, because it was reported as the false one. It is not false. The protocol bot wallet holds the LP supply bar a thousand wei, so the accurate correction ran in the opposite direction to the report: the page was understating, and now says entirely.