Skip to content
Farhat Ullah.
Security

XPEERX: a multi-chain custodial crypto platform, built for mainnet

Designed and hardened a custodial crypto deposit, custody and trading platform across six chains — deposit watchers, RPC failover, sweep automation and a security-audited admin/merchant surface — from testnet through to a live mainnet launch.

Client
Self-funded fintech product (XPEERX)
Sector
Security
Stack
NestJS · Next.js · PostgreSQL · BullMQ · Redis · Bitcoin · Tron · Ethereum · BSC · Polygon · Solana
Year
2026
By Farhat UllahSenior Full Stack + AI EngineerUpdated

The problem

A custodial crypto platform has to get one thing right that almost nothing else in software does: money that arrives on-chain, unattended, has to be detected, credited and later moved correctly — across six different chains, each with its own confirmation model, RPC quirks and failure modes — without a human in the loop and without losing a cent. Get a watcher stuck, a cursor clipped, or a block skipped, and the failure isn't a bug report, it's a support ticket from someone whose deposit vanished.

What I built

XPEERX is a custodial deposit, custody and trading platform spanning Bitcoin, Tron, Ethereum, BSC, Polygon and Solana. I built the deposit-watcher infrastructure that underpins it: per-chain block-cursor persistence, broadcast/read RPC splitting, multi-provider failover with cooldown-based rotation, and tiered polling so a quiet chain doesn't burn the same budget as a busy one. Early on the watcher ran as a single sequential scan, so a stall on one chain delayed detection on every other chain behind it in the queue — I decoupled it into independent per-chain BullMQ jobs so each chain discovers and confirms deposits on its own schedule, unaffected by the others.

Around that core I built amount-based confirmation thresholds (small BTC deposits credit at one confirmation instead of six), pending-deposit visibility so a merchant can see a deposit before it's fully confirmed instead of staring at nothing, and sweep automation with a native-gas guard so ERC-20 sweeps don't fail silently for lack of gas. On the product side: a custody workflow (deposits, withdrawals, transaction history), an admin queue for verified-credit review, merchant-facing balance and check-deposit UI, OTP-based 2FA login, and a server-side-settled binary trading feature with configurable trade periods and admin-controlled plans.

Security was treated as a first-class deliverable, not a pass at the end. I ran a full infrastructure audit before going live — SSH hardened off root, no backdoors found, CORS/JWT/rate-limiting reviewed — and separately audited a Supabase-adjacent access-control question with the same "assume it's wrong until proven otherwise" posture I'd apply to a client's system. Email delivery got a two-provider failover (Resend plus Brevo) so a single provider outage doesn't silently drop OTP or notification emails, which for an auth-gated custodial product is a security property, not just reliability.

Outcome

The platform is live on mainnet across all six chains, backed by 700+ automated tests. The RPC failover work alone cut Ethereum backlog processing from roughly 750 minutes to 48 seconds and reduced infrastructure cost by over 50%, and the per-chain watcher decoupling eliminated the cross-chain cascade stalls that used to delay unrelated chains behind a single slow one.

Why it mattered

Most of what makes a custodial platform trustworthy is invisible when it's working: the deposit that got credited without anyone noticing, the RPC provider that failed over instead of paging someone at 3am, the audit that found nothing because there was nothing to find. That's the actual bar for this kind of system — not that it demos well, but that it keeps being boring under real money and real failures.

Chains in production
6
Automated tests
700+
Backdoors found in infra audit
0

Have a system that needs to work in production?

Tell me what's breaking — or what you're building.

Chat on WhatsApp