Security Disclosure
KERNE Token: Deployed Source vs. Marketing Disclosure
Published April 26, 2026
During the April 25, 2026 source verification of the KERNE token, we found a meaningful drift between what the deployed contract does and what the published documentation claimed. This page describes the gap, the reconciled facts, and the public commitments that follow from it.
Update, June 7, 2026: Migration Executed
KerneToken v2 is live. v1 is retired.
The migration described below as planned is now complete. The canonical KERNE token is 0x230f3a63E8413D42bEe9103b98a204030206186c, deployed June 7, 2026 with a one-time fixed supply of 1,000,000,000 KERNE minted directly to the 2-of-3 Safe. The v2 contract has no MINTER_ROLE and no mint() function; the cap is cryptographic. It is Sourcify-verified with a full creation and runtime match. The retired v1 at 0xfEA3D217F5f2304C8551dc9F5B5169F2c2d87340 remains on chain for history only and is no longer canonical.
The procedural claim adapter committed to below is live at 0x59719233590777b83112053CD036a54F8EFf15eC. Because the only v1 holder at the snapshot block is the excluded EIP-7702-trapped legacy EOA, the adapter's current claimable supply is zero. The claim window remains open for 365 days.
Update, August 1, 2026
What an Opal Fragment is, and what it depends on
Kerne publishes an Opal Fragment balance on /opal and app.kerne.fi/rewards, and states that fragments convert to a share of the 5,000,000 KERNE community tranche, one of the two tranches of a fixed 50,000,000 KERNE allocation. That is a real commitment and we are not withdrawing it. It also has dependencies that were not written down anywhere, and a reader deciding what a fragment is worth needs all four of them.
1. A fragment is a points balance, not a token
Fragments accrue off chain, in Kerne's own database, at 100 per kUSD per hour multiplied by a deposit-cohort multiplier. They are not an ERC-20, they are not transferable, and they do not exist on Base. Nothing about a fragment is enforced by a contract. The accrual is real and it runs hourly; what it writes to is a ledger we control.
2. The KERNE token exists. The Opal pool does not exist separately from it
KERNE v2 is deployed, fixed at 1,000,000,000, and has no minter, as set out above. But the 2-of-3 Safe holds 100% of that supply as one undivided balance. There is no escrow contract, no vesting contract, and no segregated address holding 50,000,000 KERNE for Opal. The allocation is a published policy commitment over a treasury balance, not an on-chain earmark, and you should read it as exactly that. Anyone can check: call balanceOf on the token for the Safe address and compare it to totalSupply.
3. No contract converts a fragment into KERNE, and no distribution is scheduled
The only claim contract Kerne has deployed is the v1 to v2 migration adapter described above. It is unrelated to Opal, its merkle root is immutable and unset, and it holds zero KERNE. No Opal claim contract has been written or deployed. No token generation event has been scheduled, announced, or dated. If no distribution ever happens, fragments convert to nothing. We would rather write that sentence ourselves than have a reader derive it.
4. Almost all fragments outstanding are held by Kerne, and none of them convert
A share of a pool is only meaningful against its denominator, and ours is concentrated. The live standings, read from the same public endpoint the leaderboard uses, are below. The founder wallet and the protocol bot are labelled as such on the public leaderboard and have never been hidden, but the resulting percentage was not stated in words anywhere until August 1. Applied literally, the published formula sends most of the pool to Kerne's own wallet. On August 4, 2026 we adopted the insider-exclusion rule this page promised, and it is set out in full immediately below. The table now shows both numbers: what each wallet holds, and what each wallet converts.
| Holder | Fragments | Share of fragments | Converts to KERNE |
|---|---|---|---|
| Founder 0x14f04ce0...993946 | 237,183,395 | 97.76% | No, excluded |
| Protocol Bot 0x09a2780a...9ca37e | 3,118,006 | 1.29% | No, excluded |
| External wallet 0xe7a9d4de...e97335 | 2,304,062 | 0.95% | Yes |
| External wallet 0xab502ad7...9cebe8 | 16,655 | 0.01% | Yes |
| Kerne-held, excluded from conversion | 240,301,401 | 99.04% | 0 KERNE |
| Eligible, and the denominator the community tranche divides across | 2,320,717 | 0.96% | 5,000,000 KERNE |
Read live from the public Opal leaderboard endpoint, the same source the leaderboard page uses, and it needs no wallet to read. The third column is each wallet's share of fragments outstanding. The fourth applies the exclusion rule: the 5,000,000 KERNE community tranche divides across the eligible row only. The other 45,000,000 KERNE is the scale tranche and is not divided by fragments at all, so it does not appear in this table.
Adopted August 4, 2026
The Opal insider-exclusion rule
Kerne's own wallets no longer convert Opal Fragments into KERNE. The rule takes effect for the August 19, 2026 at 19:59 UTC snapshot and every snapshot after it.
Who is excluded
The founder wallet and the protocol bot: the two wallets the public leaderboard already labels as Kerne's own. They are identified by address, and independently by that label, so a wallet that ever renders as an insider on the board is excluded here even if someone forgets to add its address.
What exclusion means
Excluded wallets keep accruing fragments and keep their leaderboard rank. What they lose is the claim: their fragments are removed from the denominator, and the 5,000,000 KERNE community tranche divides pro rata across eligible fragments only. We chose to leave accrual alone rather than stop crediting those wallets, because deleting them from a published history would be a second problem rather than a fix for the first.
What this rule cannot do
It is a list of two addresses, not a test of who controls a wallet. Nothing in the points system can tell that a wallet belongs to us, so the rule stops the two wallets it names and nothing else. Kerne could accrue from a fresh address the list has never heard of, and the code would treat that address as an outside participant. So the rule is only worth the commitment attached to it, and the commitment is this: any wallet Kerne controls that appears on the Opal leaderboard will be added to the excluded list, and published here, before the next snapshot it affects. That is the same promise, on the same terms, as the one that produced this rule. It is checkable after the fact against the public board and this page, which is the only kind of assurance we can honestly offer here.
A defect we found while writing this, and did not paper over
Checking the standings for this rule turned up a bug in our own accrual. Fragments are credited for staked positions by reading one staking-vault address. When that vault was redeployed on July 3, the address was repointed and nothing was left pointing at the old one, so a wallet still staked in the old vault read as a zero balance, which our code could not tell apart from a withdrawal. It recorded an exit. The effect on the one external wallet in that position was that its fragments stopped growing entirely on July 3 and it lost its early-deposit multiplier, while our own wallets kept accruing every hour. The accrual fix ships with this rule and credits that position again from now on. It is not retroactive: the roughly one month that wallet lost is not being back-credited, because editing a live points ledger by hand this close to a snapshot is a worse risk than the shortfall itself. We would rather publish that sentence than quietly adjust a number and hope nobody diffed it.
What it does not change
It does not create a distribution. Everything in points 1 through 3 above still holds: no conversion contract exists, no token generation event is scheduled, and if no distribution ever happens then fragments, eligible or otherwise, convert to nothing. Excluding insiders makes the pool a real community pool if it is ever distributed. It does not make distribution more likely, and we are not implying that it does.
The Opal allocation split, and the arithmetic that forced it
Excluding our own wallets was right and it created a second problem. It cut the eligible denominator by about ninety-five times, to roughly two million fragments held by two wallets holding about ten dollars between them. A pro-rata share of a fixed pool cannot exceed all of it, so against a denominator that small the arithmetic saturates. On our own published numbers, read from the same endpoint the panel below uses, on August 6, 2026: about sixty dollars deposited took half the allocation, about five hundred and fifty took ninety percent, and a million dollars took 99.99 percent. The last $999,456 of that million bought roughly eleven percent more than the first $544 already had.
Anyone with a calculator and this website could work that out in ten minutes, and it says something we did not intend to say: that the rational deposit into Kerne is a few hundred dollars, and that the August 19 snapshot is a deadline with nothing behind it. So here is the change, and here is what it costs the people already holding fragments.
The split
The fixed 50,000,000 KERNE allocation is divided in two. The total does not change, no new tokens are created, and nothing is taken from any other allocation. 5,000,000 KERNE is the community tranche, divided pro rata by eligible fragments under the rule above, with no minimum position and with every multiplier, bonus and quest grant counting exactly as before. 45,000,000 KERNE is the scale tranche, divided pro rata by qualifying dollar-hours: for each hour, the part of a wallet's kUSD-equivalent position above $100,000. No multiplier of any kind applies to the scale tranche, including the anchor floor.
The floor is a deductible, not a cliff
Only the part of a position above $100,000 earns scale credit, so nothing jumps at the boundary: a position one dollar over the floor earns one dollar-hour per hour, not a hundred thousand. Splitting a position across wallets can therefore never manufacture qualifying exposure, and no wallet is excluded from the program by the floor. Everyone keeps an unimpaired claim on the community tranche, and accrual still has no minimum.
An unclaimed scale tranche is not redistributed
No position has ever cleared the floor. Total kUSD in existence is under two thousand dollars, which is a public on-chain read, so today the qualifying total is zero. If it is still zero at a distribution, that tranche is simply not allocated. It does not fall back into the community tranche. We state that plainly because the alternative would make the rule cosmetic: a tranche that rolls back to everyone is a tranche a reader can discount to zero, and the arithmetic above would be unchanged.
Why dollar-hours rather than fragments, and why that is checkable
Fragments carry multipliers, and our multiplier attaches to when a continuous hold started rather than to its size, so one dollar held today locks the current cohort rate on a much larger balance added later. That is a real gap and we are not going to fix it inside the accrual engine days before a snapshot. Measuring the scale tranche in unmultiplied dollar-hours removes the entire multiplier surface from the tranche that carries ninety percent of the allocation instead. It also makes that tranche independently verifiable, which fragments are not: our terms say in as many words that fragment balances are off-chain and not independently verifiable, whereas kUSD balances come from public Transfer events and vault share prices are public reads, so a holder can recompute their own qualifying dollar-hours and ours.
What it costs the people already holding fragments
Every existing fragment holder now claims a share of 5,000,000 KERNE rather than of 50,000,000, so the maximum any current holder can claim falls by a factor of ten. That is the honest description and there is no version of this change that avoids it. It is also the second unilateral change to this program in three days, and a reader is entitled to weigh that against everything else on this page. What we can offer against it is the discipline: both changes were published in full, with the arithmetic that forced them, before the first snapshot either one affects, and no fragment already credited to anyone has been altered, reset or clawed back.
What this rule cannot do
It has no more Sybil resistance than the exclusion rule above. Nothing in the points system can tell that a wallet belongs to us, so we could in principle fund a fresh address past the floor and claim the scale tranche ourselves. The commitment is the same one, on the same terms: any wallet Kerne controls that qualifies will be added to the excluded list and published here before the next snapshot it affects. One thing does make this more checkable than the fragment side. A qualifying position has to be more than a hundred thousand dollars of real kUSD on Base, so it has to be minted through the PSM and its funding is visible on chain, and anyone can ask where it came from. We will publish the address and the qualifying dollar-hours of any position that clears the floor, on this page, before the snapshot it counts toward.
The quest grants, capped the same day
Two one-time quest grants of 1,000,000 fragments each ran with no minimum position of any kind: one wei of kUSD in a referred wallet, or one wei of a staked position held a week, earned a grant. Against the post-exclusion denominator that was worth more than most real deposits, and it was repeatable across fresh wallets at no cost. Both grants are now 250,000 fragments and both require a position of at least 100 kUSD. Grants already awarded were not reduced or clawed back. Quest grants have never been able to touch the scale tranche, which carries no grants, boosts or multipliers at all.
What a deposit earns by the snapshot
Read this first: no token generation event is scheduled, no contract that converts a fragment into KERNE has been written or deployed, and if no distribution ever happens these fragments convert to nothing. What follows is arithmetic on a published formula, not a promise of value, and not an offer of a security.
Resolving the time remaining.
The allocation is fixed at 50,000,000 KERNE, split since August 6, 2026 into a 5,000,000 community tranche divided by fragments and a 45,000,000 scale tranche divided by dollar-hours above $100,000. Kerne does not publish a KERNE price and there is no market to derive one from, so this panel deliberately shows a token count and never a dollar value. Why the split exists, with the arithmetic that forced it.
Standings read live from https://app.kerne.fi/api/opal/leaderboard?pageSize=100, which is public and needs no wallet. Recompute this yourself rather than taking our arithmetic on trust.
None of the above changes anything about kUSD. kUSD is redeemable 1:1 through the PSM and its backing is published hourly in the signed proof of reserves. The dependency described here attaches to the points program only.
Canonical totalSupply
1,000,000,000
KERNE v2 at 0x230f3a63, fixed. Retired v1 held 100,000,000.
Source verification
Verified
BaseScan, Sourcify, Blockscout
Mint authority
None exists
v2 has no MINTER_ROLE and no mint(). The cap is cryptographic.
Supply custody
2-of-3 Safe
Holds 100% of canonical KERNE. Verified 2026-07-28.
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 on April 25, 2026 was the former: totalSupply() = 100,000,000 KERNE.
That is no longer the live state, and everything from here to the migration section describes April 2026 rather than today. On June 7, 2026 the February 28 rewrite was deployed as KERNE v2 and became canonical. Read against Base mainnet on July 28, 2026, v2 at 0x230f3a63 returns a totalSupply() of 1,000,000,000 KERNE, all of it held by the 2-of-3 Safe, and the contract exposes no minter to grant. The retired v1 keeps its 100,000,000 on the trapped EOA. This page is kept as the record of what was found and what was done about it, not as a description of the current token.
The Kerne 2-of-3 Safe at 0x52d3E450bA6c299B1B07298F1E87DD74732D4877 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 this page's April 26, 2026 publication date, no address other than the Safe-controlled admin could authorize new supply on v1. On the canonical v2 token no address can, including the Safe: there is no minter to grant.
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).
| Property | Deployed (January 7 source) | Documented (February 28 rewrite) |
|---|---|---|
| Initial mint | 100,000,000 KERNE | 1,000,000,000 KERNE |
| MINTER_ROLE | Present, grantable by DEFAULT_ADMIN_ROLE (the 2-of-3 Safe) | Removed |
| mint() function | Present, callable by any address that holds MINTER_ROLE | Removed |
| MAX_SUPPLY constant | Not present | 1,000,000,000 * 10**18 |
| Supply cap enforcement | Discretionary, gated by 2-of-3 Safe approval of any MINTER_ROLE grant | Cryptographic, no minter exists |
| On-chain totalSupply | 100,000,000 KERNE (retired v1, still readable at 0xfEA3D217) | 1,000,000,000 KERNE, live since 2026-06-07 at 0x230f3a63 |
| Supply custody today | 100% on the EIP-7702-trapped legacy deployer EOA | 100% held by the 2-of-3 Safe at 0x52d3E450 |
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.
| Explorer | Status | Match type | Public link |
|---|---|---|---|
| Etherscan-V2 / BaseScan | Verified | Full match | https://basescan.org/address/0xfEA3D217F5f2304C8551dc9F5B5169F2c2d87340#code |
| Sourcify | Verified | Partial match (CBOR metadata trailer) | https://repo.sourcify.dev/contracts/partial_match/8453/0xfEA3D217F5f2304C8551dc9F5B5169F2c2d87340/ |
| Blockscout | Verified | Partial match (auto-pulled) | https://base.blockscout.com/address/0xfEA3D217F5f2304C8551dc9F5B5169F2c2d87340?tab=contract |
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. The readings below are for the RETIRED v1 token at 0xfEA3D217F5f2304C8551dc9F5B5169F2c2d87340, which is what this disclosure is about. For the canonical token, call the same functions on 0x230f3a63E8413D42bEe9103b98a204030206186c: totalSupply() returns 1,000,000,000 * 1018, balanceOf(the Safe) returns the same figure, and there is no MINTER_ROLE to query.
totalSupply()returns 100,000,000 * 1018, equal to 100,000,000 KERNE.DEFAULT_ADMIN_ROLEis held by the 2-of-3 Safe at 0x52d3E450bA6c299B1B07298F1E87DD74732D4877.MINTER_ROLEis currently granted to zero addresses. UsegetRoleMemberCount(MINTER_ROLE)on the verified contract to confirm.PAUSER_ROLEholders: 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 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.
- No grant outside the Safe. No address other than the 2-of-3 Safe at 0x52d3E450bA6c299B1B07298F1E87DD74732D4877 will be granted
DEFAULT_ADMIN_ROLEorMINTER_ROLE. Any proposal to do so requires public notice as described below. - Thirty-day public notice. Before any new
MINTER_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. - 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.
- 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.
Action log
No MINTER_ROLE grant has been proposed or executed. The role membership count is zero. This entry will be the first edit if that ever changes.
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 retired v1 supply sits, and where the canonical supply sits
Canonical KERNE, read July 28, 2026: all 1,000,000,000 KERNE of the v2 token at 0x230f3a63E8413D42bEe9103b98a204030206186c are held by the 2-of-3 Safe at 0x52d3E450bA6c299B1B07298F1E87DD74732D4877, which is 100.0000% of supply. No KERNE sits on a compromised address. The paragraph below is about the RETIRED v1 token and describes a situation that has not applied to the canonical token since June 7, 2026.
Retired v1: its 100,000,000 supply is 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. That supply is frozen at that address, and it is a retired token: the migration this page proposed was executed on June 7, 2026, so the trapped balance no longer represents the protocol's governance supply. No drainer-controlled or attacker-controlled address holds any KERNE of either version, and the multisig retains full admin control of the v1 contract, which means it can pause transfers if anything moves.
No KERNE has been distributed to any external party. TGE has not occurred. There are no public claims, listings, or trading pairs on either token, which is what kept the migration cost bounded when it was executed.
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.mdincluding 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.mdwith 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) andtest/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.
The full internal verification document, including the reproduction steps, is summarised on the Audit and Security Posture page. Vulnerability reports go through the Bug Bounty Program. The live risk surface is on the Transparency page.
This page will be updated whenever a Safe action touches role membership or supply on the KERNE token, and whenever the minter discipline commitment changes.