fix(template): align apyWindow options with api-served smoothing windows

[alexbensimon]

Closes VAU-1315 — https://linear.app/morpho-labs/issue/VAU-1315

Problem

The template ships apyWindow: "7d", but VaultV2History.avgApy/avgNetApy(lookbackHours:) cap each plotted point's smoothing at 24h. A default deployment holding V2 vaults renders a headline APY labelled 7d next to a chart the app honestly relabels 1d.

Nothing was broken or dishonest — vaultV2HistoryLookbackHours clamps the request and vaultV2HistoryApyWindow relabels the series rather than claiming a smoothing the points don't have. The problem is that the public reference implementation walks into that mismatch out of the box, and didn't expose the option Anchorage uses to avoid it.

The fix adapts the configurable options to what the API actually serves, rather than working around the gap in app code.

Changes

Add "6h" to ApyWindow (config/types.ts) and APY_WINDOW_HOURS / APY_LOOKBACK_PERIOD (common/utils/timeframe.ts). The API serves SIX_HOURS on both VaultV1LookbackPeriod and VaultV2LookbackPeriod, the fork already carries "6h" | "1d" | "7d" | "30d" and runs on 6h, and this repo's data layer was already written for it — MarketSupplyApyWindows/MarketBorrowApyWindows already carry supplyApy6h/borrowApy6h, backed by MarketState.avg* fields the schema documents as genuine 6h averages. Only the config union was narrower: an oversight in the port, not a decision.

Default apyWindow → "1d" (config/index.ts).

The ticket left 6h vs 1d open. 1d is the only window that plots at full fidelity on every surface, because the API's per-point smoothing is coarser than its current-state averages in both directions:

window	vault V1 chart	vault V2 chart	market borrow chart
6h	falls back to 1d	native	falls back to 1d
1d	native	native (= the 24h cap exactly)	native
7d	native	capped to 24h	native
30d	native	capped to 24h	native

6h matches production Anchorage, but Anchorage is a vaults-only deployment. The template ships every surface, so 6h would trade the V2 vault mismatch for two new ones. 1d has none, and is the more conventional public default.

Document the gaps at the config site (config/types.ts), so an integrator learns which windows plot natively where before shipping rather than after.

Handle the windows the API doesn't serve per surface. marketHistoryApyWindow and vaultV1HistoryApyWindow floor the configured window at 1d for the two surfaces with no sub-daily averaged series, mirroring the pre-existing vaultV2HistoryApyWindow at the other end. Established rule throughout: the tab label names the configured window (the one the headline beside it genuinely uses), and the tab description discloses the window actually plotted, whenever they differ. On the default 1d nothing diverges anywhere.

Explicitly not done

• The option set is not restricted to what V2 history serves. 7d/30d are genuinely served for headline numbers and for V1 vault and market charts. Removing them would strip real capability from V1-only deployments to work around a V2-only limitation.
• The user-facing range selector is untouched. DATA_RANGES / CHART_RANGES already align with the API. The cap is on per-point smoothing only.

Review

Ran a 4-round adversarial review loop (three independent reviewers per round, fresh each round).

Round 1 caught a real defect in my first cut: widening the union activated a previously-dead branch that mapped the "6h" key onto VaultHistory.netApy. Per the schema that is the instantaneous series — VaultHistory's averaged family starts at dailyNetApy, there is no six-hour series. A 6h deployment would have plotted an instantaneous V1 series titled Net APY (6h), undisclosed, beside a genuinely-6h headline: precisely the mislabelling this PR exists to remove, on the one value it adds. Fixed in 8a9317c via vaultV1HistoryApyWindow, per-protocol series-window selection in the chart, and dropping the now-unused netApy selection from the V1 fragment (which is what invited the mismapping).

Rounds 2–4 found no further functional defects. Their remaining findings were all comments and doc-strings asserting things the code does not do — including my own new apyWindow doc block, which had the labelling rule backwards — and are fixed in the same commit. Final round scored 4/5, 5/5, 4/5 with no blockers.

One reviewer note left deliberately unfixed, flagged here for a human call: DataChart.tsx:71 falls back to the last plotted point when totalApy is falsy, and assembleApy coerces a null APY to 0. So a genuinely-0% headline renders the series' last value under a label naming a different window. The mechanism is pre-existing and untouched by this PR; on a 6h deployment the fallback can now disagree with the label where before it couldn't. Low impact (needs a zero/absent headline) and out of scope here — happy to open a follow-up.

Validation

pnpm codegen, pnpm check:types and pnpm check all pass clean.

pnpm test locally: the 6 env-independent test files pass (83 tests); the other 11 fail in viem's HTTP transport because they fork mainnet / read the Chainalysis oracle and this machine has no RPC URLs configured (smoke.test.ts asserts MAINNET_RPC_URL_1 is defined and fails first). The same set fails identically before and after this change — none of them touch apyWindow. The change has not been verified against a green suite; that has to come from CI.

CI note

This branch is cut from main, which predates #2 (ci/pin-action-shas). The org enforces sha_pinning_required and the current workflow uses tag refs, so no vitest check can run on this PR and it will show BLOCKED against the now-required vitest status. Expected — unblocks once #2 merges and this rebases onto it. No workflow files touched here.

🤖 Generated with Claude Code

[alexbensimon]

@codex review

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
morpho-blueprint	Ready	Preview	Aug 7, 2026 4:05pm