Yield Methodology

Every published Kerne APY traces to a single live computation. This chapter walks through every input, every multiplier and every deduction, and shows you how to reproduce the headline number from public endpoints in under a minute. There is one canonical APY formula. If you find a different number quoted in any other Kerne document or third party page, this chapter is the source of truth and the other figure is either historical or stale. One framing note before the arithmetic: the number this chapter reproduces is a model of the deployed book. The hedge is sized one for one against spot, so the carry is multiplied by L/(L+1), which is below one, never by the venue leverage itself. The realized record is published next to the model on the Honesty Index.

The Canonical Formula

userAPY equals the carry multiplier L/(L+1) applied to the sum of staking APR plus funding APR, then deducted by strategy costs, insurance allocation, and protocol fee in sequence. L is the venue leverage the engine targets at the live funding rate, and the multiplier is strictly below one: the hedge is sized one for one against on chain spot, so venue leverage reduces the margin that must be posted rather than multiplying the carry earned on the underlying.

userAPY = (L / (L + 1)) x (stakingAPR + fundingAPR)
           x (1 − strategyCostFraction)
           x (1 − insuranceAllocation)
           x (1 − protocolFee)

# L = venue leverage targeted at the live funding rate.
# L / (L + 1) is ALWAYS below one. It is not a multiplier
# on the carry; it is the share of capital earning it.

Each multiplicand has a single canonical source. The formula and all constants are defined in the live computation at app.kerne.fi/api/apy.

1. Live Staking APR

We pull stakingAPR from the Lido protocol's 7 day simple moving average of stETH yield. Public endpoint: https://eth-api.lido.fi/v1/protocol/steth/apr/sma. The 7 day window is short enough that material changes in Ethereum issuance reflect within a week.

If the Lido endpoint fails, we fall back to a fixed recent wstETH baseline and mark the response field stakingSource as fallback-wsteth-recent-range so consumers know the number is not live. The isLive field flips to false whenever any input is in fallback.

2. Live Funding APR

We pull fundingAPR from Hyperliquid as the 60 day trailing mean of the ETH perpetual hourly funding rate. Public endpoint: POST https://api.hyperliquid.xyz/info with body { "type": "fundingHistory", "coin": "ETH" }. Hyperliquid settles funding hourly. We paginate roughly 1,440 hourly entries (60 days), compute the simple mean, and annualize as mean x 24 x 365.

Why 60 days. The window was reselected on 6 August 2026 by out of sample prediction error against realised forward funding, replacing a 180 day mean. A shorter window makes the headline APY whip around with daily funding noise, and a longer one averages in older funding regimes that overstate what users earn today.

Asymmetry note. The Lido SMA is 7 days while the Hyperliquid window is 60 days. We chose this asymmetry deliberately: staking APR moves slowly with validator entry queues and rarely moves more than a few basis points week over week, so a short window is fine. Perpetual funding can swing materially day to day, so the longer window is needed to give a stable user facing number. The trade off is that during a sharp funding inversion the published funding APR lags spot funding, so the published number is stickier on the downside than spot funding would suggest. The bot adjusts its hedge in real time even when the headline number has not yet caught up.

Fallback: if the funding read fails, the endpoint falls back to a fixed empirical value and isLive flips to false. The response field fundingSource (for example hyperliquid-60d-trailing) names the window that produced today's number.

3. Leverage

The formula multiplies the combined carry by L/(L+1), never by a fixed leverage term. At genesis size the engine sizes its short one for one against the vault's exposed assets, so the deployed hedge is unlevered. Venue leverage at that size reduces the margin that must be posted; it does not multiply the carry earned on the underlying. Multiplying carry requires levering the underlying spot exposure itself, which the deployed strategy does not run.

Why not lever the carry. Higher leverage produces more gross carry but a tighter liquidation distance and larger margin costs, and past roughly 2.5x it is the failure class that has ended other basis dollars. The published figure is a model of the book we run; read the realized figure on the Honesty Index as the record.

4. Strategy Cost Fraction

Running the strategy is not free. We pay trading fees on rebalances, slippage on perp executions, and gas on Base transactions. The total comes to 15.20% of gross yield, broken down as:

Today this fraction is hardcoded into the live API. As we observe real production costs we will replace it with a trailing actual cost ratio so users see live operational truth instead of a backtest derived constant. That migration is tracked in our roadmap.

5. Dynamic Insurance Allocation

After strategy costs, the protocol allocates a slice of remaining revenue to the Insurance Fund (contract 0xE879…0403, redeployed 16 May 2026 with Safe Multisig as sole admin). The default allocation is 10% of revenue. The bot's InsuranceAllocator can adjust this dynamically across a 5% to 25% range based on funding regime, fund adequacy ratio, volatility percentile, TVL scale, and Neural Engine risk score. Full spec at docs/DYNAMIC_INSURANCE_FUND_SPEC.md.

Today the live formula uses the 10% default. Wiring the live allocator value into the published APY (so users see the elevated rate during stressed regimes) is queued as a roadmap item; until then the disclosed APY assumes 10% and the allocator state is exposed separately for users who want to verify.

6. Protocol Fee

The KerneVault performance fee is phased by that vault's own TVL. During Genesis (TVL below $100,000) the fee is 0%. During Growth ($100k to $1M) it is 5%. During Maturity ($1M and above) it is 10%. The schedule is enforced in src/KerneVault.sol constants GENESIS_TVL_THRESHOLD, GROWTH_TVL_THRESHOLD, GROWTH_PHASE_FEE_BPS, MATURITY_PHASE_FEE_BPS. It applies to that vault and to nothing else: skUSD, the live yield bearing product, has no performance fee in its deployed source and no setter that could introduce one.

Today the vault is in Genesis, so the live formula uses 0%. When its TVL crosses $100,000 the fee steps to 5% and the published APY steps down with it. The live response field feePhase reports the current phase, so consumers can see the change coming.

Reproduce the Number in 60 Seconds

Anyone can reproduce today's published APY from public endpoints. The recipe:

# 1. Get live staking APR (Lido 7d SMA), returned in percent
curl -s https://eth-api.lido.fi/v1/protocol/steth/apr/sma | jq '.data.smaApr'

# 2. Get live funding APR (HL 60d trailing) by reading our cached endpoint
curl -s https://app.kerne.fi/api/apy | jq '.sources.fundingRate'

# 3. Derive the venue leverage the engine targets at that funding rate,
#    then the share of capital that is actually earning the carry
# L = min(12, 1.5 + fundingRate x 10)
# carry multiplier = L / (L + 1)   <- below one, always

# 4. Compute the formula
# grossAPY       = multiplier x (stakingAPR + fundingAPR)
# strategyNetAPY = grossAPY x (1 − 0.1520)
# afterInsurance = strategyNetAPY x (1 − 0.10)
# userAPY        = afterInsurance x (1 − 0.00)
# Inputs move continuously; the live endpoint below is always authoritative.

# 5. Cross check against the live API
curl -s https://app.kerne.fi/api/apy | jq '.expectedAPYPct'
# should match within rounding

# 6. The realized rate, a measurement rather than a model.
#    A fraction, on the same scale as expectedAPY.
curl -s https://app.kerne.fi/api/apy | jq '.realized.annualized'

# 7. The delivered share of the modeled rate, same units on both sides
curl -s https://app.kerne.fi/api/apy | jq '.realized.annualized / .expectedAPY'

Every input is independently verifiable. The Lido endpoint is theirs, the Hyperliquid endpoint is theirs, and our methodology is fully disclosed above. If our published APY ever diverges from what the formula would produce, that divergence is a bug we want you to report to liam@kerne.fi.

Why a Methodology Chapter Matters

Most yield protocols publish a single APY number with no derivation. When the number drops, holders feel ambushed. We chose to publish the entire computation chain so that when funding compresses or insurance allocation rises, you see why before your APY moves and can decide whether to stay or rotate.

Past performance does not predict future results. The current rate on the deployed basis, published live at kerne.fi/api/apy, reflects today's funding regime and cost assumptions. A sustained funding inversion would compress the live number toward zero and can take it negative, and a return to bull cycle funding would push it higher. We surface the live drivers so that future readings, in any direction, are predictable from public data rather than feeling like protocol caprice.