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. /dossier/capacity executes that claim rather than stating it: a fork test mints one million USDC through the deployed bytecode and asserts that one USDC past the headroom reverts.

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, so the same two signatures can still raise your exit fee after you have entered and convert up to 5 percent of your principal into skimmable "fees". Since 2026-08-06 that call is MANAGER_ROLE held by the timelock, so it has to be scheduled in public and sits visible for 48 hours first. That gives you notice, not protection: nobody outside the Safe can cancel it, so the delay is time to redeem rather than a veto. A covenant in a signed letter not to worsen your redemption tier is the only thing that closes it outright, 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. Since 2026-08-06 the Safe no longer holds MANAGER_ROLE on the modules directly. It reaches pause() through a PauseGuardian at 0xC47adaf51907bB1871D07E18eA21dc75Ae93Cc8E, a contract whose only function is pause(module) and which refuses any caller except the Safe. That is still a single transaction with no delay, so two signatures can still halt redemption instantly.

The switch is asymmetric, and more so than before. unpause() requires the admin role, which now sits behind the 48 hour timelock, so restarting a paused module takes two days. We publish that as a property rather than a caveat: fast to stop, slow to restart. It removes our own ability to pause an exit and then quietly resume once we have done whatever we paused for. The quieter levers moved the same way and are no longer instant: setOracle, setSolvencyCheckDisabled(false) and setMaxDepegBps each now have to be scheduled in public and sit visible for 48 hours before they can land. You do not need our permission to leave. You do need us not to close the door, and closing it is the one move we can still make without notice.

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. At the snapshot block above (49,428,145, August 1, 2026), total USDC across the three modules was 1,113.885006. kUSD outstanding is supply less the inventory held at all three modules, which at that point was only the 32 sitting at the redeem reserve, so 1,112.707154. Backing was 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.

Those are stamped readings, not live ones. On 2026-08-03 a 3 kUSD redemption executed against the retired module, so the figures on each side are now about three dollars lower and the backing ratio is unchanged. The live values are served at kerne.fi/api/stats, and the figures below carry the same August 1, 2026 stamp.

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 measured at the snapshot block above was $998.00, against the retired module. Reaching all $1,113.89 required 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.

Now the half of that truth we had been leaving out, because stating only the first half answers your question wrongly. Every figure above describes the exit of somebody who did not mint. It is the right figure for a holder who bought kUSD from a third party and wants out. It is the wrong figure for you, because an anchor mint is not a claim on the reserve above. It is a deposit into the module you would redeem against, and it lands there in the same transaction that issues your kUSD.

We simulated it rather than argued it, against real deployed bytecode on a fork of Base at block 49,493,576. The three legs stood at 30.000000, 85.885006 and 998.000000 USDC. A 1,000,000.000000 USDC mint moved the live mint module from 30.000000 to 1,000,030.000000 and returned 999,500.000000 kUSD, the 500.00 difference being the 5 bps tier. Then all 999,500 kUSD redeemed in a single transaction, 155,816 gas, for 998,800.350000 USDC, and totalSupply returned to its 1,144.707154 baseline exactly, so the kUSD was burned rather than parked. No queue, no tranches, no second address. The module the swap router selects for that redemption is the smallest leg that fully covers it, which after the mint is the module holding your own money.

The rate is one for one. The round trip is not free, and the first fact must not be allowed to stand in for the second. The trip above cost 1,199.65, being 500.00 in at 5 bps and 699.65 out at 7 bps, both from the same published ladder. The redemption prices one tier cheaper than the mint for the mundane reason that 999,500 is below the 1,000,000 threshold, so the exit tier is set by what you redeem rather than by what you minted. Call it about 12 bps all in, and price it before you enter rather than after.

What this does not fix, stated in the same breath. It does not give a non-minting holder one dollar more depth than the figure above. It does not touch the pause switch in section 4, which stops redemption without stopping the clock on you. It does not touch the mint authority in section 6, which is the reason your reserve sitting in the module is not the same as your reserve being safe: the same two signatures that let us hold it let us mint against nothing and redeem it out. And it is a property of the deposit, not a reservation of it, so the reserve you fund is the same shared reserve anyone else may redeem against. What it does establish is narrow and worth having: at anchor size the exit is one transaction against a module you filled yourself, not a sequence against three addresses holding a thousand dollars between them.

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, which is still instant, and a solvency check which is currently switched off and which since 2026-08-06 can only be re-armed through the 48 hour timelock, so that one now comes with two days of public notice. 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 172,800 seconds, which is 48 hours. It was 93,600 seconds, or 26 hours, until 2026-08-03, when a queued Safe transaction widening it executed. 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 now about 24 hours rather than the 1.99 hours it was before. Read that in both directions: a missed heartbeat is far less likely to halt minting and redemption, and equally the module will now accept a price up to two days old. This was a deliberate loosening, recorded as such.
• 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.

• The Safe itself has no guard and no modules, and since 2026-08-06 the roles that matter are no longer held by the Safe. The Safe's guard slot is zero and getModulesPaginated returns empty, so nothing constrains the Safe at the Safe level. The constraint was applied one layer down instead. On 2026-08-06 at 17:00:07Z, admin and manager rights on kUSD and on all three PSM modules moved to a TimelockController at 0x36A14976980B7Dd33136f6613545EB0A2C0a0D72 with a 48 hour minimum delay. So there now is a window in which an administrative action on the mint and redeem path can be observed and reacted to before it lands, and it is two days long. Two limits on that. The timelock covers kUSD and the three PSM modules only, not the staking vault skUSD, over which the Safe still holds sole admin with no delay. And the delay does not apply to pausing, which stays instant by design.
• 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 now sits behind the timelock, and the minter set is down to one. DEFAULT_ADMIN_ROLE on kUSD is held by the timelock, not by the Safe, and getRoleAdmin(MINTER_ROLE) is zero, so granting the minting role to anything is still possible but now takes a scheduled operation and 48 hours of public notice. The role itself is held by exactly one contract, the live mint module. 0x8ccc56B5624e2FDB592F6609d81F4c3798e3292B, the v2 vault, held it until 2026-08-03, when the Safe revoked it. It never minted with it and could not have: its deployed runtime contains no kUSD address and no mint selector.
• There was a second route to the same outcome that does not touch kUSD's admin role at all, and it is covered too. The mint module at 0xaBDE1138aa1Ce88d1dF06422C0c3b05D70569803 already holds MINTER_ROLE, because minting against deposited collateral is its job. MANAGER_ROLE on that module 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 published it because the remediation we were preparing at the time 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 covers both, and as of 2026-08-06 it is deployed and executed rather than intended. The Safe no longer holds MANAGER_ROLE on any of the three modules. The timelock holds it, so listing a collateral asset or repointing a price feed is now a scheduled operation with 48 hours of notice. A PauseGuardian holds the same role for the single purpose of calling pause, which is how the emergency stop survived the move without becoming delayed.
• 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, which left the Safe as the only holder of either role until the 2026-08-06 handover moved both to the timelock. Live hasRole for that wallet returns false on both, and it returns false on all three modules. So the fee skim and every parameter needed two signatures, and now needs two signatures plus 48 hours. 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 one requires replaying role events from the creation block, and the command for that is below. The same is true of the timelock, which is also plain AccessControl. 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.