Technical Reference

Architecture

The structure of the Next.js App Router project and the main moving parts behind the user experience.

Framework

Next.js App Router

State Core

AppDataProvider

Proof Store

Vercel KV primary store with local file fallback

component-map

Component map

Layer

File family

Responsibility

Notes

Layout shell

`app/layout.tsx` + sidebar

Global structure and workspace chrome

All pages inherit the same product frame

Client state

`components/providers/AppDataProvider.tsx`

Portfolio and optimization context

Central runtime state hub

Feature pages

`app/*/page.tsx` + feature components

Dashboard, Boost, portfolio, and support routes

Docs adds a separate documentation shell

API routes

`app/api/**`

Portfolio, optimization, 0G storage, proof lookup, feature page data

Rate limited through middleware

Server helpers

`lib/server/**`

Live portfolio, runtime store, feature-page loaders

Separates server concerns from view code

text-diagram

Text diagram of the architecture

High-level data flow

text

Wallet / Watch Address
        |
        v
Sidebar wallet state -> AppDataProvider -> /api/portfolio
        |
        v
Dashboard / Boost page -> /api/agent/optimize
        |
        v
Client receives optimization payload + streamed narrative
        |
        v
/api/0g/store -> 0G SDK upload -> optional ProofRegistry write
        |
        v
runtime-store (KV or local file)
        |
        v
History / proof modal / /api/agent/latest / /api/0g/proof

state-behavior

Why the provider layer matters

The provider layer keeps wallet context, live portfolio state, optimization progress, streaming narrative, and the latest result synchronized across pages.

That is why a single completed run can appear immediately in the dashboard panels, the Boost page, and the proof modal without separate manual refresh steps.

docs-architecture

How the documentation feature fits in

The docs center lives under `app/docs` and uses regular React components with semantic HTML. There is no markdown renderer and no MDX compilation layer in this implementation.

Navigation, page content, and next/previous relationships are derived from typed docs metadata so the docs remain easy to extend while staying product-styled.