BotifyDocs

System overview

Botify is a pnpm monorepo. Three application surfaces sit on top of one API and one database.

The monorepo

| App | Package | What it is | | --- | --- | --- | | Web | @botify/web | The product app: feed, launches, token pages, portfolio | | Claim | @botify/claim | A one-page airdrop claim surface with its own lifetime | | Docs | @botify/docs | This documentation site | | API | @botify/api | Express service: routes, services, the signal pipeline, the venue layer |

The web and claim apps are Next.js App Router on React 19 and Tailwind v4. The API is Express 5 and TypeScript. Everything shares one strict base TypeScript config, and the workspace is apps/* plus a reserved packages/*.

The data model

The database is the audit log. Four models carry the core loop:

  • A Bot scans Stocks and records a Signal for each observation, passed or rejected.
  • A Signal that clears its threshold produces exactly one Launch: a token on a bonding curve, paired against that stock's mint as the quote asset.

Rejected signals are kept. "Every decision, rejection, launch and trade is public" is a product promise, so the table behind the feed is the record that backs it.

From signal to launch

The path a launch takes through the system:

  1. Ingestion writes a queued item (today, news filtered to the watchlist).
  2. The keeper claims a pending item and runs the pipeline on it.
  3. Scoring reads the item and returns a score plus token metadata.
  4. On a pass, the pipeline generates an image, uploads metadata, and calls the launch orchestrator.
  5. The orchestrator ensures the stock's curve config exists, creates the launch, and drives the venue.
  6. A seed buy gives the new pool its first trade.

Each of these has its own page: Signal pipeline for steps 1 to 4, Launch venue for the venue itself, and RPC proxy for how the browser talks to the chain.

The RPC proxy

The browser needs a Solana RPC endpoint and a websocket for account subscriptions. Pointing it straight at the upstream provider would ship the API key to every visitor, so the key stays on the API and a proxy route forwards on the browser's behalf. Details in RPC proxy.

The file-level map

This section is the conceptual overview. The exhaustive, file-by-file map of every system lives in system_breakdown.md at the repo root, and it is kept current as the code changes.