Transparency

Prove it yourself. Every hour.

Continuous on-chain transparency for institutional capital. Proof of reserves and protocol health metrics attested every hour.

Doing diligence?

The data room assembles everything on this page with the contract registry, audit pipeline status, governance, and the deployed-vs-source disclosure. One URL.

If you want it shorter, the tear sheet puts the same facts on one page. What we measured and then declined to do is in the refusal log, dated and append-only, including the market we refused to run ourselves.

Open the Data Room →

0%

Performance Fee • During Genesis Phase

Early adopter incentive

All yield retained by depositors

1

Chain:

Base

Multi-chain expansion planned

1h

Attestation Cycle

Continuous reserve verification

Automated signed proof

Genesis Window: closed

Closed 2026-08-05T00:00Z

The Genesis Window closed at 00:00 UTC on August 5, 2026. It closed on its time bound, not on its cap. kUSD supply at the close was $1,145, or 0.46% of the $250,000 cap, so the cap was never the binding condition. We are leaving that number up rather than removing the tile, because a protocol that publishes a target should publish how it did against it.

Nothing about the fee changed when it closed, and no fee has been introduced. Staking kUSD into skUSD still costs 0% in protocol fees, for every holder rather than only the early ones, and for the same reason it did during the Window: the deployed skUSD contract contains no fee logic and no function that could switch one on. The Window was a commitment not to introduce one during a fixed term. The term has ended; the rate has not moved. If that ever changes it would take a different contract, which holders would have to move to deliberately and which cannot reach into a position they already hold. Do not take that on trust and do not take it from an API field either: read the deployed contract. skUSD at 0x96F5102C exposes no fee getter and no fee setter, so there is nothing to read a rate from and nothing to set one with.

kUSD total supply at close

$1,145

0.46% of the $250,000 cap, as at 2026-08-02

kUSD total supply now

$1,145

live from the PSM, gross of the kUSD the PSM holds as inventory. /tear-sheet publishes kUSD outstanding, which nets that off and is the smaller figure. The cap bounded the Window, never total deposits, so this figure is free to move past it.

Window status

Closed

time bound reached

/Two Yield Sources. Zero Directional Risk

This is the design of the strategy, not a description of today's book. Outstanding kUSD is backed by USDC in the Peg Stability Module, and the v1 WETH vault is paused and holds no user funds. Read /risk for how that can fail, and /honesty-index for where we rank ourselves against every other issuer on advertised versus realized yield.

Ethereum Staking Rewards

Deposited collateral continues earning Ethereum proof-of-stake consensus rewards.

Perpetual Funding Rates

A matching short perpetual futures position collects funding rate payments from leveraged long traders.

/Proof of Reserves

Every kUSD is backed 1:1. Verified every hour.

kUSD is fully backed by USDC in the Peg Stability Module, and total protocol collateral exceeds outstanding kUSD by a wide margin in USD terms, attested in a signed proof of reserves every hour. The legacy v1 WETH vault is paused and held in a documented protective mode, holds no user funds, and is excluded from this backing. Its raw vault-share figures read alarming in isolation, which is why the signed proof leads with the corrected PSM and USD-aggregate primitives below.

Live Transparency Dashboard

Real-time backing ratio, APY history, and asset allocation, verified on-chain.

View Live Dashboard →

Reachable exit depth

Backing and reachable liquidity are different questions, and most issuers only answer the first. A redemption is a single transaction against a single Peg Stability Module, and each PSM pays only from its own USDC reserve. So the honest instant figure is the deepest single reserve, never the sum of all of them. We publish both, per contract, and never blend them into one number.

Instant, one transaction

$995.00

89.66% of outstanding kUSD

Total reachable, sequential transactions

$1,110.89

100.11% of outstanding kUSD

A mint funds its own exit leg. The USDC you mint with is deposited into the mint module and stays on its balance, in the same transaction that mints your kUSD. So the reserve your own redemption draws on is your own deposit, not the standing figure. A $250,000 mint adds $250,000 to that module's reserve as it happens, and our redeem router sends a redemption to the smallest module that fully covers it, which at that size is the module holding your own deposit. The standing figure measures something narrower and we publish it because it is the harder number: what a holder who did not mint can take out in one transaction today.

What that does not do is make the exit free or unconditional. Exit is not at par, because the same tiered swap fee applies on the way out, and redemption carries the same gates as minting, including a pause the operator controls. There is no lockup and no cooldown on this path.

Contract	Address	USDC reserve
Live mint PSM	0xaBDE1138aa1Ce88d1dF06422C0c3b05D70569803	$30.00
Legacy redeem PSM (redeem only)	0xFf3025ec18e301855aB0f36Ec6ECa115a29A5Fbc	$85.89
Prior mint PSM (redeem only)	0x07eBb486e11BD217e6085eb5ab663e4517595993	$995.00

Redemptions that have actually executed

Capacity is a description of what the contracts can do. These are the transactions in which kUSD was handed back and USDC came out, on Base, permanently. Every one of them was sent by the founder custodied wallet, so they are evidence that the exit path works against live deployed code and they are not evidence of outside demand. Redemptions by anyone other than the founder to date: 0.

2026-07-21: 32.000000 kUSD in, 31.968000 USDC out, via the redeem-reserve PSM.0x05476a37c2c91332d5af5982f100e36ee3727cecb42ee37bbd31f74f88708416
2026-08-03: 3.000000 kUSD in, 2.997000 USDC out, via the retired mint PSM.0xac07a7f6dff9654b3b66dac3341adff75583535d6f50947d0bc63367062e692e

A redemption does not burn kUSD. Both deployed PSM contracts predate the redeem burn change, so returned kUSD is transferred into the contract and held there as inventory. Total supply is unchanged by a redemption and lifetime kUSD burned is exactly 0. What falls is outstanding kUSD, because kUSD sitting in a PSM is netted out of it. If you check total supply after one of these and see a flat number, that is the design working.

Redemptions route to the smallest reserve that fully covers the amount, which keeps the deepest reserve available for larger exits. A contract marked redeem only has had its kUSD minting role revoked, so it cannot issue new kUSD. That does not restrict redemption: the redeem path transfers kUSD into the contract rather than burning it, so it never touches the minting role, and those reserves pay out in full.

Until 24 July 2026 the figure this app displayed was capped at the second deepest reserve, because the interface read only two of the three PSM contracts. The deepest reserve was live and redeemable by direct contract call the whole time. The interface was the thing that was wrong, and we fixed the interface. No contract was changed, unpaused, moved, or redeployed to produce the numbers above.

Verify under redemptionDepth in /api/por →

≥100%Backing Ratio

Every kUSD is backed 1:1 by USDC in the PSM, with total protocol collateral exceeding outstanding kUSD in USD terms, verified and signed on-chain every hour

Every Hour

The Sentinel system runs automated solvency checks every hour. Each check verifies total collateral value against outstanding kUSD liabilities and publishes a signed attestation.

What We Verify

Total protocol collateral vs. outstanding kUSD
Hedge position health and margin levels
Insurance fund balance adequacy
Oracle price feed accuracy

On-chain Proof

Every attestation is EOA-signed and published hourly at /api/por/signed. Anyone can recover the signer and verify the current backing ratio, collateral breakdown, and hedge position status.

Insurance Fund

First-loss capital that absorbs losses from negative funding or market dislocations ahead of depositors, capitalized from protocol revenue over time. At the protocol's current early scale the balance is $0 today.

Verify $0 today: 0xE879...0403

/Payment Receive Address

One address takes payment. Match every character.

Every paid service on kerne.fi collects USDC on Base at exactly one address, shown below. The payment panels tell you to verify the address against this page before you send; this is that address. If a payment panel, an invoice, an email, or a DM ever shows a different one, do not send, and tell us at kerne.systems@protonmail.com.

USDC receive address on Base

0x14f04cE02f35B29Af564A98544dD7e2393993946

View on Basescan →

Lookalike addresses are a live threat, not a theoretical one: attackers generate addresses that copy the first and last characters of a real one, betting you only compare the ends. Compare the entire string, character by character, before you send. Only the exact address is identity.

/Verify the signature yourself

Three lines of code. One signer to match.

The bot writes a fresh signed Proof of Reserves every hour. The signing key is the strategist EOA 0x09a2780ac8Be6D5d2d1F85A8D92b09D40C9CA37e. Fetch the latest signed JSON, recover the signer from attestation_hash and signature, and confirm it matches.

Latest signed attestation

Hourly cadence, EIP-191 personal_sign, freshness surfaced in the response _meta.

View /api/por/signed →

Read these fields first

Since schema v4 the headline aggregate_solvency_ratio is the PSM stablecoin backing ratio (USDC reserve vs user-held kUSD), consistent with psm_solvent, psm_solvency_ratio, and aggregate_solvency_usd_ratio. The vault-share basis it carried before v4 stays published, demoted to legacy_vault_share_solvency_ratio and the labeled known_issue_vault_v1 block. The _meta.v2_summary block surfaces the PSM-aware primitives, and _meta.degraded_state_explanation documents why the demoted share-basis fields look alarming while the protocol is structurally solvent. Schema version is exposed as schema_version, currently 4.

One kUSD holder to note when you reconcile supply

The retired skUSD v1 wrapper at 0xdEd74F7E06efc76455C07418b8b74Cc2bc009DB4 still holds about 10.09 kUSD from an early third-party deposit. That vault was superseded on 2026-07-03 by the live skUSD at 0x96F5102C and is abandoned. The balance is ordinary kUSD, backed 1:1 through the PSM like every other kUSD and already included in the circulating supply the solvency ratio is measured against. We name it here so anyone recomputing the kUSD holder set finds this holder documented rather than unexplained.

Two things about that deposit we should have said earlier, and are saying now. First, nobody asked for it. On 2026-06-15 an address we had never contacted called the PSM, paid 10.000000 USDC of its own, received 9.99 kUSD and staked all of it sixteen seconds later. We did not solicit, refer, fund or introduce it, and we have never been in touch with whoever holds it. It is the only kUSD position anyone outside this project has ever opened, and it is still open. It is also ten dollars, and we are not going to dress ten dollars up as demand.

Second, the part that reflects badly on us. When we moved to the new vault we repointed the app and built nothing that reads the old one, so from 2026-07-03 that holder's balance showed as zero in our own interface with no way to withdraw from it. The money was never locked, never paused and never at risk, and the contract has no admin withdraw path, so this cost them nothing but the ability to see it. Still, a protocol whose whole argument is that you should check it for yourself had left its only outside user unable to check their own balance. That was our omission, it lasted seven weeks, and it is fixed: the app now shows the retired position and offers a working exit, and /api/por now reports the retired vault beside the live one instead of describing only the vault whose deposits are ours.

Checking kUSD holders on a block explorer?

Two things can make an explorer holder list read oddly, and neither is a backing problem. First, the large majority of circulating kUSD is held by a single contract, the skUSD staking vault at 0x96F5102C15b839757f811A98CEc3725Ac21DfA14, because staking kUSD moves it into the vault. A holder set that looks concentrated in one address is that staking vault working as designed. Most of the remainder sits in three accounts we can name: the founder wallet, the redeem-reserve PSM, and the retired v1 wrapper noted above. The founder wallet withdrew its Aerodrome kUSD/USDC liquidity on August 1, 2026, which moved about 84.99 kUSD out of that pool contract and into the wallet, so a holder list read before that date apportions the same kUSD differently. That withdrawal minted and burned nothing, and the 1:1 backing did not change. Second, some block explorers freeze or lag their token holder index and undercount both the number of holders and the total held, missing recent mints. If an explorer shows a holder total well below the live total supply, that is an explorer indexing gap, not missing backing. The authoritative numbers are the live total supply and the 1:1 USDC backing in the hourly signed proof of reserves at /api/por/signed, and every balance is independently checkable on BaseScan. Reconcile against those.

One trap to avoid: verify over raw bytes, not text

The signature is EIP-191 personal_sign over the 32 raw bytes of attestation_hash, not over the 66-character hex string. The recipes below already handle this: hexstr= in eth_account, getBytes() in ethers, and cast wallet verify natively. If you instead encode the hash string as text (encode_defunct(text=...), or ethers verifyMessage(j.attestation_hash, ...) without getBytes), you compute a different digest and recover a different, wrong address from a perfectly valid signature. If your recovered address does not match the signer, check this first before concluding anything about the attestation.

JavaScript (ethers v6)

import { verifyMessage, getBytes } from "ethers";

const j = await (await
  fetch("https://kerne.fi/api/por/signed")
).json();

const recovered = verifyMessage(
  getBytes(j.attestation_hash),
  j.signature,
);
console.assert(
  recovered.toLowerCase()
    === j.signer.toLowerCase(),
);

Python (eth_account)

import requests
from eth_account import Account
from eth_account.messages import encode_defunct

j = requests.get(
  "https://kerne.fi/api/por/signed"
).json()

# hexstr= treats the hash as raw bytes.
# text= would recover the WRONG signer.
msg = encode_defunct(hexstr=j["attestation_hash"])
recovered = Account.recover_message(
  msg, signature=j["signature"],
)
assert recovered.lower() == j["signer"].lower()

CLI (foundry cast)

curl -s https://kerne.fi/api/por/signed > por.json

HASH=$(jq -r .attestation_hash por.json)
SIG=$(jq -r .signature  por.json)
SIGNER=$(jq -r .signer  por.json)

cast wallet verify \
  --address $SIGNER $HASH $SIG

The route response embeds the same three snippets under _meta.verify, a freshness flag at _meta.is_fresh, and an expected-signer check at _meta.signer_matches_expected. On a key rotation the expected-signer constant is updated in the route handler and the boolean reflects the new state on the next deploy.

Check freshness with _meta.freshness.expires_at, not with _meta.is_fresh. The boolean is computed when the response is built, so a cached copy keeps asserting whatever was true at that moment. expires_at is an absolute timestamp you compare against your own clock, which stays correct no matter how long the response sat in a cache. You can rebuild it from the signed bytes alone: JSON.parse(signed_payload_canonical).timestamp plus _meta.freshness.stale_threshold_seconds.

Why this field exists: on 1 August 2026 our own infrastructure sweep fetched this endpoint and received an attestation generated on 4 June that still reported is_fresh: true. The response had been built on 4 June, when it was genuinely fresh and correct, and a cache served that same body 58 days later. No figure was ever fabricated and no attestation was ever late: the signing bot published on its hourly cadence with no gap for the whole period, so this was a delivery fault on the read path, not a reserves or solvency problem. We cannot reconstruct how many requests were affected, and we are not going to pretend otherwise. What we changed on 2 August is that the response now carries an absolute expiry you can check yourself, its cache lifetime is bounded by the attestation's remaining validity, the published date is derived from the signed timestamp rather than passed through unsigned, and a scheduled check fails loudly if this endpoint ever again serves a stale attestation labelled fresh.

Delta neutrality, signed

The hedge's deviation from a perfect hedge, as a fraction of the declared hedge base (the ETH-exposed vault leg plus the disclosed watch-only float the engine shorts against), read from the signed hourly attestation (the same value the delta_neutral flag is computed from, tolerance 5 percent). The engine rebalances on drift above 0.005 ETH; the attestation flags non-neutral beyond 5 percent of that base.

Loading the signed attestation...

Verify all of it yourself: /api/por/signed (current, EIP-191 signed), /api/por/delta-history (series + methodology), raw hourly archive at the attestation host.

Realized funding ledger

What the hedge account has actually earned and paid, month by month, read from Hyperliquid's public ledger: funding received (negative-funding periods subtract), trading fees, closed price PnL on the hedge leg, net. These are genesis-scale dollars, published deliberately; the replay recipe is embedded in app.kerne.fi/api/funding-attribution.

Loading the venue ledger...

/Live Risk Status

The runbook, audited live

Every threshold in the runbook is wired to the contract or the Sentinel risk engine, and surfaced here in real time.

/Governance Queue

Who can change this, and how fast

Kerne is administered by a 2-of-3 Safe with no guard and no modules. Since 2026-08-06 that Safe can no longer change the mint or redeem path instantly. Admin and manager rights on kUSD and on all three PSM modules are held by a TimelockController at 0x36A14976980B7Dd33136f6613545EB0A2C0a0D72 with a 48 hour delay, so a change has to be scheduled in public and sits visible in the queue for two days before it can land. The emergency stop is not delayed. This does not cover everything: the staking vault skUSD holds most of the kUSD in existence and the Safe still holds sole admin over it with no delay. The Safe queue is public, and rather than leave you to decode it we decoded every entry from its calldata and published the working. The same page carries the measured time this Safe has taken to produce a second signature across all 19 transactions it had executed at the time of measurement: a median of 12 minutes and a worst case of 25 days.

Read the decoded queue