Mindshare Analyzer: Kaito AI Growth

Kaito tracks which accounts drive conversation around crypto projects. What it does not give you is history. You can see who leads mindshare today, but not how they got there — which leaders are rising, which are fading, and which projects are gaining or losing attention week over week. For a team managing 50+ projects across multiple campaigns, that gap turns strategy into guesswork.

The problem

Mindshare on Kaito is published as a live leaderboard. The data is there, but it is a snapshot. There is no API endpoint that returns "growth in mindshare for the top 100 leaders of project X over the last 30 days." You either watch the leaderboard manually and take notes, or you do not track growth at all.

For a portfolio of 50+ projects, manual tracking is not viable. You need the top-100 leaders per project, captured on a schedule, diffed against prior captures, and turned into a report someone can actually read and act on.

The approach

We built a Python service on FastAPI that runs the full pipeline: fetch, normalize, persist, diff, report. The stack is deliberately boring — requests for HTTP, openpyxl for Excel output, Jinja2 for templated reports, SQLite for storage. No message queue, no worker framework, no orchestration layer. The job is a scheduled fetch and a diff; anything heavier would be over-engineering.

The pipeline has four stages:

1. Fetch. For each tracked project, pull the current top-100 mindshare leaders from Kaito. This is the expensive step, so it runs on a schedule and caches aggressively.
2. Persist. Store each capture with a timestamp. Every fetch is an immutable snapshot — we never overwrite prior data. This is what makes growth measurable.
3. Diff. Compare the latest capture against the previous one. For each leader, compute the change in mindshare percentage and rank. New entrants and drop-offs are flagged separately.
4. Report. Render the diff into two formats: a structured JSON payload for programmatic consumption, and an Excel workbook for humans. The Excel file uses openpyxl to produce per-project sheets with conditional formatting on the growth column — green for rising, red for falling — so a portfolio manager can scan 50 projects in a few minutes.

What was built

A FastAPI application with three endpoints: trigger a fetch, generate a report for a given project, and list all tracked projects. The fetch endpoint is what a cron job hits. The report endpoint returns either JSON or Excel depending on the Accept header, so the same endpoint serves both the dashboard frontend and the analyst who wants a spreadsheet.

The Excel report is the primary deliverable. Each project gets a sheet. Rows are leaders, sorted by current mindshare. Columns: rank, handle, current mindshare, prior mindshare, absolute change, rank change. A summary sheet aggregates across all projects — total mindshare movement, biggest gainers, biggest losers — so you can see the portfolio at a glance before drilling in.

The JSON report mirrors the same structure for downstream consumption. It is what the frontend at kaito-mindshare-analyzer.vercel.app renders.

Results

• Automated mindshare analytics for 50+ projects, running on a schedule with no manual intervention.
• Excel and JSON reports generated per project and per portfolio, with growth deltas computed from immutable historical snapshots.
• Top-100 leader tracking per project, with new entrants and drop-offs flagged on every diff.

The deployment is a single FastAPI process behind Vercel's serverless runtime. The frontend is a thin Jinja2-templated view over the JSON endpoint. The whole system is small enough that the entire state — all snapshots for all 50+ projects — fits in a SQLite file that backs up in seconds.

The takeaway

Growth is a derivative, not a snapshot. You cannot measure it from a single observation; you need a time series. The system works not because it does anything clever with the data, but because it captures every observation immutably and computes the diff honestly. The Excel output matters more than the API — the person making decisions wants a spreadsheet they can sort and filter, not a JSON payload they have to parse.