Kerne Logo
← Back to Insights
May 6, 20265 min read

How to Verify Kerne Without Trusting Us

A guided tour of the URLs, line-cited sources, and parity tests that let a stranger check our security claims in five minutes, without us in the middle.

How to Verify Kerne Without Trusting Us

Most security posts in DeFi are advertising in a serious tone. They list audit firm logos, test counts, and bug bounty maximums, then ask you to trust the team that the numbers are accurate. We held this post back for almost two months because shipping that kind of artifact would have meant exactly that: a polished claim about safety with no way for a stranger to check it.

What changed is not the marketing copy. What changed is that the operational surface around the protocol caught up to the claim. Today every commitment we make about how Kerne behaves in adverse conditions is published as a live JSON value, line-cited to the source file that enforces it, asserted in a parity test that fails CI when the documentation drifts, and surfaced visibly when the protocol enters a protective state. This post is a guided tour of that surface. Every section below points at a URL or a code path you can open right now, without us in the middle.

1. Every wired threshold, with its source file

The endpoint at /api/risk-status returns the live value of every commitment we have made in the runbook. For each trigger, the response includes a source field naming the file and symbol the limit is enforced from. Solvency ratios cite KerneVault.sol:getSolvencyRatio. Off-chain freshness windows cite the sentinel risk engine. PSM caps cite the PSM contract.

The same response also includes a specNotYetWired array. It is a list, by name, of things the documentation implies are live and which are not actually enforced on chain. We publish this gap because the alternative is a bigger, hidden gap. If you are evaluating Kerne, the smallest meaningful read is to load the endpoint, scroll to that array, and decide whether the items in it are acceptable in their own right.

2. The four-bucket reserve breakdown

Proof of reserves is a phrase that has been stretched almost out of meaning. What we publish at /api/por is a single JSON object that decomposes the protocol's vault into the four places its assets actually live: on-chain WETH balance, off-chain CEX collateral attestation, L1 Hyperliquid bridge balance, and the dedicated hedging reserve. Each bucket has a source attribution and a USD valuation derived from a live oracle.

The solvency.ratio field is a real number when there is real supply to compare it against, and null with status: "no-supply" when there isn't. We do not invent ratios when there is nothing to ratio. This is the boring half of verifiability: the endpoint is allowed to say it does not know, and it does say so when it does not.

3. The parity test that keeps spec, API, and contract in lockstep

The runbook chapter at Exit Triggers and Emergency Runbook, the /api/risk-status endpoint, and the on-chain constants in the vault contract are three different surfaces, owned by three different parts of the codebase. The risk in that arrangement is silent drift: someone updates the chapter without updating the contract, or vice versa, and the protocol's stated rules quietly stop matching its enforced rules.

A single test file in the bot repository, bot/tests/test_threshold_constants.py, asserts that all three surfaces agree on every named threshold. If the chapter says the critical solvency floor is one number and the contract enforces a different one, the test fails in CI before the change can ship. This is not glamorous and it is not what audit firms write reports about, but it is the structural reason the documentation cannot drift away from what the protocol actually does.

4. What is verified, what isn't, with timestamps

The Security and Audits chapter is the part of this post that most security pages elsewhere quietly skip. Several of the deployed contracts are not yet verified on Basescan. We know which ones, we published the list, and for each one we documented the reason it is unverified (in some cases the contract was deployed from uncommitted local edits; in others source was lost to an early git history reset) and the concrete remediation path: redeploy from the verified, current source so the bytecode reproduces against a public commit hash.

External audit work is in scope and on the roadmap. We are not listing audit firm names until conversations are far enough along that the listing is a fact rather than a marketing artifact. The same chapter will be updated with the firm, the scope, and the timeline as those conversations close.

5. The banner you may have just seen on the homepage

If you arrived at kerne.fi today, you may have noticed a small amber line above the hero pointing you at the PSM mint as the live revenue surface. That banner is wired to the same /api/risk-status endpoint as the rest of the trust surface. The vault is in a protective accounting mode while share supply reconciles, and rather than hide that under an opaque "deposits temporarily disabled" wall, we tell you what is happening, why minting is unaffected, and where to read the live status.

The banner is the smallest, most visible example of the rule the entire trust surface is built around: never let the marketing surface and the operational surface disagree. If the API says the protocol is in a protective posture, the homepage says so too, in the same visit.

What "verifiable" actually buys you

"Verifiable" is doing real work in that sentence. It is not a claim that nothing can go wrong. It is a claim that when something does, you do not have to take our word for what is happening. The runbook explains the rules. The API publishes the live values of those rules. The parity test asserts the documentation and the code agree on what those rules are. The audit chapter tells you exactly what has and has not been independently verified. If any one of those four loses parity with the others, it shows up before we can spin it.

The protocols that have failed in this category in the last twelve months failed because their reserve composition was off chain and unverifiable, or because their mint completion was off chain and uncapped, or because their advertised yield was a backtest dressed as a live number. Kerne is built so that none of those three statements can be true about us without you being able to see it.

For the rules in plain English, read Exit Triggers and Emergency Runbook. For the live values right now, /api/risk-status is one URL. For the reserve breakdown, /api/por. For the audit posture and the named verification gaps, Security and Audits. None of these surfaces require trusting us; they require five minutes.

Ready to deposit?

Mint kUSD with USDC at the live PSM, 1:1 backing, 10 bps fee.

Or deposit WETH for kLP shares earning the live APY today. Genesis Phase: 0% protocol performance fee.