KERNE Token: Deployed Source vs. Marketing Disclosure

What we found

The KERNE token at 0xfEA3D217F5f2304C8551dc9F5B5169F2c2d87340 was deployed in early January 2026. The source we successfully reproduced and verified on April 25, 2026 is the January 7 version of src/KerneToken.sol. It is not the February 28 rewrite that has been sitting in the public repo and that the published documentation describes.

The two contracts are textually similar but economically distinct. The deployed (January 7) version mints an initial 100,000,000 KERNE and exposes a mint() function gated by MINTER_ROLE. The February 28 rewrite mints a one-time 1,000,000,000 supply and has no minter at all. The on-chain reality, observed at the time of writing, is the former: totalSupply() = 100,000,000 KERNE.

The Kerne 2-of-3 Safe at 0x52d3E450C4B6BD25b73D38b76FA1B4eA77904877 holds DEFAULT_ADMIN_ROLE, meaning any future grant of MINTER_ROLE requires sign-off from two of three independent signers. There is no other path to mint. As of the publication date, no address other than the Safe-controlled admin can authorize new supply.

This is not an exploit, a hidden minter, or a missed private key. The mint authority is multisig-gated and the multisig holders are the named protocol founders. The substantive issue is that the marketing claim of a cryptographically enforced 1B fixed supply does not match the deployed contract, and that gap is now a verified public artifact on three explorers. We are publishing this disclosure so that any external reviewer who reads the verified BaseScan source finds our explanation already linked, rather than discovering the discrepancy without context.

Property-by-property diff

Each row compares the contract that is actually live on Base (left) against the version that had been described in the public docs and the whitepaper (right).

Source verification status

The deployed bytecode (28,608 hex chars after stripping the constructor argument) was reproduced byte-for-byte from the January 7 source at commit 3d136241 under solc 0.8.24+commit.e11b9ed9 with optimizer=true, optimizer_runs=200, evm_version=cancun, and via_ir=true. The only divergence is the 30-byte CBOR metadata trailer (an IPFS hash of the source tree), which does not change runtime semantics. All three explorers now display the verified source publicly.

On-chain confirmation

Anyone can independently reproduce the totalSupply and role assignments using a public Base RPC and BaseScan's read tab. The on-chain values are the canonical source of truth; this disclosure is not asking for trust in our writeup, only that you read the contract.

• totalSupply() returns 100,000,000 * 10¹⁸, equal to 100,000,000 KERNE.
• DEFAULT_ADMIN_ROLE is held by the 2-of-3 Safe at 0x52d3E450C4B6BD25b73D38b76FA1B4eA77904877.
• MINTER_ROLE is currently granted to zero addresses. Use getRoleMemberCount(MINTER_ROLE) on the verified contract to confirm.
• PAUSER_ROLE holders: the legacy deployer EOA was the original holder; the role was revoked at Safe nonce 7 on April 17, 2026 as part of the orphan-role revocation sprint. The Safe is the sole remaining pauser.

Public commitment on minter discipline

To make the deployed reality safe for token-holders even though it is not cryptographically supply-capped, Kerne Labs publicly commits to the following minter discipline. This commitment is binding on the multisig signers and is referenced from the footer of every page on kerne.fi that mentions KERNE supply.

1. No grant outside the Safe. No address other than the 2-of-3 Safe at 0x52d3E450C4B6BD25b73D38b76FA1B4eA77904877 will be granted DEFAULT_ADMIN_ROLE or MINTER_ROLE. Any proposal to do so requires public notice as described below.
2. Thirty-day public notice. Before any newMINTER_ROLEgrant is executed by the Safe, an explicit notice will be published on this page and on the official Kerne X account at least thirty days in advance. The notice will name the proposed grantee, state the intended mint amount, justify the use case, and link the planned Safe transaction. Token-holders can rely on the lack of such a notice as evidence that no grant is imminent.
3. Permanent public log. Every Safe action that touches role membership or supply on the KERNE token will be listed on this page, with the Safe nonce, the executed tx hash, and the rationale. The log is append-only by intent.
4. Path to cryptographic cap. If the protocol redeploys KerneToken to the February 28 source (1B fixed, MINTER_ROLE removed) at a new address, the migration plan will be published in advance on this page along with a token-holder claim contract.

Why the gap exists

The original KerneToken was deployed in early January 2026 from an evolving working copy. After the deploy, the source was rewritten on February 28, 2026 to remove the minter and bake in a 1B cap, with the intent of redeploying. The redeploy never happened, but the documentation and on-chain reality drifted apart. The git history reset on January 7, 2026 (commit 3d136241) destroyed the visibility of the pre-reset source, which contributed to the mismatch going unnoticed during prior audits. The April 25 verification rebuilt the deploy environment exactly and made that history-reset gap moot, because the on-chain bytecode itself reproducibly compiles from the post-reset commit at the correct compiler settings.

Where the 100,000,000 KERNE currently lives

The full deployed supply is currently held by the original deployer EOA at 0x57D400cED462a01Ed51a5De038F204Df49690A99, the same address that was delegated to a drainer contract under EIP-7702 in April 2026 and can no longer sign normal transactions. The supply is, by happenstance, frozen at that address until either the EIP-7702 delegation is unwound or a token migration is executed. No drainer-controlled or attacker-controlled address holds any KERNE at the time of writing, and the multisig retains full admin control of the token contract itself, which means the contract can pause transfers if anything moves.

No KERNE has been distributed to any external party yet. TGE has not occurred. There are no public claims, listings, or trading pairs that depend on the current address being the canonical token, which means the migration cost is bounded.

v2 migration plan: drafted, ready-to-sign

On April 27, 2026 we completed the design and drafting work for the v1-to-v2 migration. The work product is in the public Kerne repository and is reviewable by anyone. None of it has been executed on chain yet, the execution is gated on a future Trezor signing session, but every prerequisite (forensics report, options analysis, v2 contract source, claim adapter source, comprehensive test suite, deploy script, and runbook) is finished and version-controlled. The thirty-day notice commitment described in the previous section is honored by this public disclosure of the plan; the actual on-chain ceremony will not occur sooner than thirty days from the date of this update.

The recommended path is Option E: pause v1, deploy v2, publish a claim adapter. Rationale: pausing v1 converts the soft retirement into a structurally enforced retirement, the trapped 100M cannot move under any future EIP-7702 unwind because the contract refuses every transfer in `_update`. v2 mints the long-stated 1 billion KERNE fixed cap directly to the Safe, with no `MINTER_ROLE` and no `mint()` function, so the supply is cryptographically capped. The claim adapter honors the prior public commitment to publish a balanceOf-at-block claim contract; because the only v1 holder at the snapshot block is the trapped EOA (excluded by hardcoded address check), the adapter accepts the empty Merkle root and has zero claimable supply at deploy. The five Option A through Option E variants were evaluated against five criteria each in the linked recovery-options doc.

The v2 contract adds two narrow EIP-7702 awareness features that do not exist on v1: a public `is7702Delegated(address)` view helper, and a `RecipientHasDelegatedCode` advisory event that fires whenever a transfer settles to an address with the EIP-7702 magic prefix. Neither feature blocks any transfer, they just make 7702-delegated recipients observable to wallets and indexers, so the same trap pattern that affected v1 cannot recur silently on v2.

Reviewable artifacts in the repository:

• On-chain forensics report: docs/security/EIP7702_FORENSICS_REPORT_2026-04-26.md including reproduction commands so any reader can re-run the forensics without trusting our writeup.
• Recovery options analysis: docs/security/KERNE_TOKEN_V2_RECOVERY_OPTIONS_2026-04-26.md with the five-option scoring matrix and the recommended path.
• v2 contract: src/KerneTokenV2.sol. 1B fixed supply, no minter, OpenZeppelin v5, ERC20+Burnable+Pausable+AccessControl+Permit+Votes, EIP-7702 awareness helpers.
• Claim adapter: src/KerneV1ClaimAdapter.sol. Merkle-rooted claim with hardcoded ineligibility for the trapped EOA and the drainer destination, 365-day claim window, admin sweep after deadline.
• Test suite: 47 tests passing across test/unit/KerneTokenV2.t.sol (31 invariant + role + 7702-detection tests) and test/unit/KerneV1ClaimAdapter.t.sol (16 claim + sweep tests including the production-shape empty-root case).
• Deploy script: script/DeployKerneTokenV2.s.sol. One broadcast deploys both v2 and the claim adapter, mints 1B v2 directly to the Safe in the constructor, and logs all metadata to stdout for the operator.
• Migration playbook: docs/runbooks/KERNE_TOKEN_V2_MIGRATION.md. Trezor-ready ceremony in four steps with pre-flight checks, post-deploy verification commands, rollback analysis, and a pre-written replacement copy block for this page.

When the migration executes, this section will be replaced with the executed-migration version, naming the v2 address and linking BaseScan and Sourcify. Until then, the v1 contract at 0xfEA3D217F5f2304C8551dc9F5B5169F2c2d87340 remains the on-chain KERNE token, the trapped 100M remains on the legacy EOA, and the multisig discipline commitments above continue to apply.

What we changed in our public copy

The following pages have been updated to describe the deployed contract accurately. The previous wording used the planned February 28 properties; the corrected wording uses the deployed January 7 properties, with a link back to this disclosure.

• Documentation: The $KERNE Token. The supply paragraph now describes 100,000,000 deployed KERNE with multisig-gated optional inflation, and links here for the full context.
• Transparency. The KerneToken contract row no longer claims "no MINTER_ROLE" and the verification status reflects the successful April 25 reproduction.
• Transparency: Source Verification Audit. KerneToken has moved out of the "reconstruction infeasible" bucket and into the "verified" one.
• Terms of Service. The KERNE token paragraph now describes the deployed supply and minter discipline rather than a cryptographic cap.
• Audit and Security Posture. The April 25 verification entry now links here.