components/entities/vault/overview/VaultOverviewBlockIRM.vue (1)

615-622: 🚀 Performance & Scalability | 🔵 Trivial | 🏗️ Heavy lift

Lazy-load the IRM chart when this section starts collapsed.

This accordion only hides the panel DOM; it does not stop the existing onMounted/watch-driven VaultLens and UtilsLens reads from running immediately. That turns a default-collapsed technical section into eager off-screen RPC + chart work. Consider wiring the fetch/render path to the expanded state, or hoisting the accordion above this component so the IRM body mounts only after expansion.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@components/entities/vault/overview/VaultOverviewBlockIRM.vue` around lines
615 - 622, The Interest rate model section currently mounts its
VaultLens/UtilsLens data and chart work even when the accordion starts
collapsed, so make the IRM body lazy by tying the fetch/render path to the
expanded state in VaultOverviewBlockIRM and the accordion section around
hasValidIRM/defaultOpen. Update the onMounted/watch-driven reads so they only
run after expansion, or move the conditional mounting above this component so
the IRM content does not mount until the section is opened.

components/entities/vault/overview/VaultOverviewBlockOracleAdapters.vue (1)

305-309: 🚀 Performance & Scalability | 🔵 Trivial | 🏗️ Heavy lift

Keep oracle adapter loading behind expansion for collapsed views.

After this refactor the section can start closed, but loadOracleAdapter(...) and useOracleAdapterPrices(...) still fan out as soon as the component mounts. In the pair overview this block is explicitly default-closed, so users still pay the metadata/price-loading cost before opening it. Please gate that work on the accordion’s open state, or move the accordion above this component so the expensive body mounts lazily.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@components/entities/vault/overview/VaultOverviewBlockOracleAdapters.vue`
around lines 305 - 309, The Oracle adapters section still triggers eager
metadata/price loading on mount even when the accordion is collapsed. Gate the
expensive work in VaultOverviewBlockOracleAdapters.vue behind the accordion’s
open state, or restructure so the body that calls loadOracleAdapter(...) and
useOracleAdapterPrices(...) only mounts when the VaultOverviewAccordionSection
is expanded. Keep the change centered on the accordion/open-state logic and the
Oracle adapters loading flow.

components/entities/vault/overview/earn/VaultOverviewEarnBlockStats.vue (1)

48-61: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Duplicated logic vs. VaultOverviewEarnBlockExposure.vue; recomputation not memoized.

getStrategyMarketSource (lines 48-61) is duplicated verbatim in VaultOverviewEarnBlockExposure.vue (lines 167-180). Also, getStrategyCollateralGroups (73-80) is called directly inside both hasUnavailableExposureSplit and exposureDisplayItems without caching per strategy — unlike the sibling file, which memoizes results in a collateralExposureGroupsByStrategy computed.

Consider extracting getStrategyMarketSource into a shared util (e.g. utils/vault/strategy-market-source.ts) and memoizing collateral groups per strategy similarly to the Exposure block file.

Also applies to: 73-80, 102-122

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@components/entities/vault/overview/earn/VaultOverviewEarnBlockStats.vue`
around lines 48 - 61, `getStrategyMarketSource` in
`VaultOverviewEarnBlockStats.vue` is duplicated in
`VaultOverviewEarnBlockExposure.vue`, so extract that shared market-link builder
into a common utility (for example a strategy market source helper) and reuse it
from both components. Also memoize `getStrategyCollateralGroups` results per
strategy, following the `collateralExposureGroupsByStrategy` pattern from the
sibling component, and update `hasUnavailableExposureSplit` and
`exposureDisplayItems` to read from the cached groups instead of recomputing
repeatedly.

components/entities/vault/overview/earn/VaultOverviewEarnBlockExposure.vue (1)

155-219: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Mixed address-normalization conventions.

collateralExposureGroupsByStrategy keys by getAddress(...) (checksummed), while exposureUsdPrices/unavailableExposureUsdPrices key by .toLowerCase(). Each map is internally consistent, but the mixed convention within the same file is easy to regress when adding new lookups.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@components/entities/vault/overview/earn/VaultOverviewEarnBlockExposure.vue`
around lines 155 - 219, The exposure state and lookup logic in
VaultOverviewEarnBlockExposure.vue mixes checksummed and lowercased address keys
across related helpers. Standardize the keying convention used by
getStrategyExposureValueState, collateralExposureGroupsByStrategy, and
getStrategyExposureDisplayItems so the same address normalization is applied
consistently for all maps and lookups. Use the existing symbols getAddress,
strategyVault.address, exposureUsdPrices, and unavailableExposureUsdPrices to
align the convention and avoid future lookup regressions.

utils/vault/open-interest.ts (1)

71-79: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

Linear scan + re-normalization on every lookup — consider a memoized lookup map.

findOpenInterestMapForVault re-normalizes every key of data on each call. It's invoked once per vault row (e.g. from VaultItem.vue's collateralExposureGroups and VaultOverviewBlockOpenInterest.vue), so rendering a list of N borrowable vaults against an M-entry OI map costs O(N·M) checksum computations instead of O(N+M).

Consider building a normalized-address → sub-map cache once per data change (e.g., memoize keyed off object identity of data) and doing O(1) lookups per vault.

♻️ Example approach

+const normalizedMapCache = new WeakMap<object, Map<string, Record<string, number>>>()
+
+const getNormalizedMap = (data: Record<string, Record<string, number>>) => {
+  let cached = normalizedMapCache.get(data)
+  if (!cached) {
+    cached = new Map(Object.entries(data).map(([addr, v]) => [normalizeOpenInterestAddress(addr), v]))
+    normalizedMapCache.set(data, cached)
+  }
+  return cached
+}
+
 export const findOpenInterestMapForVault = (
   data: Record<string, Record<string, number>> | undefined,
   vaultAddress: string,
 ): Record<string, number> => {
   if (!data) return {}
-  const normalizedVault = normalizeOpenInterestAddress(vaultAddress)
-  const entry = Object.entries(data).find(([address]) => normalizeOpenInterestAddress(address) === normalizedVault)
-  return entry?.[1] ?? {}
+  return getNormalizedMap(data).get(normalizeOpenInterestAddress(vaultAddress)) ?? {}
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@utils/vault/open-interest.ts` around lines 71 - 79,
findOpenInterestMapForVault currently does a linear scan and re-normalizes every
address on each lookup, which makes repeated vault rendering unnecessarily
expensive. Refactor this helper to use a memoized normalized-address lookup map
keyed by the identity of data, so the normalization work is done once per data
change and subsequent calls are O(1). Keep the fix localized around
findOpenInterestMapForVault and the normalizeOpenInterestAddress flow,
preserving the same return shape.

utils/vault/collateral-exposure.ts (1)

46-54: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Export the address-lookup helper to avoid triplicated logic.

readOpenInterestUsd is the single, checksum-safe implementation for matching a collateral address against the openInterestUsdByCollateral map, but it isn't exported. VaultCollateralExposureModal.vue and VaultOverviewBlockBorrow.vue each reimplement the same lookup with a plain .toLowerCase() comparison instead of reusing it. Exporting it (or a small getOpenInterestUsdForCollateral wrapper) would remove the duplication and keep the normalization logic in one place.

♻️ Proposed export

-const readOpenInterestUsd = (
+export const readOpenInterestUsd = (
   openInterestUsdByCollateral: Record<string, number>,
   collateralAddress: string,
 ): number => {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@utils/vault/collateral-exposure.ts` around lines 46 - 54, Export the
address-lookup helper from collateral-exposure so the checksum-safe matching
logic lives in one place. Update readOpenInterestUsd (or add a small
getOpenInterestUsdForCollateral wrapper) in the utility module, then change
VaultCollateralExposureModal.vue and VaultOverviewBlockBorrow.vue to call that
shared helper instead of reimplementing the .toLowerCase() lookup. Keep
normalizeAddress-based matching as the single source of truth.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes