Vorxis

Vorxis ingests market data, SEC filings, news wires, and social sentiment in real time. This is how the architecture works and why I made the decisions I did.

Current Status

The terminal, Kafka ingestion pipeline, and WebSocket delivery layer are built. I'm currently onboarding beta users and iterating on the AI assistant layer. If you want early access, sign up at vorxis, and request beta access.

The Problem

Modern financial workflows are fragmented. Even sophisticated traders rely on multiple disconnected tools: Bloomberg / LSEG / FactSet for institutional data, TradingView for charting, Discord / Telegram for community discussions, Twitter/X for breaking news, Reddit for sentiment, broker platforms for execution, and Excel for custom analysis.

The trader becomes the integration layer. They spend more time collecting information than acting on it.

Legacy platforms are expensive and inaccessible:

These products were built for institutions. The next generation of traders needs something different.

The Vision

Vorxis is designed to become the operating system for financial intelligence.

A user should be able to ask "Why is NVDA moving today?" and instantly receive price action analysis, breaking news, social sentiment, options flow, historical comparisons, and similar previous events.

A user should also be able to ask "Show every time AAPL dropped more than 5% after earnings since 2005" — and Vorxis returns a complete answer immediately. Not because it is fetching data live. Because Vorxis has already built the intelligence graph.

This is the long-term direction. Right now Vorxis is in Phase 1, focused on building a terminal worth using every day.

Core Product

Real-Time Market Terminal

You see NVDA dropping 4% premarket. You open Vorxis, see the options flow anomaly from yesterday, pull the SEC filing from two weeks ago that flagged the risk, and read what the community surfaced overnight — all in one place, without switching tabs. That's what the terminal is for.

Under the hood: multi-window layouts, modular workspaces, watchlists, live tickers, charts, heatmaps, alerts, options analytics, news streams, and economic calendar — all customisable, built to support both retail and institutional workflows.

AI Financial Assistant

Rather than searching manually, users interact with markets conversationally. The AI layer combines real-time data, historical market memory, news, sentiment, and technical indicators to answer questions that currently require a Bloomberg subscription and a research team.

Community Intelligence Layer

Markets are increasingly driven by crowd sentiment. Vorxis integrates a native chat system directly into the terminal — live chat rooms, stock tagging, community sentiment, and ticker-based discussions — creating a living layer of crowd intelligence inside the platform rather than across six separate tabs.

Market Memory Engine

This is Vorxis' long-term moat. Every query improves the intelligence layer. When a user asks about AAPL earnings reactions since 2005, Vorxis fetches historical data, links price action, news events, analyst revisions, and sentiment changes — then stores the structured result. The next similar request becomes near-instant.

Technical Architecture

Vorxis is designed around low-latency, high-throughput systems with four primary goals: sub-50ms streaming, massive ingestion scale, AI-ready infrastructure, and efficient long-term storage.

Frontend

Next.js + TypeScript, TailwindCSS + ShadCN UI, D3.js for charting, Three.js for visualisation. Terminal-grade UX with real-time rendering.

Backend

Go was chosen for its excellent concurrency, low latency, high performance, strong networking support, and efficient memory usage — the right fit for streaming systems where goroutines are cheap and you need thousands of concurrent WebSocket connections.

Streaming Layer

Real-time market infrastructure uses Kafka, Redis, WebSockets, and event-driven services.

Data Sources
  → Ingestion Collectors
      → Kafka Event Bus
          → Normalization + Entity Resolution
          → Enrichment Layer
              → ClickHouse (history)
              → Redis pub/sub (live channel)
                  → Go WebSocket server
                      → Terminal Delivery

This allows millions of events to be processed with minimal latency.

Why Kafka, not RabbitMQ

The central design question for Vorxis's data pipeline was what to put between the ingest layer — news wires, SEC filings, social feeds — and the consumers: the live feed, the alert engine, the chatroom tagger. Both Kafka and RabbitMQ are message brokers, but that framing misses the point. The real question is: do you need a task queue or an event log?

RabbitMQ is a task queue. A message arrives, a worker picks it up, and it disappears. That's the right model when you're dispatching email sends or processing background jobs — work that happens once and doesn't need to be revisited. But market data events aren't tasks. They're facts. The fact that Apple just filed an 8-K doesn't stop being true once one consumer has read it.

Kafka is an event log. Messages are written durably to disk and retained for a configurable window — Vorxis keeps seven days of raw events. Multiple consumers maintain independent offsets, so the live feed processor, the alert engine, and the chatroom tagger each consume the same stream at their own pace, fully decoupled. When I added AI sentiment scoring to news events three months in, I replayed the previous 30 days through it without touching any ingest code. That kind of replay is structurally impossible with RabbitMQ — those messages are gone.

Partitioning by ticker symbol is the other decisive factor. All AAPL events flow through the same Kafka partition, guaranteeing arrival order per ticker. RabbitMQ's routing is more flexible, but it doesn't give you this ordering semantic without engineering around it.

The honest tradeoff: Kafka is operationally heavier. Partition topology, offset management, schema evolution — real surface area to own. But when the events are the product — Kafka's log semantics are the right abstraction.

Database Layer

Vorxis uses multiple storage systems purpose-built for each workload.

ClickHouse

Used for time-series market data, tick data, aggregated analytics, and historical storage. ClickHouse was chosen for its extremely fast analytical queries, excellent compression, and fit for financial time-series workloads.

PostgreSQL (Neon)

Used for user accounts, billing, preferences, chat metadata, and permissions.

Redis

Used for caching, pub/sub, rate limiting, session acceleration, and hot data.

Data Ingestion

Vorxis ingests data from exchanges, market data providers, news APIs, press releases, SEC filings, social platforms (X/Twitter, Reddit), and alternative datasets.

Data arrives through distributed collectors. Collectors normalise data into a consistent internal schema — a process called entity resolution — ensuring all market intelligence connects correctly regardless of source format.

Latency Philosophy

Market intelligence loses value if it arrives too late. The infrastructure is designed around minimising latency at every stage: network proximity to data providers, efficient serialisation, in-memory caching, stream processing, WebSocket delivery, and fast query execution.

Target: Sub-50ms event-to-terminal delivery.

Long-Term Vision

Vorxis evolves in four phases.

Phase 1 — Terminal

Build a modern financial intelligence terminal: charts, news, chat, AI. This is where we are now.

Phase 2 — Data Platform

Build one of the world's largest structured market databases — market events, news, sentiment, historical reactions.

Phase 3 — Market Intelligence Engine

Enable AI-driven reasoning over decades of market history.

Find every company behaving like NVDA before major breakouts.

Phase 4 — Financial Operating System

Vorxis becomes the intelligence layer used by traders, funds, institutions, and autonomous AI agents. This is where Vorxis becomes much bigger than a terminal — but it's built on whether Phase 1 is worth using every day.

Why I Built This

At Leap Blockchain I co-founded a Solana trading platform. We were building execution tooling — fast, technically solid — but every time we needed to understand why something was moving, we were context-switching across Twitter, Discord, five browser tabs of news, and a DexScreener chart that didn't talk to any of them. The research layer was entirely manual.

That's the gap Vorxis is trying to close. Not charts — there are good charts. Not data feeds — there are good data feeds. The gap is the connective tissue between them: the thing that knows a filing happened, links it to the price move, surfaces what the community said, and remembers it so next time you don't start from zero.

I built the Kafka pipeline, the ingestion layer, and the terminal because I wanted to use them. The product I'm building is the one I needed at Leap.

Bloomberg indexed financial information for the information age. Vorxis is building the memory layer AI will use to understand global markets.