Kerne Logo
← Back to Transparency

Source Verification Audit

Per-contract reconstruction evidence. Last reviewed 2026-04-26.

Update, 2026-04-26

KerneToken has been reconstructed and verified. The contract previously listed as "reconstruction infeasible" was reproduced byte-for-byte from the January 7 source on April 25, 2026 and is now verified on BaseScan, Sourcify, and Blockscout. The verification surfaced a meaningful drift between the deployed source (100,000,000 initial mint, multisig-gated MINTER_ROLE) and the previously published documentation (1,000,000,000 cryptographically-fixed cap). The full disclosure is at /security/kerne-token-disclosure. The card for KerneToken has been removed from the "reconstruction infeasible" list below.

Why this document exists

Two of the thirteen Kerne production contracts still cannot be matched to source on BaseScan or Sourcify. Two more are scheduled for redeploy from current source and one is retired. KerneToken, originally listed here as infeasible, was reconstructed on 2026-04-25 (see disclosure above). Rather than leave the verification status as a silent blank, this page publishes the bytecode-level evidence for why the remaining gaps exist, what was tried, and what closes them.

The premise that matters for Kerne credibility is not are the contracts verified, but if they are not, can we prove we are not hiding something. The evidence below establishes three facts for each unverified contract:

  1. The exact block and UTC timestamp at which the contract was deployed (from Blockscout logs and cast block).
  2. The nearest candidate commits and their runtime bytecode sizes under both compiler profiles Kerne uses (default = 200 runs, production = 1000 runs, both via_ir, cancun, solc 0.8.24).
  3. The first-diff character between candidate and on-chain runtime core (after stripping the CBOR metadata tail), which tells you where the divergence lives, dispatch table, function body, immutable, or completely different contract.

A first-diff at character < 100 means the dispatch table itself differs, the contract has different public functions or different selectors than the candidate. That is unreconstructable without the source. A first-diff at character >= 2,000 usually means an immutable constant or a late function body, potentially fixable by picking a different candidate or compiler setting.

Methodology

For each unverified contract, we ran:

  1. Overlay the candidate commit into a detached worktree at pre-fmt commit 19310f5f.
  2. Build under both profiles: default (200 runs) and production (1000 runs).
  3. Strip the CBOR metadata tail from the artifact bytecode.
  4. Fetch on-chain runtime via cast code.
  5. Strip on-chain metadata tail the same way.
  6. Compare core bytecode and record first-diff character plus size delta.

Forge version 1.5.1-stable. Cast version 1.5.1-stable. RPC: mainnet.base.org with Blockscout v2 fallback. Foundry profile chains both default and production runs over each candidate so optimizer-runs is not a confounding variable.

Pending redeploy from current source

These contracts have current HEAD source available. They will verify on first submission once the redeploy script executes.

KerneFlashArbBot

0x57e73919Efc8a70B40a0bFc562C4DC9e58c4D76F

Deploy

Block 40859589, 2026-01-15 22:22:05 UTC

On-chain runtime

22,616 chars (after metadata strip)

Candidate commits and compiled sizes

CommitDate (UTC)Default profileProduction profile
c533d8282026-01-15 18:0822,30623,780
5f9ca3702026-01-2825,420>= 26,400
d94dae152026-02-0326,656>= 27,500
da51dce02026-02-2726,664>= 27,500

First-diff verdict

built core: ...60806040|52600436105b3f60...
on-chn core: ...60806040|52600436108015b060...
First diff at character 87, location: function dispatch jump table

Verdict

Source modified locally between commit c533d828 (18:08 UTC) and the deploy at 22:22 UTC and never committed. The 4h14m window contains genuine code edits that are not recoverable.

Resolution

RedeployArbSuite.s.sol replaces this address with a fresh deploy from current HEAD. Upon execution, the new KerneFlashArbBot will verify cleanly on first submission.

KerneTreasury (legacy, retired)

0x0067F4957dea17CF76665F6A6585F6a904362106

Deploy

Redeployed 2026-05-16, successor at 0x7c07517ABcc4BD674CC74B76D2Ab0d95A41560d5

On-chain runtime

14,014 chars

Candidate commits and compiled sizes

CommitDate (UTC)Default profileProduction profile
HEADcurrent10,478n/a

First-diff verdict

built core: n/a (size delta is structural, not first-byte)
on-chn core: n/a
removed vault-integration logic and captureFounderWealth path

Verdict

RESOLVED. On-chain version was 3,536 chars larger than current HEAD because source had been slimmed post-deploy. Legacy contract held 0 of every token at retirement.

Resolution

Redeployed 2026-05-16 via scripts/deploy_treasury_v2_trezor.py to 0x7c07517ABcc4BD674CC74B76D2Ab0d95A41560d5. Safe Multisig is sole owner (transfer landed in tx 4 of the deploy). WETH+USDC approved for buyback. Sourcify-verified perfect match. Basescan auto-syncs from Sourcify.

Source not reproducible, evidence published

These contracts cannot be matched to any committed source revision. One was wiped by the 2026-01-07 history reset. One was deployed from a working tree with uncommitted edits during the early launch-prep period.

KerneStaking

0x032Af1631671126A689614c0c957De774b45D582

Deploy

Pre-2026-01-07, deploy timestamp lost in history reset

On-chain runtime

6,372 chars

Candidate commits and compiled sizes

CommitDate (UTC)Default profileProduction profile
c5300bba2026-03-206,0566,368

First-diff verdict

built core: ...c5300bba production build, first diff at char 142
on-chn core: ...on-chain dispatch table
First diff at character 142, location: structural dispatch change, one additional function body present at deploy that was later trimmed

Verdict

Production build lands within 4 chars of the on-chain size, tantalizingly close, but the first-diff at char 142 is a dispatch change, not an immutable. Pre-2026-01-07 commits are destroyed.

Resolution

Staking can in principle be redeployed since position migration is simpler (each staker calls withdraw then deposit on the new contract), but this is a multi-week operator coordination problem. Not on the current launch path. Accepted as permanently unverifiable.

KerneInsuranceFund (legacy, retired)

0x3C93E231a3b74659ABfCA95dFf2eC9a8525b08B9

Deploy

Redeployed 2026-05-16, successor at 0xE8799FCF327C6D2f78103a3c9308C93592A30403

On-chain runtime

7,544 chars

Candidate commits and compiled sizes

CommitDate (UTC)Default profileProduction profile
2eacb83d2026-01-15 19:407,8728,254
e0a8b9102026-01-15 21:057,8728,254
2561f8d22026-02-198,2208,662
d9c1c5ac2026-03-098,7909,230

First-diff verdict

built core: ...6080604052|600436105c6310...
on-chn core: ...6080604052|60043610610092...
First diff at character 74, location: function dispatch jump table, on-chain contract has fewer or simpler public functions than e0a8b910

Verdict

RESOLVED. Source drift between e0a8b910 (21:05 UTC) and the original deploy at 21:50 UTC was unrecoverable from git. Legacy fund held 0 WETH at retirement, so the redeploy migrated zero state.

Resolution

Redeployed 2026-05-16 via scripts/deploy_insurance_v2_trezor.py to 0xE8799FCF327C6D2f78103a3c9308C93592A30403. Safe Multisig is sole admin (DEFAULT_ADMIN_ROLE + MANAGER_ROLE) from tx 5 of the deploy. AUTHORIZED_ROLE intentionally NOT granted to any vault, closing the permissionless-drain primitive flagged in COMPREHENSIVE_AUDIT_2026-05-11. Sourcify-verified perfect match. Basescan auto-syncs from Sourcify.

Retired

Listed for completeness. No funds, no role permissions, no remediation needed.

Previous KUSDPSM

0x7286200Ba4C6Ed5041df55965c484a106F4716FD

Deploy

Block 40727134, 2026-01-12 17:26:55 UTC

On-chain runtime

7,740 chars

Candidate commits and compiled sizes

CommitDate (UTC)Default profileProduction profile
7b093f242026-01-12 22:36 (5h09m AFTER deploy)6,5887,024

First-diff verdict

built core: ...608060|40523415...
on-chn core: ...608060|4052345f8015...
First diff at character 8, location: constructor prologue, entirely different contracts from the second instruction onward

Verdict

Contract was deployed before any version of its source was ever committed to this repository. The 3d136241 Initial commit after reset on 2026-01-07 wiped pre-reset history. Deployed during the 5-day window where the actively-edited working tree was uncommitted.

Resolution

Retired. MINTER_ROLE never granted to this address after kUSD v2 redeploy. totalSupply of any token held = 0. Contract is inert. No remediation possible and none required.

What a reader should take away

  1. The verification gap is real, small, and bounded. 5 of 13 production contracts are currently unverified after the 2026-04-25 KerneToken reconstruction. 2 (Treasury, FlashArbBot) are mid-redeploy. The remaining 2 plus 1 retired are the irreducible unverified set.
  2. The source was not lost because we did not try. Three reconstruction passes were run, including a production-profile sweep that closed the one remaining tuning lever. The build pipeline, archaeology worktree, and bytecode-comparison script are all preserved internally.
  3. The contracts that are unverifiable have a clear reason for being so. One is wiped by the 2026-01-07 history reset. Three were deployed from uncommitted local edits during the early launch-prep period. One pre-dates its own first commit. None were deliberately obscured.
  4. Future deploys will pin a commit hash. Adding a deployCommitHash field to deployments/8453.json and requiring it populated at deploy time means future archaeology becomes a single git-show call.

Source: docs/security/VERIFICATION_GAPS_2026-04-21.md, mirrored here so external reviewers can reach the evidence without repository access. Updated whenever the next reconstruction pass runs.