Kerne Logo
Documentation

Live APY Math

Every protocol publishes an APY number. Few publish the formula, every constant, and the live inputs in one machine readable endpoint that updates in real time. We do, because the only way a depositor can verify what the protocol earns is to see every input that produces the headline number.

If the displayed APY ever drifts from what these constants and inputs imply, the page is wrong, not the protocol. The math is checkable on the same visit by the same caller, against the same upstream feeds we use ourselves.

The Formula

The displayed APY is computed by computeLiveAPY() in app.kerne.fi-terminal/src/app/api/apy/route.ts. The methodology string in the JSON spells it out in one line:

[L/(L+1)] × (Lido 7d SMA + HL 60d trailing funding) × (1 − 15.20% strategy costs) × (1 − 10% insurance) × (1 − 0% Genesis fee),  L = min(12, 1.5 + funding × 10)

In English: take the staked ETH base yield plus the trailing perpetual funding rate, multiply by the share of capital that is actually earning that carry to get gross APY, deduct strategy operating costs, route a fixed portion of the remainder to the Insurance Fund, then deduct the protocol fee. The protocol fee is 0% during the Genesis phase; the methodology string shows the live value, not a target.

That share is L/(L+1), and it is always below one. The hedge is sized one for one against on-chain spot, and the margin posted behind the short earns nothing, so of total capital C the spot leg is C × L/(L+1) and the remainder is margin. Venue leverage reduces the margin that has to be posted; it does not multiply the carry earned on the underlying. This formula read 3× until 24 July 2026, which overstated the deployed book by roughly four and a half times. The 3× figure was then carried in a modeledTarget block on the same JSON until 28 July 2026, when it was withdrawn: it was reachable only with a levered spot leg the protocol does not run, and no holder could have been paid it.

Where Each Constant Comes From

  • Lido 7-day SMA: live, sourced from the Lido staking yield feed and smoothed over the last seven days. Reported as stakingYield in the JSON.
  • Hyperliquid 60-day trailing funding: live, computed from 1,440 hourly Hyperliquid funding samples (60 days × 24 hours). The window was 180 days until 6 August 2026, when it was reselected by out-of-sample prediction error against realised forward funding. The window length is reported asfundingWindowDays and the sample count as fundingEntries.
  • Venue leverage L: not fixed. Recomputed each call from the prevailing funding rate using the hedge engine's own rule, min(12, 1.5 + funding × 10). Reported as leverage in the JSON, with the resulting carryMultiplier (L/(L+1)) beside it so the two can be checked against each other.
  • Modeled leverage 3×: the old design target at scale. It fed only the modeledTarget block, which was withdrawn on 28 July 2026, so it is no longer published in any form and never touched the headline.
  • Strategy costs 15.20%: fixed cost fraction covering perp execution slippage, exchange fees, and gas. Was 22.32% until 6 August 2026, when a margin opportunity cost slice of 7.12 points was removed as a double-count of the L/(L+1) multiplier. Reported as strategyCostFraction.
  • Insurance allocation 10%: fraction of net yield routed to the Insurance Fund. Reported as insuranceAllocation.
  • Genesis fee 0%: protocol fee during the Genesis phase. Reported as protocolFee and feePhase. When the fee schedule changes, both fields update on the same release.

Verify It Yourself

Hit the endpoint directly and read the live values:

curl -s https://app.kerne.fi/api/apy | jq

Each numeric field above appears as its own key. The methodology field is the same one-line formula rendered with the live inputs substituted in. The isLive flag is true while live sources are reachable; if either upstream feed is unavailable the endpoint falls back to a frozen value and the flag flips to false.

The two derived intermediates are also published so the chain of arithmetic is auditable: grossAPY is [L/(L+1)] × (staking + funding), and strategyNetAPY is grossAPY × (1 − strategyCostFraction). Multiplying strategyNetAPY by (1 − insuranceAllocation) × (1 − protocolFee) reproduces expectedAPY.

Raw JSON

The unprocessed feed lives at app.kerne.fi/api/apy. Mirror it, cache it, or diff it against historical snapshots. Nothing on this chapter is paywalled and no signed request is required. If the rendered APY anywhere on kerne.fi disagrees with what this endpoint produces from its own published constants, the rendered page is wrong, not the endpoint.

24h Funding Forecast (Neural Engine v3)

The 60-day trailing window in the APY formula above is a backward-looking smoothing. The protocol also publishes its forward-looking 24h funding-income forecast, produced by the same linear model the bot uses to size its hedge: kerne.fi/api/forecast.

Three feature inputs: trailing 24h funding sum, current premium, trailing 24h premium sum. The model coefficients, intercept, and residual standard deviation are all returned in the response under the model.coefficients object so anyone can reproduce the prediction by hand. The training metrics are returned alongside: testR2 is 0.44 against a naive last-24h-sum baseline of 0.31. That is a real, modest, publishable lift on a noisy target rather than the constant-predictor degenerate the previous LSTM attempt produced.

The TypeScript implementation in frontend/src/lib/forecast-engine.ts mirrors the Python implementation in bot/funding_forecast.py byte-for-byte. The bot's own forecast is persisted to /opt/kerne/bot/data/forecast_latest.json on every periodic-task tick (30 min cadence); operators compare the two implementations to verify the public surface has not drifted from the model the hedger actually uses.

curl -s https://kerne.fi/api/forecast | jq '{predictedSum, annualizedApy, lowerBound, upperBound, model}'

Forecast accuracy is bounded by the model. R² of 0.44 means the prediction explains 44% of next-day funding variance; the 80% interval is wide because the residual is real. The honest framing is that the model is publishable, the math is checkable, and the metric a depositor cares about is whether the published forecast tracks realised funding over time. We expose both, you decide.