Findings-Response Protocol

Kerne engaged Hexens for an independent security audit of its core protocol (kUSD, skUSD, KUSDPSM, KerneVault, and esKERNE). Fieldwork ran from July 13, 2026, Hexens delivered its initial report on July 20, 2026, and the final report published on July 31, 2026. This page was published before fieldwork started, on purpose, and the protocol below is unchanged since. The promise it made about publishing the report in full has now been kept, and you can check that against what this page said before it was possible to know what the report contained.

An audit exists to find things. When this page was written we did not know what it would surface, and pretending otherwise would have defeated the point of paying for one. What we could decide in advance is how we would act on whatever it finds: how fast we triage, how we handle each severity, when a live surface is paused, and where the result is published. That is what this page pre-commits to.

A protocol written before a finding lands is process. The same words written after a critical would read as damage control. Committing to them now, in public, is what lets us run an honest, real-time fieldwork diary without the diary becoming a liability. Nothing here promises the audit will come back clean. It promises that the response will be the same whether it does or not.

Triage timeline

These are stated targets for our response, not guarantees, and they run against the working day. They exist so a reader can hold the response to a clock rather than take it on trust.

Severity handling

Severity is assessed against live exploitability on the deployed contracts, not just against repository source. The classification mirrors the bug bounty severity guidance so the two surfaces stay consistent.

Disclosure format

Coordinated disclosure. While a finding is live-exploitable and unpatched, we do not publish a working exploit path for it. The finding is acknowledged and its status is tracked, but the reproducible detail is withheld until a fix is deployed or the auditor agrees it is safe to release. This protects users, not us: the same detail that would let a reader verify the issue would let an attacker use it.

The full report, whatever it contains. KEPT on July 31, 2026: the Hexens final report is published in full, unedited, in the public contract registry at github.com/kerne-protocol/contracts-public under audits/, alongside the existing scope document and internal-review record. No summary was substituted for the report and publication was not delayed to soften anything. Two of the ten findings are published as acknowledged rather than fixed, which is exactly the case this promise was written to cover.

Per-finding live status. Every named finding that sees a remediation commit is enumerated on the findings tracker with its current status (open, partial, closed, or mitigated) and, when closed, the commit that closed it. The tracker moves with each remediation, so the open count is always current rather than a periodic manual claim.

A finding landing mid-fieldwork

The scenario this protocol is built for is a Critical landing in the middle of fieldwork while a public diary is running. Handled without a plan, that is a crisis. Handled by a published process, it is the audit doing exactly what we paid for.

The sequence is fixed: (1) assess live exploitability against the deployed bytecode within 24 hours; (2) if it is live-exploitable, contain the affected surface with the strongest control it exposes (pausing, halting mints, gating deposits, or removing the at-risk funds) through the protocol admin controls, and disclose that action on the transparency page and here; (3) write, test, and submit the fix to Hexens for re-review; (4) track the finding, its status, and the closing commit on the findings tracker; (5) publish the full detail under coordinated disclosure. Step 5 was discharged for the audit findings on July 31, 2026, when the report published in full; it continues to govern anything raised after it.

Custody note, stated plainly: some surfaces are controlled by the 2-of-3 Safe and some by the deployer key where rotation to the Safe is still pending. Which is which is published live on the skUSD admin status page, so a reader can check exactly what control we actually hold before we claim we can pause anything.

What we will not do

• Describe the code as passed, secure, clean, or safe. That rule did not expire when the final report published on July 31, 2026, and it has no expiry date. The honest status is now that one external review of five contracts at one commit is complete and readable, that two of its findings were acknowledged rather than fixed, and that the live vault runs earlier bytecode than the commit that was reviewed.
• Cherry-pick or pre-announce a favorable interim result. Interim posts describe process (what surface is being reviewed, what has been submitted for re-review), not verdicts.
• Publish a working exploit path for a live, unpatched Critical or High finding.
• Quietly drop a finding. Anything the audit surfaces appears in the published report, and anything remediated is tracked to its closing commit.