What Kerne sells.

1. The ask

We are not asking you to deposit. Deposits into the live vault are shut at the contract, which section 3 states with the call that shows it, and the staking vault that is open has exactly one holder. The commercial relationship on offer is work: you name an address or a protocol, we read it, and we hand back a result signed by a key whose address is published.

Above those there are fixed-price engagements for reserve snapshots, counterparty verification, commissioned teardowns and standing security work. The full catalogue with every price is at /pricing, anything above the $149 floor can be bought against an invoice at /invoice rather than from a wallet, and the contracting party is a co-founder acting personally. There is no company, which /institutional states along with the novation term that covers it.

2. What that ask actually rests on

A signed read is worth what the signing and the method are worth, so those are the only two things worth checking before buying one.

• Kerne signs a statement of its own reserves every hour and publishes it at /api/por/signed. You can recover the signer, rehash the payload and check freshness in your own browser at /verify, against our signature, before you send anybody money.
• The same measurement method is applied to every comparable protocol we can measure on chain and published as a board Kerne can lose, and currently does lose, at /honesty-index. Every row is re-derivable from public archive RPC by a second implementation that shares no code with ours: /honesty-index/reproduce.
• A million dollar round trip through the modules, run on a pinned fork from an address that had never transacted and reconciled to the cent, is at /round-trip. What that ticket would be against the size of this protocol is at /first-money.
• Who outside Kerne has checked the contracts, and what they found, is at /security/independent and /security/audits.

The honest form of the objection to all of this is not that any single finding below matters to a read. It is broader: if the protocol is this small, why trust the shop. The answer is that the shop and the protocol are separately checkable, and the shop is the half that has public, running, signed output an outsider can grade today. Grade it before buying, and the board above is where we made that convenient.

3. What a diligence read finds

Eight things, and every one of them is a public read anybody can run without asking us for anything. Most are already published somewhere on this property. They are collected here so that a reader who starts checking meets Kerne's own account of each one rather than concluding it was hidden.

3.1 The deposit gates, both of them

Two vaults, two different answers, and the difference is the thing worth knowing. Probed with the burn address, the live deposit vault returns 0 from maxDeposit, so that address cannot put anything into it. The staking vault, probed with the same address, returns the uint256 maximum, so nothing on chain caps it and no whitelist exists there. Substitute your own address into either call and check the answer is the same, which is the only version of this claim worth making.

cast call 0x8ccc56B5624e2FDB592F6609d81F4c3798e3292B "maxDeposit(address)(uint256)" 0x000000000000000000000000000000000000dEaD --rpc-url https://mainnet.base.org
cast call 0x96F5102C15b839757f811A98CEc3725Ac21DfA14 "maxDeposit(address)(uint256)" 0x000000000000000000000000000000000000dEaD --rpc-url https://mainnet.base.org

The second of those is also why no cap sentence appears anywhere on this property about the staking vault. A cap that the contract does not enforce is a promise made in prose, and /api/apy publishes capEnforceable as false for exactly this reason.

4. The four worth a paragraph each

4.1 One holder, and it is us

Read the staking vault's total supply, then read the founder wallet's balance of it. On this read both calls returned the same thirty two byte word, so there is exactly one holder of skUSD and it is Kerne's own hardware wallet. The 1,011.482368 shares that appear wherever this vault is measured are our own money, not a deposit anybody chose to make. This is the same fact /api/por publishes as founderOwnedFraction and /api/apy publishes as insiderStakedUSD against an external figure of zero, stated in the units the chain returns it in. It is also the reason no distribution has been made from the Genesis escrow: paying yield into a vault that is entirely our own address would move money between two Kerne accounts and then publish the result as realized yield, which is precisely what the Honesty Index exists to catch. The gate that refuses it is in the planner and is re-checked on chain before signing.

cast call 0x96F5102C15b839757f811A98CEc3725Ac21DfA14 "totalSupply()(uint256)" --rpc-url https://mainnet.base.org
cast call 0x96F5102C15b839757f811A98CEc3725Ac21DfA14 "balanceOf(address)(uint256)" 0x14f04cE02f35B29Af564A98544dD7e2393993946 --rpc-url https://mainnet.base.org

Returned: 0x00000000000000000000000000000000000000000344adb91052ed010fae5b16 and 0x00000000000000000000000000000000000000000344adb91052ed010fae5b16. The claim is made on the words rather than on the decimal figures, because at twenty four decimals two different balances print identically.

4.2 Realized yield is zero, and the share price says so

One share of skUSD converts to 1.000098667771066974 kUSD, and it has converted to that same figure since 9 July 2026. A share price that does not move is a vault that has paid nothing. The whole of the fraction above one comes from a single 0.10 kUSD transfer, which the deployment registry records as a plumbing test proving the strategist topology works rather than as strategy carry, and it has since passed out of the trailing thirty day window. So the realized column for Kerne on its own board reads 0.00 percent, and by that board's own note Kerne is the only row on it that realizes exactly zero while still publishing a forward rate. The other rows that realize zero publish no rate at all. Where Kerne ranks against the rest is computed on the board rather than asserted here: /honesty-index. The rate Kerne publishes is labelled a model of a deployed book on the endpoint that computes it, beside the realized figure, on every request. What a signed read costs, and whether it is correct, does not depend on any of this.

cast call 0x96F5102C15b839757f811A98CEc3725Ac21DfA14 "convertToAssets(uint256)(uint256)" 1000000000000000000000000 --rpc-url https://mainnet.base.org

The argument is 1e24 because that is the SHARE decimal on this vault while the answer comes back in kUSD at eighteen. Passing 1e18 returns a millionth of the real figure and makes the vault look like it trades at a rounding error.

4.3 The funding field reads negative, and that is money arriving

Ask Hyperliquid for the hedge account's position and read cumFunding.allTime. On this read it is -0.152271, a negative number. A negative value there, read as cumulative funding earned, says the hedge has been paying to stay open, which on a short whose whole purpose is collecting funding would be the most damaging thing on this page. It is a sign convention. The venue reports that field in the PAID direction, so a negative value is funding received, and the per settlement ledger settles it rather than leaving it to be argued about.

291 settlements have credited this account and 19 have cost it, for 1.226245 USDC received since 2026-05-01, across 2,508 hourly samples. The tail of that ledger from 2026-07-22 sums to 0.152271, which is the position field with its sign flipped, so that date is where the venue's counter starts rather than the start of the ledger. That is the reconciliation, and this page derives it on every read: when the ledger and the field do not reproduce each other the sentence you are reading does not appear and no direction is claimed.

curl -s https://api.hyperliquid.xyz/info -H "content-type: application/json" \
  -d '{"type":"clearinghouseState","user":"0x09a2780ac8Be6D5d2d1F85A8D92b09D40C9CA37e"}'
curl -s https://api.hyperliquid.xyz/info -H "content-type: application/json" \
  -d '{"type":"userFunding","user":"0x09a2780ac8Be6D5d2d1F85A8D92b09D40C9CA37e","startTime":0}'

Over the trailing 60 days, the window the published model prices its funding input over, this book realized 8.70% annualized on the notional it actually carried, against a venue 60 day mean of 9.12% for the same window. Those two are close but they are not the same measurement: the venue figure covers every hour, and ours covers the hours this book actually held a position, weighted by the notional it held. What has not happened is any of it reaching a holder, for the reason in 4.1.

4.4 The engine is small, and it is smaller than the book

/api/por reports the assets behind the hedge as the WETH the retired vault holds on chain plus the live equity in the venue account, recognised at the lower of the on chain mirror and the venue's own balance so a stale mirror can never overstate it. On this read that is $37.30 against a staked book of 1,011.582169 kUSD, so the machinery that produces the carry is 3.69% of the book it is measured against. Nothing here is levered to close that gap. kUSD is backed by USDC held in the modules, at the ratio section 5 computes, and the hedge is a disclosed pilot sized against a founder float rather than against user collateral. That is why the hourly signed attestation reports a hedge base of zero and carries a delta warning: the vault it attests holds no user deposits, so a short over it scores as fully directional. That is the expected steady state for a book in this position and not an incident, and it clears when the hedge runs against collateral that actually backs kUSD. A book this size is an argument for buying verification and against making a deposit, which is the argument this page is making.

5. Supply against reserves, in two lines

A reader who compares the two obvious totals finds kUSD total supply of 1,144.707154 kUSD against combined module reserves of 1,110.888006 USDC, and concludes the reserve is about 33.82 dollars short of the supply. It is not, and the two lines that close it are these.

1. 35.000000 kUSD of that supply is sitting inside the modules themselves, returned by redeemers and held by the protocol rather than by anybody with a claim. It splits as 3.000000 at the retired mint module 0x07eBb486e11BD217e6085eb5ab663e4517595993, 32.000000 at the redeem reserve module 0xFf3025ec18e301855aB0f36Ec6ECa115a29A5Fbc, 0.000000 at the live mint module 0xaBDE1138aa1Ce88d1dF06422C0c3b05D70569803.
2. Outstanding kUSD, the only figure that is a claim on the protocol, is therefore 1,109.707154. Reserve over outstanding is 1.0010641113701, which is the figure the signed attestation carries as psm_solvency_ratio and the one /api/por carries as psmSolvencyRatio.

Supply is the wrong denominator and it is wrong in a specific way: it counts inventory the protocol holds as though somebody could redeem it, which manufactures a shortfall exactly the size of that inventory. Both figures are published separately, on the endpoint that exists to be recomputed by strangers, so the check is available in both directions. /first-money works the same arithmetic against a hypothetical ticket, and /transparency carries the module by module detail.

6. What to do with this

If you are grading Kerne as a place to put money, the sections above are the case against and we would rather you had them from us. If you are grading Kerne as somewhere to buy a signed read, none of them apply, and the fastest way to find out whether the work is any good is to buy the cheapest one and check it.

• /pricing, every SKU with its price and a checkout.
• /honesty-index, the same method applied to the category, with Kerne on it.
• /security, scope, findings, the reserve concentration and the researcher ledger.
• /contact, if the scope you need is not on the list.