Automated multi-exchange crypto trading
One secure dashboard for automated volume generation and manual trading across multiple exchanges, on live data.
The problem we were handed.
Traders needed automated volume generation and manual trading across multiple exchanges from a single, secure dashboard with live data.
Every exchange speaks its own dialect. Different authentication schemes, different rate limits, different symbol notation, different rounding rules on price and quantity, and very different opinions about what a WebSocket should push and how often. Collapsing all of that into one order form and one position view is most of the work — and it's the part that never shows up in a demo.
Then there's trust. The product asks a trader to hand over exchange API credentials and let software place orders on their behalf. That is a high bar. If the dashboard lags, if a fill appears late, if a key could plausibly ever reach the browser, the product is done — no amount of feature surface repairs it.
And the automation had to be genuinely unattended. Volume-generation strategies run across venues while the market moves, so they have to be configurable by a human, observable in flight, and stoppable in one click by someone who has just noticed something they don't like.
How we built it.
A MEAN-stack SaaS with an automated trading engine, REST + WebSocket exchange connectivity, Firebase Auth, real-time sync and enterprise-grade security, deployed on Google Cloud.
Automated trading engine
A Node.js engine executing configured strategies against multiple exchanges. Strategies are stored as data — parameters a trader edits, not code we redeploy. The engine owns the order lifecycle end to end: intent, placement, acknowledgement, fill, reconciliation.
- Strategy configuration as data — no deploy to change a parameter
- Client order IDs so a retry after a timeout never doubles a fill
- Per-exchange rate-limit budgets with backoff instead of blind retries
- One stop control that drains in-flight orders and reports what it found
Per-exchange connector layer
Each venue sits behind one internal interface: balances, tickers, order book, place, cancel. Everything exchange-specific — auth signing, symbol mapping, precision and fee rules, error taxonomy — stays inside its own connector. Nothing above that layer knows which exchange it is talking to.
- REST for state and orders, WebSocket for the stream
- Symbol, precision and minimum-size rules normalized at the edge
- Reconnect, resubscribe and backfill on every socket drop
- Adding a venue is a connector, not an architecture change
Real-time dashboard
An Angular front end fed by a single server-side WebSocket channel rather than a connection per exchange. The server aggregates and throttles the fan-in, so the UI updates continuously without thrashing on a volatile pair. Manual trades and automated ones flow through the same pipeline and land in the same history.
- One socket to the client, many upstream — the server does the merging
- Server-side throttling so the browser stays responsive under load
- Manual and automated orders share one path, one audit trail
Credential custody and access
Firebase Auth handles identity and sessions; authorization is checked server-side on every privileged action. Exchange credentials are encrypted at rest and decrypted only inside the engine that needs them. The browser never receives a key — it asks the server to act, and the server decides whether it may.
- Firebase Auth for identity, server-side checks for authority
- Credentials encrypted at rest, never serialized to the client
- Trading-scoped, withdrawal-disabled keys recommended at onboarding
Google Cloud deployment and observability
Deployed on Google Cloud with the engine scaled separately from the API, because the two fail in different ways and under different load. MongoDB holds orders, fills, strategy state and history. The interesting failures in a trading system are quiet ones, so the logging targets them specifically.
- Engine and API deployed and scaled independently
- MongoDB for orders, fills, strategy config and audit history
- Alerts on socket health, order rejects and stalled streams
Architecture & integrations.
What it delivered.
Trading systems fail quietly. A socket that stops delivering without disconnecting, a rounding rule that shaves a decimal off every order, a retry that places the same trade twice — none of those throw an exception. So the engineering that mattered here wasn't the strategy logic; it was the connector discipline and the instrumentation that make a silent failure visible while it's still cheap. Production isn't a finish line — it's a contract.
Questions this project raises.
Yes. Each venue sits behind one internal connector interface, so adding one is contained work rather than a re-architecture. Sandbox credentials and the venue's own docs are usually enough for us to start and give you a real estimate.
Encrypted at rest on the server, decrypted only inside the trading engine. The browser never holds a key and never transmits one. We also recommend keys scoped to trading with withdrawals disabled, so the worst case stays bounded by design rather than by trust.
Most of it. The engine, the aggregated socket layer and the credential custody are venue-agnostic. What changes per market is the connector — auth signing, symbol notation, precision and fee rules — which is exactly why that logic stays inside its own file.
The first exchange plus a working dashboard is the expensive part; each connector after that is far smaller. This one ran project-based with fixed scope and milestone billing. We put the sequence in writing first, including what we'd cut to hold a date.
That's what the instrumentation is for: alerts on socket health, order rejects and stalled streams, strategies editable as data rather than as code, and one stop control that drains in-flight orders. Code, infrastructure config and docs are yours outright.
Related work.
Have a problem shaped like this one?
Tell us what's in the way. You'll hear back from a senior engineer within one business day.