Private Liquidity Trading Platform

Most crypto-exchange startups die not from a missing feature but from the integration tax — six months of stitching together a wallet service, a matching engine, an admin panel, a Kafka bus, three blockchain integrations, and an SMTP queue before a single user can register. BitExchange is the integrated baseline that skips that tax: 18 Docker containers, one master .env, one command to launch the whole exchange — built for SaaS operators who deploy a fresh instance per client.

The problem it solves

Standing up a crypto brokerage means standing up roughly fifteen services that must agree on user IDs, balances, prices, and confirmations across three blockchains. The standard outcome: a senior team burns six to nine months and $250K-500K on the integration before the first real deposit. The alternative — a vendor exchange platform — charges $5K-50K per month plus a per-trade revenue share, owns the operator's user data, and can disable the deployment unilaterally if the upstream relationship sours.

The hidden cost is worse than the cash. Most off-the-shelf exchange platforms are single-tenant SaaS that cannot be relocated to a new cloud or jurisdiction, cannot be handed off to a client, and quietly leak operator margin into the vendor's revenue share. Per-client white-labeling is either impossible or billed as a separate license per client. The operator who wanted to run five regional brokerages now has five vendor contracts, five admin consoles, and zero ability to migrate. BitExchange inverts that: every deployment is a self-contained Docker stack on the operator's own server, owned end-to-end.

Who needs this most

• SaaS operators serving regional crypto brokerages — typically one-to-five-person teams running deployments per client. The moment this hurts: every onboarding call where the next client asks "can you run a copy with our brand and our domain?" and the answer involves a fork, a config sweep, and a six-week setup.
• Founders building a B-Book brokerage in a single jurisdiction (Eastern Europe, LATAM, SEA, MENA) with retail demand validated but no engineering team large enough to build the platform. The moment this hurts: they have signed letters of intent for the first thousand users and the build is still six months out.
• Existing payment-rails or fintech operators bolting a crypto rail onto an existing customer base who want crypto deposit/withdraw and spread trading without rewriting their fiat backbone. The moment this hurts: the quarterly board review where the crypto question keeps coming up and the answer is still "twelve to eighteen months" or "let's buy a third-party widget."

The solution — in plain terms

BitExchange is a complete, deployable crypto trading platform that ships as one Docker Compose stack. A technically literate operator follows the README, edits one .env file, and runs ./start_all.sh. Within an hour, three URLs are live: a public marketing landing page, a trading platform for end users, and an admin panel for the operator. Behind those URLs, eighteen services handle every step an exchange needs — registration with email verification, profile and role management, wallet generation across Bitcoin, Ethereum, and TRON, deposit detection on each chain, balance accounting, order execution against live Binance prices, withdrawal processing, referral payouts, and real-time WebSocket price feeds.

Operationally, the platform runs on a single VPS for the first five thousand users. PostgreSQL holds all state. Kafka coordinates async work between services. Redis caches. Three Next.js 15 frontends serve users, admins, and visitors. Backend services split between NestJS — for Auth, Profile, Withdraw, and Referrals — and FastAPI for Wallet, Balance, Treasury, Trade, Analysis, and Monitor. Wallet private keys are encrypted with AWS KMS at rest and never leave the wallet service. Trading uses a B-Book model: orders match internally in PostgreSQL against live Binance reference prices, so the operator captures the spread without standing up a matching engine or maintaining an upstream exchange relationship.

Replacing this stack from scratch would mean integrating roughly $250K-500K of bespoke engineering over a two-quarter senior team build. BitExchange ships that baseline configured, containerized, and runnable today — and re-deployable per client in an afternoon.

Value delivered — what you get

• Skip the $250K-500K integration build and the six-to-nine-month wait — eighteen containers, one .env, one launch script. A deployment that would consume a senior team for two quarters is a one-evening setup.
• Replace vendor exchange platforms charging $5K-50K per month plus revenue share — self-hosted, no per-trade fee paid upstream, no third party that can disable the deployment.
• Per-client tenancy via deployment isolation, not row-level tags — each client gets their own Docker stack, their own database, their own wallets. No cross-tenant data leakage risk, no shared-key blast radius, easy to migrate or hand off.
• Multi-chain custody built into the deployment — Bitcoin, Ethereum ERC-20, and TRON TRC-20 with USDC and USDT deposits, AWS KMS-encrypted private keys, and a two-hop privacy-mixing path from user wallet through intermediate wallets to a corporate cold address.
• B-Book economics from day one — orders match internally against live Binance prices on six pairs (BTC, ETH, SOL, BNB, DOGE, XRP). Operator earns the spread; no external exchange API key to rotate, no order-flow leakage.
• Rebrand a deployment in minutes, not days — PLATFORM_NAME, PLATFORM_DOMAIN, logo paths, support email, and CORS origins all live in one .env. One container rebuild ships the new brand end-to-end across all three frontends.
• Full role hierarchy with JWT-embedded RBAC — user / moderator / admin / superadmin baked into tokens. The first superadmin is bootstrapped from SUPERADMIN_EMAILS on container start; role changes flow through an authenticated REST API. No default-admin-password risk and no separate identity provider to integrate.
• Documented capacity baseline up to 100K users — a thirty-page technical audit covers every service's connection pool, Kafka topic, and bottleneck, so the operator knows exactly what 2x, 5x, 10x, and 50x scaling cost in dollars and engineering days.

Where it delivers outsized value

• Per-client SaaS operators in crypto-friendly jurisdictions — Eastern Europe, LATAM, SEA, and MENA, where running a single regional brokerage is viable and the regulatory cost of a multi-tenant exchange is prohibitive. Deployment-per-client isolation maps directly to the per-jurisdiction operating model and to client handoff if the operator exits.
• Solo founders or two-to-five-person teams validating a brokerage hypothesis — the platform is feature-complete enough to take real users on day one, but small enough that one operator can run it. A 16 GB Linode at $96 per month covers the first thousand customers; a tuned 32 GB box at around $300 per month carries the deployment to roughly 5,000 concurrent users before any architecture change is needed.
• Existing fintech or payments operators bolting a crypto adjacency — the admin panel, withdrawal workflow, and profile service drop into operating processes that already exist for fiat. The crypto layer does not need to be rebuilt against the fiat backbone; it lives alongside it on its own Docker stack with its own database.

Distinctive features — why this over the alternatives

• One .env, one stack, one command — the README is the only onboarding document. Setup is ./start_all.sh. No Terraform, no Helm chart, no service-mesh learning curve. The operator who deploys this does not need a Kubernetes background.
• Deployment isolation as the tenancy model — each client deployment is its own Docker volume, database, and wallet set. There is no multi-tenant row to leak across, no shared key pool, no "tenant X queried tenant Y's balance" failure mode. Audit, failover, and handoff are per-deployment.
• B-Book matching against live Binance reference prices — the operator captures the spread, holds custody of the float, and never holds an upstream exchange API key. Liquidation, take-profit, and stop-loss run server-side on a five-second loop against the live feed.
• Multi-chain custody with privacy mixing first-class — funds flow user wallet → two intermediate wallets → corporate cold wallet, with configurable hop count and inter-hop delay. The mixing path lives in the Treasury service, not in fragile shell scripts pasted between deployments.
• Sensible role hierarchy for small-team ops — superadmin can promote any user via a single REST call, the first superadmin is bootstrapped from .env on container start, and the admin panel honors JWT-embedded roles without a separate identity provider.
• Honest scaling roadmap, not a marketing chart — the technical-spec document names the exact ten bottlenecks that block the next order of magnitude (Gmail SMTP, in-memory verification codes, PostgreSQL max_connections, BTC monitor API, PnL updater, single Kafka broker, ETH full-history scan) with the cost and the engineering hours to fix each.

Under the hood — built to last

The runtime is conservative on purpose. Node 18 and 20 for NestJS services, Python 3.11 for FastAPI services, PostgreSQL 15 for state, Kafka 5.2 with ZooKeeper 3.4 for async coordination, Redis 7 for caching — all mature, all widely supported, no exotic dependencies. Frontends are Next.js 15 on React 18 with TailwindCSS and shadcn/ui. Everything ships as multi-stage Docker images orchestrated by Docker Compose, so the stack stands up on any Linux host with 8 to 16 GB of RAM. Wallet private keys are encrypted with AWS KMS; no key material lives in the codebase or the .env. Self-hostable end-to-end, no SaaS dependency on any critical path.

Current maturity

The platform runs in production across multiple white-labeled deployments. The Docker containerization effort that produced the current single-command launch shape was completed in February 2026; the underlying microservices pre-date that consolidation by several months. Roughly 128,000 lines of code across Python and TypeScript span eighteen services — fifteen application services plus four infrastructure components and three Next.js frontends. The documented capacity baseline is 200-500 concurrent users and 50,000-100,000 registered users on a single 16 GB server with stock configuration; the realistic ceiling without architecture changes is roughly 5,000 concurrent users and 100,000 registrations after PostgreSQL tuning and connection-pool adjustments. Per-deployment cost runs $96-192 per month at startup scale, scaling to $400-600 per month at five-times capacity. A companion treasury console ships alongside each deployment to handle the operator's outbound fund movements without touching the exchange code.

Roadmap — what's next

The next track is operator tooling alongside the exchange rather than features inside it. A persona-based wallet manager built to scale beyond the treasury model to fifty-to-a-hundred wallets per persona, with key generation and signing handled outside the exchange runtime, is the next deliverable shipped alongside each client deployment. On the platform itself, the priority gaps surfaced in the technical audit are an asynchronous email queue (to lift the current 350-emails-per-day Gmail bottleneck into paid SMTP throughput), Redis-backed verification codes (to allow horizontal scaling of the auth service), and incremental block scanning for the ETH and TRON monitors (to cut deposit-detection latency as the address count grows).

The longer arc connects BitExchange into a multi-deployment SaaS control plane: a single operator console that shows the health, balances, and customer counts of every client deployment without breaking the per-deployment isolation contract. The 50x scaling path is documented; the engineering work to get there is sequenced rather than speculative.

Working with the architect

BitExchange is available in three engagement modes for serious operators. A founder or fintech can commission a custom build modeled on this architecture, tuned to a specific jurisdiction, brand, and asset mix — the work is well-understood and bounded. An existing trading or fintech team can engage on extension to bolt this stack onto an existing customer base, adding crypto deposit/withdraw and B-Book trading without rewriting their fiat backbone. And operators planning their own equivalent build can engage in strategic advisory on architecture, hosting, capacity planning, and the regulatory operating model for per-client SaaS deployment. Reach out via sintegrium.io or LinkedIn for a 30-minute scoping call.

---

Built by Yurii Staryk · Solution Ecosystem Architect