System architecture
A public market feed for display, an authenticated server for account truth.
On this page
The main data paths
| Path | Responsibility |
|---|---|
| Browser → Hyperliquid WebSocket | Charts, mids, mark context, BBO, depth, trades and candles |
| Browser → authenticated Iceberg API | Owned accounts, orders, collateral, checkout and payout requests |
| Iceberg API / worker → Hyperliquid | Independent fresh execution/risk inputs and funding history |
| Iceberg API / worker → PostgreSQL | Durable accounts, fills, positions, requests and immutable cash ledgers |
| Iceberg API → EVM RPC | Canonical finalized native-USDC receipt verification |
| User wallet → supported chain | The user-authorized checkout transfer |
Display projections never set an entitlement, cash balance or fill. A local transaction hash, stored order or cached account is only recovery/display information.
Runtime and deployment
The app uses React, TypeScript and App Router conventions through vinext/Vite. A standalone Node runtime on Railway supervises the HTTP server and a separate background risk/funding process. PostgreSQL is their shared durable source of truth.
The supervisor stops the service if either process exits unexpectedly. One risk worker per database remains the operating model until worker ownership is distributed with explicit leases and fencing. Multiple API replicas alone are not a proven worker-scaling design.
An independent documentation service
The documentation is pre-rendered into static HTML for each page, with a small browser bundle for local search, mobile navigation, tables and copy controls. Its dedicated lightweight static service serves those files and compressed assets.
The docs runtime does not load Privy, trading APIs, a risk worker or a database connection. Reading a guide does not query a trading account. Prices, networks and market definitions are included from the product catalogs at build time, so publishing a catalog change requires rebuilding the docs.
Identity and ownership
Privy handles email, Google and wallet sign-in. The server verifies access tokens against the app’s JWKS, issuer, audience, expiry and subject, then checks account ownership before private reads or mutations.
The public Privy App ID is client configuration. Database credentials, signing keys and other secrets do not belong in browser code. The marketing and app origins do not rely on a browser-local paid flag or an assumed shared authentication cookie.
Transactions and immutable ledgers
Owner locks serialize cross-account exposure checks. Account locks serialize cash and position mutations; per-market locks coordinate quote consumption. Decimal arithmetic is used for financial calculations.
Fills, position changes, fees, cash and quote use commit atomically. Immutable funding, margin and payout cash events support reconstruction and reconciliation. Exact request fingerprints distinguish retries from conflicting reuse of the same client ID.
These are implementation controls, not a claim of a completed independent security audit. Treasury execution and public solvency reporting remain separate work.