- exchange
- Cryptocurrency & Fintech
WazirX: wallet and KYC infrastructure for a crypto exchange
Hot, warm and cold wallet tiers behind a single custody API, with automated document and liveness checks replacing a manual verification queue.
- Blockchain Engineering
- Security Infrastructure
- Full-Stack Development
At a glance
- Sector
- Cryptocurrency & Fintech
- Type
- exchange
- Services
- Blockchain Engineering · Security Infrastructure · Full-Stack Development
The problem
What it had to solve
The platform strained during market volatility, with latency in order matching and a backlog in user verification. Managing private keys at scale while a manual KYC process ran for days was holding back onboarding at exactly the moments when new traders arrived.
Speed of onboarding is a competitive position in crypto, and the compliance floor underneath it keeps moving. The client needed to get off a monolith and onto a high-availability, microservices-led architecture that could absorb volatility-driven traffic while still satisfying AML and CTF obligations.
What we built
How it works
We implemented a distributed Node.js microservices architecture built around event-driven processing, with a Redis caching layer serving real-time order books and a vertically partitioned Postgres database holding the immutable transaction log.
Security and scale pull against each other in custody, so the wallet infrastructure was tiered rather than unified: hot wallets for instant liquidity, warm wallets as an operational buffer, and air-gapped cold storage for long-term holdings, all reached through one Wallet-as-a-Service API.
Calls we would still defend
Automated OCR-based KYC — an AI-driven verification engine that reads identity documents with computer vision and runs a liveness check, so a human reviewer sees the exceptions rather than every application.
Multi-signature authorisation — m-of-n multi-sig on large-value withdrawals, so no one key or one operator can move funds alone.
CQRS — command query responsibility segregation splits trade execution from account-balance lookups, which takes read contention off the write path during volatility.
Built with
Node.js (TypeScript)
Selected for its non-blocking I/O model, which is essential for handling thousands of concurrent WebSocket connections for real-time trading.
Postgres (ACID Compliant)
ACID guarantees on the ledger, so a balance and the transactions that produced it cannot disagree.
Redis (Pub/Sub)
Used as the primary engine for high-speed order matching and real-time event broadcasting to millions of users.
AWS HSM / KMS
Hardware-held cryptographic keys, so signing happens inside the module and the key material stays there.
Where it landed
What the build changed
3
Wallet tiers
hot, warm and cold behind one custody API
m-of-n
Withdrawal authorisation
multi-signature, so no single key or operator can move funds alone
Automated
KYC
OCR document reading plus a liveness check, replacing a manual queue
FAQ
The questions this build raises
What was actually built, the constraints it had to meet, and how it holds up in use.
It separates key management from application logic. Multi-party computation and hardware security modules hold the key material, so a compromise in the application layer does not hand an attacker the keys — it still has to get past custody, which is where the multi-sig authorisation sits.
Yes. The verification engine reads a wide range of document formats and routes AML checks to the databases for the applicant's region, which is what makes cross-border expansion a configuration change rather than a rebuild.
Horizontal sharding plus read replicas on Postgres, with Redis absorbing the hot reads so the primary handles writes. The CQRS split does most of the work here: balance lookups never queue behind trade execution.
Keep looking
Other builds, taken apart the same way
defi
Bru Finance
Agriculture & DeFi
dex
tanX
Decentralized Finance