Hunter — System Architecture

Authoritative, as-built architecture documentation for the Hunter platform.

Everything here describes code that exists and runs today. Where something is planned but not yet built it is explicitly marked [PLANNED].

Launch status. The platform is pre-launch. The Solidity contracts in §06 are written and tested but not deployed to any network, and no revenue is flowing through them yet — mainnet deployment is gated behind an external audit. Read every description of on-chain value flow as the designed behaviour, not as something operating today.

Read in this order

# Document Answers
01 System Context What is Hunter, who uses it, what does it touch?
02 Components What services exist, what does each own, how do they scale?
03 Runtime Flows What actually happens on a request, end to end?
04 Data Architecture Which store owns which data, and for how long?
05 Interface Contracts The four contracts that let teams work independently
06 On-chain Architecture Contracts, roles, events, and where the money goes
07 Deployment & Environments How it is built, shipped, and run
08 Security & Privacy Authn/authz, trust boundaries, threat model, guarantees
09 Observability & SLOs How we know it works
10 Decision Log (ADRs) Why it is built this way

The system in one paragraph

Hunter is an autonomous crypto-intelligence platform. A marketing site sends users into a web3 terminal where they authenticate with their wallet (SIWE), gain an access tier by holding, locking or subscribing with $DRPXBT, and receive an API key. That key buys inference from our own GPU cluster through an OpenAI-compatible gateway that enforces tiers and meters credits. Behind the terminal, an agent built on LangGraph runs autonomous research pipelines using a plane of MCP tool servers, publishes signals with a public accuracy record, and sells its work to other agents. Revenue is designed to route through on-chain contracts that buy back and burn the token, pay stakers, and fund the treasury — those contracts are built and tested but not yet deployed.

Architectural principles

  1. Interfaces before services. Four contracts (§05) are frozen; anything behind them can be rebuilt without coordination.
  2. The chain is the source of truth for entitlement, never a database. The database is a cache of chain state.
  3. Privacy is a product feature, not a policy. Prompts are not persisted by default; the usage ledger records token counts only, and retention is opt-in per key (§08).
  4. Revenue is designed to be verifiable. Value flows through contracts that emit events rather than through spreadsheets (§06).
  5. Every service is independently deployable, has a Dockerfile, and gates merges on CI (§07).
  6. Agent tools are MCP servers only. No bespoke tool code inside the agent, so tools are reusable and independently deployable (§05).

Repository map

Plane Repository Role
Marketing drpxbt.xyz Public site, live flywheel dashboard
App hunter-terminal Web3 app: SIWE, tiers, API keys, dashboards, chat
Platform hunter-gateway Model gateway: OpenAI-compatible API, keys, metering, x402
Platform hunter-platform Platform API: accounts, entitlements, signal track record
Agent hunter-agent LangGraph agent, pipelines, ACP seller surface
Agent hunter-mcps Tool plane: MCP servers (Twitter, Hyperliquid, …)
Agent hunter-workers Orchestration: cron, queues, indexers
Data hunter-scrapers Ingestion into the data plane (incl. the airdropio module)
Media hunter-podcast Briefing generation; playback lives in the terminal
Chain hunter-contracts Contracts: TierLock, Staking, Subscription, Splitter, Buyback
Product hunter-rescue Recovery desks: withdraw from a sunset protocol's live contracts
Infra hunter-demo Full-stack local environment
Docs hunter-docs This documentation site: litepaper, architecture, brand

This directory is strictly the engineering view. The product-level summary is in the litepaper.

HUNTER · $DRPXBT · drpxbt.xyz edit this page