[Feature] Build a protocol-wide analytics dashboard showing TVL, active pools, member growth, and transaction volume

[Sendi0011]

Getting Started

1. Fork the repository: https://github.com/JointSave-org/Joint_Save
2. Clone your fork:

git clone https://github.com/<your-username>/Joint_Save.git
cd Joint_Save

3. Create a new branch:

git checkout -b feat/protocol-analytics-dashboard

---

Overview

JointSave has no public-facing analytics page that shows overall protocol health. Users and potential integrators have no way to see how much total value is locked across all pools, how many active pools exist, member growth trends, or transaction volume over time. The factory contract tracks deployed pools via get_all_pools() but this data is never surfaced at the protocol level.

Checked frontend/app/explore/page.tsx — shows individual pool cards but no aggregate stats. The Supabase pools table has created_at and total_saved columns that could power aggregate queries, but no API route aggregates them.

This issue adds a public analytics dashboard accessible from the landing page and navbar, displaying key protocol metrics with historical charts powered by Chart.js or Recharts.

Requirements

API Changes

• New route: GET /api/analytics/protocol
  • Returns cached (5-minute TTL) aggregate metrics:
    • total_value_locked: sum of total_saved across all pools
    • active_pools: count of pools where status is not 'completed'
    • total_pools_created: count of all pools
    • total_members: distinct count of wallet addresses across all pool_members records
    • total_transactions: count of rows in pool_activity
    • pools_by_type: { rotational: N, target: N, flexible: N }
    • tvl_by_type: { rotational: X, target: X, flexible: X }
  • Historical data: daily_stats array for the last 30 days with date, tvl, new_pools, new_members, transaction_count
  • Computed from Supabase queries against pools, pool_members, and pool_activity tables
  • Rate limited with the existing readLimiter

Frontend Changes

• New page: frontend/app/analytics/page.tsx
  • Public page (no wallet connection required)
  • Hero section with 4 large metric cards: TVL, Active Pools, Total Members, Total Transactions
  • TVL trend line chart (30-day history) using Recharts
  • Pool type distribution donut chart (Rotational / Target / Flexible)
  • Daily new pools bar chart (30-day)
  • Member growth area chart (30-day)
  • All charts use a responsive grid layout (2 columns on desktop, 1 on mobile)
  • Skeleton loading states while data fetches
• New component: frontend/components/analytics/protocol-charts.tsx
  • Encapsulates all Recharts components
  • Shared color palette: Rotational=#3b82f6 (blue), Target=#8b5cf6 (purple), Flexible=#10b981 (emerald)
  • Tooltips on hover showing exact values
  • Responsive: charts resize and stack vertically below 768px
• New component: frontend/components/analytics/metric-card.tsx
  • Displays a single metric with icon, label, value, and optional trend indicator (+12% this week)
  • Animated counter on page load (counts up from 0 to final value)
• Navigation:
  • Add "Analytics" link to the landing page navbar and the dashboard sidebar
  • Add /analytics to the public routes in the layout

Dependencies

recharts@^2.12.0

Data Pipeline

• For historical data, create a Supabase Edge Function or Vercel Cron (/api/cron/snapshot-daily) that runs daily at midnight UTC and inserts a row into a new protocol_daily_snapshots table:
  • date (date, PK)
  • tvl (numeric)
  • active_pools (integer)
  • total_members (integer)
  • transaction_count (integer)
  • new_pools (integer)
  • new_members (integer)
• The analytics API reads from this snapshots table for historical charts, and computes live values for the current-day metrics

Acceptance Criteria

• /api/analytics/protocol returns all specified metrics with correct values
• Historical daily snapshots are created by the cron job
• Analytics page renders all 4 metric cards with correct values
• TVL trend chart shows 30-day history with correct data points
• Pool type distribution donut chart renders correctly
• Charts are responsive and stack on mobile
• Page loads with skeleton states before data arrives
• Animated counters count up smoothly on initial load
• Analytics link appears in navbar and dashboard sidebar
• API route is rate limited and returns within 3 seconds

[Ajibose]

I'd like to work on this.

For the API route, I'd compute the live aggregate metrics (TVL, active pools, member counts, etc.) with direct Supabase queries against pools, pool_members, and pool_activity, and cache the response for 5 minutes so the dashboard doesn't recompute these on every page load, applying the existing readLimiter on top. For total_members, I'd make sure the distinct count is actually deduplicating by wallet address across pools rather than summing per-pool member counts, since a wallet in multiple pools shouldn't be counted twice.

For historical data, the cron job (Vercel Cron or Supabase Edge Function, whichever fits the existing deploy setup better) writes one row to protocol_daily_snapshots per day at midnight UTC. The analytics API then reads snapshot rows for the 30-day history and only computes today's numbers live, rather than recomputing all 30 days on every request, which keeps the route fast and avoids the response time creeping past the 3-second target as data grows.

On the frontend, protocol-charts.tsx holds the Recharts components with the shared color palette and consistent tooltips, and metric-card.tsx handles the animated count-up, I'd drive that with a simple requestAnimationFrame-based counter rather than a heavier animation library since it's just one number ticking up. The analytics page itself is public (no wallet gate), with skeleton states shown while the initial fetch is in flight, and the chart grid collapsing to one column below 768px as specified.

For tests, I'd cover the API route's aggregate calculations against known seed data, confirm the cron job correctly inserts a snapshot row, and check the rate limiter and 3-second response constraint hold under the cached path.

[Promise278]

i have expereince with system designs and archecture i would love to work on these please assign to me

[mijinummi]

I am a full stack developer experience in building scalable systems, I can handle this

[grantfox-oss]

🦊 GrantFox — @mijinummi has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #204)
2. Your PR will be reviewed by the JointSave-org maintainers

Good luck! Track your progress on GrantFox.