Crypto Analytics Platform

Frameworx

Multi-source crypto analytics platform aggregating market, on-chain, prediction-market, and social signals into one analysis surface.

DockerPostgresWebSocketsNginxCloudflareAI ensembles

frameworx.site

The problem

Crypto research is spread across a dozen dashboards — price, on-chain flows, prediction markets, and social chatter all live in different tools, and none of them talk to each other. I wanted one surface where a signal from any of those sources could be evaluated against the others in real time.

How it's built

Ingestion workers pull CoinGecko, TokenMetrics, DefiLlama, Polymarket, and X/ScrapingDog feeds on independent schedules
Postgres as the single store, with normalized asset identifiers so cross-source joins are cheap
An AI ensemble layer scores each asset from multiple model outputs rather than a single prompt
WebSocket fan-out pushes live updates to the client without polling
Geopolitical risk overlays derived from prediction-market and news signals
Self-hosted on a Hostinger KVM2 VPS: Docker Compose, Nginx TLS termination, Certbot renewals, Cloudflare DNS, nightly off-box pg_dump

Architecture

  X / ScrapingDog ─┐
  CoinGecko ───────┤
  TokenMetrics ────┼──> ingest workers ──> Postgres ──> AI ensemble
  DefiLlama ───────┤                          │             │
  Polymarket ──────┘                          └──> WebSocket fan-out ──> web client

  [ Cloudflare DNS ] -> [ Nginx + Certbot ] -> [ Docker Compose on KVM2 VPS ]
                                                    └─> nightly pg_dump -> off-box

Outcome

Moving off managed Postgres cut recurring cost substantially and removed the connection-limit ceiling that throttled the ingestion workers. The stack is boring on purpose: one VPS, one compose file, automated certs and backups.

At a glance

5: External data sources unified
1 VPS: Entire stack, one compose file
Nightly: Off-box backups with restore drills

Decisions & tradeoffs

Considered: Staying on managed Postgres

Chose: Self-hosted Postgres in Docker on a KVM2 VPS

Why: Connection limits were throttling the ingestion workers and recurring cost scaled with usage, not value.

Tradeoff: I now own patching, TLS renewal, and backups — so all three are automated and tested.

Considered: Client polling for fresh prices

Chose: WebSocket fan-out from the ingestion layer

Why: Polling multiplied API cost and still showed stale numbers between intervals.

Tradeoff: Reconnect and backfill logic on the client that polling would not have needed.

Considered: A single model prompt per asset

Chose: An ensemble that scores each asset from multiple model outputs

Why: One model's confident wrong answer is indistinguishable from a right one.

Tradeoff: Higher inference cost and latency per refresh cycle.

More case studies

Local SEO Toolkit