Primary routes

Request life cycle

1. 1

   Portfolio fetch

   The provider reads the requested wallet and network, then asks `/api/portfolio` for a current snapshot backed by the configured RPC and latest stored proof when available.

2. 2

   Optimization request

   A client action posts the portfolio map and prompt to `/api/agent/optimize`, which returns an optimization payload via a response header and streams narrative text through the body.

3. 3

   Proof persistence

   The client follows up with a POST to `/api/0g/store` carrying the final decision payload, network key, and wallet address.

4. 4

   Hydration and replay

   Later, `/api/agent/latest`, `/api/history`, and `/api/0g/proof` all read from the stored proof record instead of recomputing everything from scratch.

Provider priority and fallback rules

• Optimization narrative prioritizes 0G Compute when the active network credentials are configured.
• If the compute provider is unavailable, the app still produces a deterministic narrative so the UX does not collapse.
• The snapshot builder stays available locally, which keeps the product usable even before full mainnet cutover.
• This fallback behavior is intentional and is surfaced honestly in the UI.

Stored decision payload shape

{
  "current_apy": 12.38,
  "optimized_apy": 23.84,
  "yield_increase": 2356.41,
  "yield_increase_pct": 23.61,
  "recommended": "SaucerSwap LP",
  "confidence": 96,
  "executionSeconds": 8.42,
  "estimatedAnnualGain": 2356.41,
  "totalPortfolio": 24570.25,
  "reasoning": "YieldBoost rerouted idle stablecoin..."
}