BullionFX
A hybrid CEX for tokenized gold that uses the Stellar Blockchain as a high-speed internal settlement engine.
Architecture Overview
A 'Dual-Ledger' architecture. A NestJS backend handles the high-frequency Orderbook and matching via WebSockets, while the actual settlement of assets occurs instantly on a private Stellar network to ensure immutable transaction history.
The Challenges
Problem
We held user funds in a hot wallet to allow automated withdrawals, which is a massive security risk. If the server is hacked, the private key is stolen.
Solution
Implemented a 'Keyless' architecture using Shamir's Secret Sharing (2-of-3 threshold). The private key was split into shards encrypted via distinct AWS KMS profiles across different organizational accounts (BullionFX + BlockApex). The key is reconstructed *only* in ephemeral memory for milliseconds during signing and never touches the disk.
shamir-secret-algo.service.ts
Problem
We had three sources of truth: The EVM Contract (Deposits), The Stellar Ledger (Internal Settlement), and MongoDB (Order History). Keeping them in sync during network failures was critical.
Solution
Designed an 'Atomic Settlement' pipeline. Deposit events on Ethereum trigger a localized 'Mint' on Stellar. Withdrawals use a state machine (PENDING → PROCESSED) that locks funds on Stellar before releasing them on EVM. If any step fails, the system rolls back to the last checkpoint, ensuring no 'Phantom Money' is ever created.
withdraw-funds.service.ts
Problem
Users deposit fiat/crypto to the exchange by submitting a server-signed message to the smart contract. A malicious user could capture this signature and replay it to double-credit their account.
Solution
Implemented strict EIP-712 Typed Data signing. The contract maintains a `_signatureLog` mapping. Every deposit signature includes a unique `Nonce` and `Amount`. The contract verifies the signature on-chain and instantly invalidates the nonce, making the signature useless for any future attempts.
BullionfxCex.sol
Problem
Traders expect 'Binance-like' speed. Broadcasting orderbook updates and OHLC candles to thousands of users via HTTP polling would crash the server.
Solution
Built a high-performance WebSocket Gateway using Socket.io with Room Partitioning (e.g., `join('GOLD-USD')`). Market data is pushed via an event-driven emitter only when the orderbook state changes. OHLC candles are computed via a MongoDB Aggregation Pipeline that bucketizes trades into time intervals on the fly.
orderbook.gateway.service.ts