Deployed vs Source
Last updated: June 12, 2026
On any young protocol the repository moves faster than the chain. This page is the canonical table of every place where Kerne's deployed bytecode behaves differently from the current source, published before any external audit begins, so a reviewer reading the code finds context here rather than surprises there.
The reading rule: when an internal security document marks a finding FIXED, that means fixed in source. Whether the fix is live on chain is a separate fact, and this page is where that fact lives.
How to read the protocol's state
Every security finding Kerne has published falls into one of four buckets:
- Fixed and deployed. The fix is live bytecode. The findings tracker cites the closing commit and date per finding.
- Fixed in source, riding the prepared redeployment. KerneVault v2, KUSDPSM v3, and an oracle router are staged, scripted, and fork-rehearsed as a single multisig deployment ceremony. A set of published vault and PSM findings close on chain when it executes. Until then those fixes exist in source only, and we say so here rather than let the word FIXED imply otherwise.
- Open on chain, with a mitigation and an operating rule. The three standing divergences in the table below. These are the gaps that persist after the prepared redeployment, each with a stated rule that bounds its exposure.
- Source only, never deployed. The repository contains contracts that have never been deployed (including kUSDMinter and the entire cross-chain bridge stack, the latter under an explicit do-not-deploy quarantine). Findings against them affect no live funds. The auditor-facing scope document draws this boundary precisely.
The three standing divergences
Each row states what the live bytecode does, what the current source does instead, the practical exposure, and the operating rule that bounds it. All three contracts are source-verified on BaseScan and Sourcify, so everything described here is independently checkable against the deployed code itself.
kUSD
Deployed 2026-04-08Deployed bytecode
Standard OpenZeppelin ERC20Burnable: burnFrom is callable by any address holding an allowance from the token owner. No role gate on burning.
Current source
Burning is gated behind BURNER_ROLE in src/kUSD.sol; only role holders can burn third-party balances, allowance or not.
Practical exposure
An attacker must first obtain an allowance from the holder (a malicious or compromised approval target). With one, they can destroy the holder's kUSD rather than transfer it. There is no path to burn without an allowance, so the practical surface is the same approval hygiene every ERC-20 demands.
Operating rule
Permanent disclosure item. No kUSD redeploy is planned: a token migration would cost holders more than the role gate is worth at current scale. Treat kUSD approvals with the same care as any token approval.
KerneYieldDistributor
Deployed 2026-04 (pre-timelock source)Deployed bytecode
ROOT_UPDATER_ROLE can set a new Merkle distribution root with immediate effect. The role is held by the operational hot wallet 0x09a2780ac8Be6D5d2d1F85A8D92b09D40C9CA37e (the same EOA that signs the hourly Proof of Reserves).
Current source
Root updates go through proposeMerkleRoot and executeMerkleRoot with a 24-hour ROOT_UPDATE_TIMELOCK, so a compromised updater key cannot route funds instantly.
Practical exposure
If the deployed contract held funds and the hot key were compromised, an arbitrary root could claim them. Today the exposure is zero in practice because the contract is deliberately unfunded: there is nothing on it to route.
Operating rule
Standing operating rule: never fund the deployed distributor. Redeploy from current source (with the timelock) before any real yield routes through it. The unfunded state is verifiable on chain at any time.
skUSD
Deployed 2026-05-11Deployed bytecode
distributeYield credits each distribution to the share price immediately, with no streaming or vesting window. A depositor entering just before a distribution and exiting just after captures a share of it proportional to transient capital. We found and classified this ourselves as a High severity finding on 2026-05-28.
Current source
The upgraded staking vault (skUSD v2) streams distributions over a vesting window, removing the incentive to bracket a distribution with transient capital.
Practical exposure
Bounded by distribution size: only the amount distributed in a single event is capturable, never principal. At current protocol scale distributions are small, and the protocol controls their timing and size.
Operating rule
Interim rule: distributions stay small and frequent so the bracketable amount per event stays negligible. Staking of institutional-scale capital is explicitly gated on the skUSD v2 deployment plus the external audit; the anchor terms encode that gate. The v2 redeploy decision is pending and tracked.
Why we publish this
A reviewer who finds a source-versus-chain gap on their own has every reason to read it as concealment. The same facts, stated by the team first with addresses and operating rules, are evidence the team knows its own system. Kerne has found and published over two hundred findings against its own code; this page is where the honest residue of that work lives. If a future deployment changes any row above, this page changes in the same commit.
Continue the audit trail: the audit and security posture page, the per-finding status tracker, the public contract registry, and the one-link diligence surface at kerne.fi/dataroom.