Yield Methodology

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, which both the kerne.fi marketing hero and the app.kerne.fi terminal stat card consume.

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 hardcoded 2.4% (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 asmean x 24 x 365.

Why 180 days. A shorter window (7 or 30 days) makes the headline APY whip around with daily funding noise. A longer window (365 days) still averages in last year's bull funding regime and overstates what users earn today. 180 days is the middle ground that matches how the bot's dynamic insurance allocator models regime, and it is symmetric with how the published funding chart on app.kerne.fi/dashboard renders.

Asymmetry note. The Lido SMA is 7 days while the HL window is 180 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 reality by several months. We disclose this asymmetry rather than hide it: the published number is structurally stickier on the downside than spot funding would suggest, and the bot adjusts its hedge in real time even when the headline number has not yet caught up.

Fallback chain: 180 day window first, then 90 day, then 60 day, then a hardcoded 5.5% empirical fallback. The response field fundingSource (e.g. hyperliquid-180d-trailing) tells you which window produced today's number.

3. Leverage

Until 24 July 2026 the formula multiplied the combined carry by a fixed 3x term. It no longer does, and this section is kept because the number is still quoted at us. That 3x was the target leverage of the strategy design at scale, never a description of the deployed position. 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 currently run.

Why publish a 3x model at all. Higher leverage produces more gross carry but tighter liquidation distance and larger margin costs, and past roughly 2.5x it is the failure class that has ended other basis dollars. 3x is the documented design target at scale, while our published feasibility analysis caps the defensible through-cycle assumption at 2.0x, which is why the published 8 to 9.4 percent band sits below the headline. Since 24 July 2026 the headline is no longer that 3x figure: the endpoint publishes the deployed basis. The 3x target was carried beside it under a modeledTarget key until 28 July 2026, when it was withdrawn entirely, because a target that needs a levered spot leg we do not operate is not a rate any holder could ever be paid. Read the headline as a model of the book we run, and 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 2026-05-16 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 protocol is in Genesis (TVL below $1k as of this writing) so the live formula uses 0%. When TVL crosses $100,000 the fee steps to 5% and the published APY drops by approximately 2 percentage points; we will surface this transition in the live response field feePhase so consumers can detect the cliff in advance.

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)
curl -s https://eth-api.lido.fi/v1/protocol/steth/apr/sma | jq '.data.smaApr'
# returns e.g. 2.19 (interpret as percent: 0.0219)

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

# 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 + 0.0671 x 10) = 2.171
# carry multiplier = L / (L + 1) = 0.6847   <- below one, always

# 4. Compute the formula (illustrative, using the example inputs above)
# 0.6847 x (0.0220 + 0.0671) = 0.0610 grossAPY
# x (1 - 0.1520) = 0.0517 strategyNetAPY
# x (1 - 0.10)   = 0.0466 afterInsurance
# x (1 - 0.00)   = 0.0466 userAPY ~= 4.66%
# Inputs drift continuously; the live endpoint below is always authoritative.
# The funding window was 180d and the cost fraction 22.32% until 6 Aug 2026.

# 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, which is a measurement rather than a model
curl -s https://app.kerne.fi/api/apy | jq '.realized.annualized'
# returns e.g. 0.001123, a FRACTION on the same scale as expectedAPY, so that
# is 0.1123 percent. Until 7 Aug 2026 this key was .realized.annualizedPct and
# carried a NUMBER OF PERCENT, which made it the only percent-scaled number in
# a payload of fractions and therefore read 100x too high, in our favour, on
# the one endpoint whose job is to show we underdeliver. The key was renamed
# rather than kept alongside a twin, because two spellings of one number is
# how that bug is born. Same units on both sides, so the delivered share of
# what we advertise is one division and no unit conversion:
curl -s https://app.kerne.fi/api/apy | jq '.realized.annualized / .expectedAPY'
# returns e.g. 0.024, i.e. we have paid about 2.4 percent OF our headline rate

# There used to be a step 6 here reading .modeledTarget.expectedAPYPct, a 3x
# design target at scale. It was withdrawn on 28 July 2026 and that key now
# returns null. The deployed figure above is the only forward rate we publish.

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 kerne.systems@protonmail.com.

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.