Pre-committed before fieldwork
Findings-Response Protocol
Published July 8, 2026
How Kerne triages, remediates, and discloses security findings during its external Hexens audit. Written and published before fieldwork begins on July 13, 2026, so a finding is met by a stated process rather than an improvised one.
Kerne has engaged Hexens for an independent security audit of its core protocol (kUSD, skUSD, KUSDPSM, and KerneVault). Fieldwork begins July 13, 2026 and the publishable report is expected mid-August 2026. This page is published before fieldwork starts, on purpose.
An audit exists to find things. We do not know what it will surface, and pretending otherwise would defeat the point of paying for one. What we can decide in advance is how we will 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.
| Step | Target |
|---|---|
| Log and acknowledge a reported finding | Within 1 business day. We are in active contact with the audit team for the duration of fieldwork. |
| Assess live exploitability against deployed bytecode | Critical or High: within 24 hours of report. Medium or Low: within 5 business days. |
| Publish a remediation plan for the finding | Critical or High: within 48 hours. Medium or Low: within the fieldwork window. |
| Ship and re-submit a fix for re-review | Critical: targeted before TVL scales beyond the current genesis phase and, where feasible, before the report publishes. Others: per the triage order, tracked publicly until closed. |
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.
Critical
Direct loss or theft of funds, permanent freezing, or insolvency. We assess live exploitability against the deployed bytecode within 24 hours. If it is live-exploitable, we contain the affected surface with the strongest control it exposes (for example pausing the vault, halting PSM minting, or gating deposits) through the protocol admin controls, and disclose that action on the transparency page and here. The fix is then written, tested, submitted to the auditor for re-review, and tracked publicly on the findings tracker until it closes.
High
Temporary freezing, material access-control or accounting failures, or significant value leakage under realistic conditions. Same 24-hour exploitability assessment. Remediation plan within 48 hours, fix shipped and re-reviewed on the triage timeline, with the compensating control documented per finding until the fix lands.
Medium
Griefing, minor value leakage, or degraded functionality without direct fund loss. Assessed within 5 business days and remediated within the fieldwork window or queued in the published triage order with its status kept live on the tracker.
Low and Informational
Best-practice deviations, hardening opportunities, gas and code-hygiene notes. Logged, triaged, and either fixed or explicitly accepted with the reason recorded. None are hidden; the full set appears in the published report.
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. When Hexens delivers the report, it is published in full in the public contract registry at github.com/kerne-protocol/contracts-public under audits/, alongside the existing scope document and internal-review record. We will not substitute a summary for the report, and we will not delay publication to soften a finding. If the report lists open items at publication, they are published as open.
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 we are posting a public diary. 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 with the final report under coordinated disclosure.
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 audited, passed, secure, or clean at any point before the report is public. Until then the honest status is engaged and under review.
- 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.
Live fieldwork status and the running diary are on the Audit and Security Posture page. Per-finding live status is on the Findings Tracker. To report a vulnerability directly, see the Bug Bounty Program.