What a $1M park in kUSD actually is.

1. Entry: a mint at the published fee, no permission required

You send USDC to the Peg Stability Module and it sends you kUSD. The function is swapStableForKUSD. It carries no role gate and no whitelist: anyone can call it, including you, without asking us. Minting is enabled and the contract is not paused.

The fee is a tiered ladder set on chain, and it is charged the same way in both directions. These are not modelled rates, they are the literal returns of getFee at four sizes:

A $1,000,000 mint costs $500 and settles in one transaction. Capacity is not a constraint: the USDC cap is 10,000,000 with 30 currently taken, so 9,999,970 of headroom is open right now. We do not quote a flat rate anywhere, because the contract does not charge one.

2. What holds the money, and what it can do with it

Your USDC sits in the module, and every flow is between your own addresses and the deployed contracts. That is not the same as saying nobody can take it, so here is the ceiling rather than the slogan.

With that ceiling stated, here is what the contract itself is able to do with the balance while it sits there.

• There is no yield-deployment egress that outlasts a transaction. No function on the module parks reserve USDC in a strategy, a vault, a lending market or a bridge. That is why the balance earns zero, and it is a property of the code rather than a policy. One function does push the reserve to an arbitrary address, flashLoan, and it is covered below. Every other transfer out of this contract is a redemption to the caller or a fee skim to the treasury.
• The module grants no allowances. approve and allowance do not appear anywhere in its deployed runtime, so the reserve cannot be pulled by an allowance, and it has no ERC-1271 or fallback either, so a signature-based permit cannot authorise a pull round the back. It can still be pushed: a flash loan sends it to a caller-chosen address for one transaction, and swapKUSDForStableTo sends it to a caller-chosen address against kUSD. The absence of approve closes one mechanism, not every mechanism. We checked this with a method that correctly finds the selectors that are there (transfer, transferFrom, mint, burn), because a naive scan misses left-aligned call selectors and would have produced a confident false negative. The sharper control: run the identical scan against Kerne's own v2 vault and it does find approve. So the absence on this module is a real difference between two contracts, not an artifact of how we looked.
• The code cannot be changed. The runtime contains zero DELEGATECALL, zero CREATE, zero CREATE2 and zero SELFDESTRUCT. It is not a proxy, and what is deployed there is what runs. Two things that does not mean. It does not mean the arrangement cannot change: the upgrade path for this system is deploying a new module and moving the mint role, which is exactly what we did on July 10, 2026, and the backing stayed behind in the old one. It does not mean the asset is immutable either, because USDC is itself an upgradeable proxy with a third-party blacklister. And note the scope: the properties in this section were verified against the live module, which is a different build from the retired one holding most of the backing, 11,376 bytes against 11,247.
• The admin can skim accrued fees, and the admin also sets what counts as a fee. skimSurplus sends fee revenue to the treasury, callable only by the Safe, and we say that on the basis section 6 demands, a full replay of role events on the module rather than a hasRole call against addresses we chose to check. It is bounded by skimmableSurplus, the lesser of the fee ledger and the balance above net backing. Nobody can inflate that ledger with a donation, and backing cannot be pulled through it. Two things to price anyway. First, your own mint fills it: a $1,000,000 entry pays $500 of fee and raises the ceiling from $0.03 to $500.03 in the same transaction, so the ceiling is a function of your deposit, not a small constant. Second, the rate is a parameter, not a promise: setTieredFees accepts up to 500 bps with no timelock, so the same two signatures can raise your exit fee after you have entered and convert up to 5 percent of your principal into skimmable "fees". A covenant in a signed letter not to worsen your redemption tier is the only thing that closes this, and it is contractual rather than on chain. Note also that the retired module runs its own spigot with $0.998 skimmable to a different treasury address, so the honest system-wide figure today is $1.028, not $0.03.
• The second exception, which you would find in the ABI anyway: the reserve is flash-loanable. The module implements ERC-3156. flashLoan is permissionless, the fee is currently zero, and maxFlashLoan returns the entire balance. Repayment is genuinely enforced: the loan must be repaid inside the same transaction or the whole call reverts, so a flash loan cannot leave the reserve short at the end of a block. That is a statement about flash loans, not a guarantee that the reserve is always full; the box above and section 3 cover the things that can actually empty it. Two further disclosures on the fee. A zero fee means your principal is free flash liquidity for any contract on Base and you are not paid for it, and when the fee is switched on it accrues to the treasury rather than to kUSD holders. And flashFee returns zero unconditionally for holders of an ARBITRAGEUR_ROLE, which is a private fee-exemption primitive sitting in deployed code. Nobody holds it today, confirmed by replaying every role event on the module. We disclose it because we publish a "no private exemptions" line elsewhere, and a primitive that could quietly contradict it should be named by us rather than found by you.

3. Exit, and the reconciliation you would otherwise fail us on

Redemption is swapKUSDForStable. Like the mint, it carries no role gate, so no address is whitelisted and none is excluded. You get par, less the same tiered fee charged on the way in. Symmetric means the same ladder both directions, not free.

It is not unstoppable, and we are not going to imply it is. Every swap path carries whenNotPaused, and pause() is a single MANAGER_ROLE call held by the same 2-of-3 Safe, with no timelock. The switch is asymmetric: unpause() requires the admin role. So two signatures can halt redemption instantly and keep it halted. Quieter versions are not gated any harder: setOracle accepts any address, setSolvencyCheckDisabled(false) re-arms a gate that is switched off today, and setMaxDepegBps can narrow the band until ordinary prices fall outside it. You do not need our permission to leave. You do need us not to close the door.

Here is the part a five minute diligence pass finds and reads as insolvency. The live mint module holds thirty dollars. Most of the backing sits in a different, retired module:

That reconciles, and it reconciles in our favour rather than against us. Total USDC across the three modules is 1,113.885006. kUSD outstanding is supply less the inventory held at all three modules, which today is only the 32 sitting at the redeem reserve, so 1,112.707154. Backing is 100.11 percent. Nothing is missing. The backing simply did not move when the mint role did, because moving it would have been an unnecessary transaction with real risk attached.

Read that definition carefully, because the one-module version of it breaks the first time anyone uses the exit described below. The retired module does not burn what it redeems. Its runtime contains no burn call, unlike the live module, so kUSD redeemed there parks on its balance as inventory and totalSupply does not move. If you subtracted inventory at only one module, a single legitimate $998 redemption would make this page's own backing figure read about 10 percent. Subtract inventory wherever it sits and the ratio stays honest. We are pointing at this because it is the kind of formula that looks fine until it is used once.

The operational consequence is the number that matters to you, and it is the reason this section exists rather than a line in a footnote: each module pays only from its own reserve, so the deepest single-transaction exit today is $998.00, against the retired module. Reaching all $1,113.89 requires sequential transactions against three different addresses. At current book size an anchor cannot exit a meaningful position instantly, and no amount of framing changes that. What fixes it is the reserve growing, which is the same thing an anchor mint does.

That $998.00 is measured, not inferred from a balance. Simulating a redemption against the retired module at 998 kUSD clears every gate and stops only because the simulated caller has not approved its kUSD. The same simulation at 999 kUSD reverts InsufficientStableReserves. The boundary is exactly where the reserve says it is, and section 8 gives you both commands so you can watch it move as the reserve changes.

4. What can stop the door, in both directions

Four things can revert a swap, and each gates redemption exactly as it gates minting. A gate that protects the reserve is also a gate that can delay your exit, and you should price both halves. Two are market conditions, below. The other two are operator controlled: the pause switch covered in section 3, and a solvency check which is currently switched off but which the Safe can re-arm at any time with no timelock. If you price only the market gates you have mispriced your exit.

• Oracle staleness. The module reads Chainlink USDC/USD and reverts if the price is older than its configured window. The window is 93,600 seconds, which is 26 hours. That feed is a 24 hour heartbeat whose worst observed gap across fifteen consecutive rounds was 24.008 hours, so the margin in the worst case is about 1.99 hours. At the snapshot block the price was 13.97 hours old. If the feed ever misses its heartbeat by more than roughly two hours, minting and redemption both revert until it updates. A Safe transaction widening this window to 48 hours is signed and queued but has not been executed, so 26 hours is the number in force.
• Depeg band. If USDC itself deviates more than 2 percent from a dollar, both directions halt. This protects the reserve from being drained at a bad price and equally prevents you from redeeming during that window.

5. What it earns

Parked, nothing. kUSD pays no yield for holding it, and the reserve backing it is not deployed. Repeating the top of this page because it is the single most important thing on it: a million dollars minted and held earns zero percent.

There is a separate staking receipt, skUSD, and it is open: you can stake kUSD and redeem instantly, with no cooldown. We are not going to present that as the answer, because the honest record is that exactly one yield distribution has ever reached it in its entire life, of 0.1 kUSD, in July 2026. An incentive that had been advertised on top of it was withdrawn on August 1, 2026 when we established that no mechanism existed to pay it. The realistic carry this strategy can produce, at maximum leverage with zero cost, is under 8 percent, which is not a market-beating number and we are not going to pretend otherwise.

The disclosure an allocator should weigh most heavily is who else is here, so here is the entire holder set, replayed from every kUSD transfer since the token was created. There are 27 transfers in its whole history and seven holders:

• 1,011.58 sits inside the staking contract, and every share of it belongs to one wallet, ours.
• 84.99 sits in our own founder wallet. It was protocol-seeded liquidity in an Aerodrome pool until we withdrew that position on August 1, 2026, which moved the kUSD out of the pool contract and into the wallet. It has never been sold and the withdrawal minted and burned nothing.
• 32.00 is inventory in our own superseded redeem reserve.
• 10.09 sits in our retired staking contract, and it is not ours. Every share of it belongs to a single external wallet that is not any Kerne operational address, which bought roughly 9.99 kUSD through the module with its own USDC in June 2026 and staked it. It can redeem at will and we cannot touch it.
• 5.98 is what is left in that Aerodrome pool after the withdrawal. The pool has recorded zero buys and zero sells since it was funded.
• 0.0065 is our own operations bot.
• That leaves two external wallets holding 10.145055 kUSD between them.

So third-party demand for kUSD today is about ten dollars, across two wallets, or 0.91 percent of outstanding. One of those two arrived by buying through the module with its own money rather than by receiving a transfer from us, which is the only piece of genuine external demand this protocol has. You would not be joining a book. At $1,000,000 you would be more than 99 percent of it. Whether that is an opportunity or a disqualification is your call, but it should not be a surprise you discover after signing.

6. Who can change things, and how fast

Administration sits with a 2-of-3 Safe on Base at 0x52d3E450bA6c299B1B07298F1E87DD74732D4877, with the first signer hardware-backed.

• There is no timelock, no guard and no modules. The Safe's guard slot is zero and getModulesPaginated returns empty. So there is no enforced delay between two signatures and an executed change, and no scope restriction on what those signatures can do. There is no window in which an administrative action could be observed and reacted to before it lands.
• How fast, measured. This section is headed "and how fast", so here is the number rather than an assurance. Across all 19 transactions the Safe has executed, proposal to second signature ran to a median of 12 minutes and a maximum of 25 days, with 14 of 19 inside 24 hours; execution follows the second signature by a median of 8 minutes. Read that in both directions. It is how quickly we can respond to a problem, and it is equally how little warning you would have. The full distribution, the pending queue decoded from its calldata, and the commands to reproduce every figure are on the Safe queue page. It describes past behaviour and is not a service level.
• kUSD mint authority sits behind those same two signatures. The Safe holds DEFAULT_ADMIN_ROLE on kUSD, and getRoleAdmin(MINTER_ROLE) is zero, so the Safe can grant the minting role to anything at any time, immediately. Today the role is held by two contracts: the live mint module and 0x8ccc56B5624e2FDB592F6609d81F4c3798e3292B, the v2 vault. A transaction revoking the vault's role is signed and queued and has not executed, so the correct statement today is two holders, not one. The vault cannot actually mint (its deployed runtime contains no kUSD address and no mint selector), so this is a stale grant rather than an open route, but a stale grant is still a grant and you should price it as one.
• There is a second route to the same outcome that does not touch kUSD's admin role at all. The mint module at 0xaBDE1138aa1Ce88d1dF06422C0c3b05D70569803 already holds MINTER_ROLE, because minting against deposited collateral is its job. The Safe holds MANAGER_ROLE on that module, and MANAGER_ROLE is what gates listing a new collateral asset and choosing the price feed that values it. Those two levers, used together, reach the same place as granting yourself the minting role, without ever calling grantRole on the token. We verified this against a fork of Base rather than reasoning about it from source. We are publishing it because we were preparing a remediation that would have moved kUSD's admin role behind a delay and left this route untouched, which would have looked like a fix and would not have been one. Any delay worth the name has to cover both. The revised design does, and it is designed and fork-tested, not deployed and not proposed. Until it is executed, price this page on the position described above and not on the intention.
• The deployed kUSD has no burn role, and our published source does. burnFrom on the live token carries no role gate. Our repository restricts it to a BURNER_ROLE as a May 2026 audit fix, and that version is not what is deployed: BURNER_ROLE() reverts on the live token, the UnauthorizedBurner selector is absent from its runtime, and a call from an unrelated address fails only on allowance. Two consequences for you. Any address you grant an ERC-20 allowance over your kUSD can burn it, not merely spend it, so approve nothing you would not hand the tokens to outright. And our published source is not a safe proxy for the deployed token, so diligence should be run against bytecode. This is the single finding on this page we would most have preferred not to write.
• The deploy key was handed off and revoked, and you can watch it happen. The module was bootstrapped with the founder's own wallet holding both admin and manager, which is normal and would be a real finding if it had been left that way. It was not. Replaying role events on the module gives four grants and two revocations, and the two revocations both strip the founder's wallet, leaving the Safe as the only holder of either role. Live hasRole for that wallet returns false on both, and it returns false on all three modules, with the Safe holding admin on all three. So the fee skim and every parameter really do need two signatures, not one. This is the one part of the governance picture that is unambiguously good, which is why it is stated alongside the parts that are not.
• You cannot enumerate the minter set in one call. kUSD uses plain AccessControl, so getRoleMemberCount is absent and reverts. hasRole only answers for an address you already name. Proving the set is exactly two requires replaying role events from the creation block, and the command for that is below. We mention it because a terms document that told you to "verify it in one call" would be telling you to run something that does not work.

We publish this because you would find it, and finding it yourself after reading a terms page that omitted it is worse for us than writing it down. It is a real weakness of the current setup, not a rhetorical one.

7. What a signed letter adds on top of the above

Everything in sections 1 to 6 is true for anyone who mints, with or without a relationship with us. It is the deployed system, and you should verify it rather than accept it. A signed anchor letter adds contractual protections around that deposit: a points multiplier floor, fee rebates bounded by fees actually collected, a covenant not to worsen the fee tier applicable to your redemption, priority of access if a capped founding window is ever opened, and a named transparency page scoped to your position.

The points floor is the one term already published as a rule in its own right, at the Opal anchor tier rules, so an executed letter rests on published terms rather than on its own words. Points are not yield, carry no guaranteed value, and no token generation event is scheduled.

To be explicit about what the date does and does not bind: it bounds the Opal points window only. It is not a deadline on this document, not a fee change, and not a deadline on the letter, which is with counsel. Nothing about a deposit made after it is worse except the points, and nothing on this page is an offer or a solicitation.

Two things you should know before asking for the letter. First, the counterparty: no Kerne legal entity is incorporated or in formation. You would contract with the founder in his individual capacity as founder and promoter, with a mandatory novation to the first incorporated entity. Second, the letter is currently with offshore counsel and is marked not for execution, so it is a draft under review and not a document we can hand you to sign today. Terms are discussed directly at liam@kerne.fi.

Anchor terms version 1.0, issued August 1, 2026, figures read at Base block 49,428,145. This page is a description of a deployed system and of terms under negotiation. It is not an offer to sell or a solicitation to buy any token or security, and it is not investment, legal, tax or accounting advice. Kerne is infrastructure, not a custodian or an investment adviser, and does not take custody of your USDC or kUSD at any point. kUSD is a protocol-issued synthetic dollar, not a fiat-backed payment stablecoin, and is not a bank deposit and not insured. kUSD pays no yield for holding it. Opal fragments are a points balance, not a token, a price, or a yield promise. Where this page and the executed anchor deposit letter conflict, the letter controls. Where this page and the chain conflict, the chain controls.