[codex] add yield splitter vault metadata

[rossgalloway]

What changed

Add yieldSplitter metadata to vault responses across the web API.

This includes:

• GraphQL schema support for Vault.yieldSplitter
• lazy GraphQL field resolution so hot top-level vault queries do not eagerly hydrate splitter data
• REST list and snapshot enrichment for yield splitters
• Katana yield-splitter discovery, dynamic contract reads, and cache handling
• targeted single-vault lookup behavior plus cache priming for snapshot refreshes

Why

Clients need a structured way to identify yield-splitter vaults and render their source vault, target vault, reward token, and strategy metadata.

The follow-up work on this branch also fixes review issues uncovered during implementation:

• degrade gracefully on chain-specific RPC failures
• avoid widening hot GraphQL paths
• keep the web app independent of repo-root YAML config loaders
• normalize zero-address optional fields
• avoid cold-path regressions in single-vault and snapshot-refresh flows

Impact

• GraphQL clients can request yieldSplitter from Vault
• REST consumers get yield-splitter metadata in list and snapshot payloads
• single-vault reads stay lazy and targeted
• snapshot refresh avoids repeated per-vault splitter misses once the cache is primed

Root cause

Yield-splitter metadata was not previously modeled in the web API, so clients had no typed way to distinguish these vaults or understand their vault-to-vault routing.

Validation

• bun test in packages/web
• bunx tsc -p tsconfig.json --noEmit in packages/web
• bun run lint in packages/web

Lint still shows the pre-existing warning in packages/web/components/LatestBlocks.tsx for an unused index variable.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
kong	Ready	Preview, Comment	Apr 9, 2026 0:08am