Our First External Audit, in Full: Every Finding Hexens Raised, and What We Did About Each One

The final report from our first external security audit is public. You can read it here: https://github.com/kerne-protocol/contracts-public/blob/main/audits/hexens-kerne-protocol-final-2026-07-31.pdf. The reviewer was Hexens, and we paid for it, which is worth saying out loud because it is true of essentially every audit in this industry and is rarely said.

Most protocols mark this moment with a badge and a link. We are going to do something less flattering and more useful, which is to publish the response matrix. Every finding, what severity it carried, what we changed, and for the two findings where we did not ship a code change, the actual reasoning rather than a shrug. That is the same standard we apply to everyone else on our honesty index, where our own row goes first and is currently the worst one on the board. Applying it to our own security review is the least we can do.

What was reviewed, precisely

Scope was five contracts: kUSD, skUSD, KUSDPSM, KerneVault, and esKERNE, each pinned to an exact commit link in the report's own scope section. Fieldwork began on July 13, 2026, the initial report was delivered on July 20, 2026, and the final report published on July 31, 2026. The commit under review was 0912c870, frozen before fieldwork started so the reviewed code could not move underneath the reviewers mid engagement.

A freeze stops drift during an engagement. It does not make the reviewed commit the deployed one, and on the vault it did not. Of the five contracts reviewed, the live peg stability module and the live skUSD run commit 0912c870 exactly, byte for byte, which you can check on Sourcify without asking us. The live KerneVault does not. It was deployed on June 16, 2026 from source a month older, so every finding below is open on that bytecode, and so are three defects we found ourselves after the deploy and before the freeze, which is why they are not in the report. That vault holds no user funds, no shares have ever been issued from it, and no deposit opens into it until the remediated build is deployed and verified. We are stating this in the same post that announces the audit rather than letting someone find it with a block explorer, because the second version of this paragraph is the one that ends a protocol. The whole map, contract by contract and finding by finding, is at /security/deployed-vs-source.

What was not in scope matters as much as what was. The off-chain hedge leg, which runs on Hyperliquid as a single venue and is self reported rather than independently re-derivable on chain, is not something a smart contract review can attest. Neither is our operational security, our key custody practice beyond what the contracts encode, or our economic model. An audit of five contracts tells you about five contracts. We list the rest of our open gaps, unchanged by this report, at /legible.

What it found

0 Critical, 2 High, 2 Medium, 4 Low, and 2 Informational: ten findings in total. On the re-test, the report records that all identified issues were either remediated or acknowledged by the development team and subsequently verified by its auditors.

Every one of them was in KerneVault, the contract that holds assets and does the accounting. The stablecoin itself, the staked receipt, the peg stability module that mints and redeems kUSD against USDC, and the escrow token drew zero findings between them. We think the first three carry the most weight here for anyone holding kUSD, because those are the contracts that stand between a holder and their dollar. It is also not a promise. A review finding nothing in a contract is evidence, not proof, and the honest reading of a zero is that a competent team looked and did not find something, not that nothing is there. One further caveat on that zero, since we would want it made if this were someone else's post: both High findings concern the escrow token's forfeiture mechanism, and the report files them against the vault because that is where the offending code sits. Zero findings filed against esKERNE is not the same as the escrow design going unexamined.

The two High findings, in plain language

Both High findings were about the same mechanism: esKERNE forfeiture, the rule that says if you leave the vault early you forfeit your still-unvested rewards to the people who stayed.

The first was a gas problem. The forfeiture call was made on a best effort basis, wrapped so that a failure would not block the withdrawal. That meant a withdrawer who supplied just enough gas for the withdrawal but not enough for the forfeiture could exit with their unvested rewards intact. The withdrawal would succeed and the forfeiture would quietly not happen.

The second was an identity problem. Vault shares are transferable, so a holder could move their shares to a second wallet and have the withdrawal happen from an address that the forfeiture logic was not looking at. The exit and the penalty could be separated.

Eight we fixed, immediately

We returned a complete per finding response within a day of receiving the initial report, well inside the window we had, and asked for the re-test immediately. The report's own changelog records the revision arriving on July 21, 2026. The fixes are a single surgical diff on one file, branched off the exact commit that was reviewed, and the report names that remediation commit in its scope section.

The gas starvation finding we closed with a floor. Before the forfeiture call the contract now requires a minimum amount of gas remaining, and reverts the whole withdrawal if it is not there. The outcome set goes from three possibilities to two: either forfeiture runs, or the withdrawal fails. The quiet third option, where the withdrawal succeeds and the penalty is skipped, is gone. Ordinary full gas withdrawals are unaffected.

Two accounting findings were about the vault under reporting or failing to react. One: when the verification node call failed, the vault's total assets reading silently dropped the off-chain buckets instead of falling back to the full formula, which meant a transient outage briefly made the vault look poorer than it was, and anyone who could trigger that outage on demand had a cheap mint and redeem window. That fallback now returns the complete figure. Two: the function that captures founder revenue reduced assets without arming the collateral ratio circuit breaker, unlike the three other paths that reduce assets. It arms it now.

The rest were smaller and are in the report in full: a deposit cap that counted the deposit fee as though it stayed in the vault, so deposits were turned away slightly early, a withdrawal claim that was not bound to the share price at the moment the withdrawal was requested, a bucket that could get permanently stuck at zero, and two pieces of dead or redundant code.

The one we caused ourselves

The stuck bucket finding deserves its own paragraph, because it was our fault in a specific way. In May 2026 we hardened the vault's rate limiting so a strategist could not zero a bucket and then restore it to bypass the per update change cap. That hardening introduced a bug: once a bucket legitimately sat at zero, the rate limit maths made every non-zero write revert forever. There was no path back up.

We did not find it. Hexens did. The fix replaces the silent failure with an explicit error that names the recovery path, which is a deliberate multisig gated re-seed rather than something the strategist can do alone, so the original bypass stays closed. We are writing this down because the useful thing about publishing a matrix is that it includes the findings that make you look worse, and a defect introduced by your own security work is one of those.

The two we did not change, and why

We agreed with all ten findings as valid. We disputed none. But on two of them we did not ship a code change, and the reasoning is the part we would most want to read if this were someone else's post.

The share transfer High finding. The obvious fix is to make vault shares non transferable while the forfeiture mechanism is set. We implemented that, and then our own adversarial re-review caught what it does. Those shares are the collateral asset for kUSD borrowing positions. Blocking wallet to wallet transfers would have broken collateral deposits and, worse, made underwater positions collateralized by those shares impossible to liquidate, because a liquidator seizing collateral is itself a share transfer. That removes the liquidation backstop from the collateral system, which is a solvency critical regression traded for a latent finding. The second obvious fix, firing forfeiture whenever shares move, would slash a user who merely posted shares as collateral and still economically owns the position.

A correct fix has to tell an economic exit apart from a collateralization or liquidation movement, which is a design decision rather than a patch. So we said so, and we said what makes the wait acceptable: the forfeiture mechanism is inert on chain today. Nothing has ever been emitted for it to act on, and the token it would redeem into is retired. We will not enable it until the ownership versus forfeiture binding is designed and re-tested.

The upper bound circuit breaker finding. The recommendation was to pause the vault when the collateral ratio rises above the safe threshold, on the theory that an inflated ratio signals manipulation. A healthy delta neutral vault routinely runs above that threshold in ordinary operation, so a hard pause there would halt the vault on good days rather than only on bad ones. Picking a sensibly high bound is a tuning question we would rather resolve deliberately. In the meantime the bucket updates that could inflate the ratio are rate limited and cooldown gated, withdrawals route through a request queue and can never be same block with an inflation, and the withdrawal claim fix above caps the payout at the request time snapshot, which removes the profit from the scenario the finding describes. We told the auditor we are open to adding a conservative upper bound alert as a follow up.

The correction we sent about our own answer

Our first written justification for leaving the share transfer finding alone said the forfeiture hook was disabled because the escrow token address was unset. We went back to check that on chain rather than trust our own sentence, and it was wrong. The hook is wired to the current escrow token. The disposition did not change, because the mechanism is still inert for the reason above, nothing has been emitted and the redemption target is retired, but the stated reason was inaccurate. We sent the correction to the auditor in the open re-test window rather than let a wrong sentence sit in the record.

That is a small thing and we are giving it a section on purpose. The gap between a protocol that corrects its own filing unprompted and one that does not is the entire difference this project is built on.

What this does not mean

A completed audit changes one specific thing: the five reviewed contracts have now been examined by an external team with a published result you can read. It does not make the code safe, and we are not going to describe ourselves with words the report does not use. Smart contract risk after an audit is lower than before one and is not zero, which is why our bug bounty stays open at /security and our findings response protocol at /security/findings-response is unchanged.

Everything else we disclose is exactly where it was yesterday. The hedge leg is self reported on a single venue and an independent attestation of it is being scoped. We are at Genesis scale, and the staked yield we publish is a live model against a through cycle band, not a large realized distribution, with the realized figure sitting first and lowest on our own index. Those are the numbers to argue with, and they are all on one page at /honesty-index.

Where to check the rest

The full report is at https://github.com/kerne-protocol/contracts-public/blob/main/audits/hexens-kerne-protocol-final-2026-07-31.pdf, and our security posture page, including the internal adversarial reviews that came before this one and the per finding status of each, is at /security/audits. The reserve backing kUSD is readable straight off Base, and we publish an hourly proof of reserves signed with an EIP-191 key that you re-derive yourself at /verify and /api/por, with no attestor in the path.

Finding counts, severities, and dispositions are as stated in the published Hexens report; where this post summarizes a finding in plain language, the report's own text governs. Nothing here is investment advice, and nothing here is an offer. An external audit is a review of specific contracts at a specific commit and is not a guarantee of safety, a solvency opinion, or a statement about the off-chain leg of the design.