Case 01TetherLand
Crypto wallet & transaction infrastructure
Five years building a crypto exchange's TRON wallet and transaction infrastructure — balances reconciled to the cent.
- Role
- CTO & Full-Stack Developer — four roles, React Native dev to senior back-end
- Timeline
- Jul 2020 – Oct 2025 · 5 yrs 4 mos
- Status
- In production
- Stack
- TypeScriptNode.jsTRON APIsMySQLDockerReact
The problem
TetherLand needed custody-grade wallet infrastructure on the TRON network: users deposit and withdraw USDT and TRX, and every movement has to be tracked from mempool to confirmation and reflected in user balances — exactly, every time.
On an exchange, the wallet system is the product. A missed deposit, a double-processed withdrawal, or a balance that drifts from on-chain reality doesn't create a bug ticket — it costs someone money and burns trust that never fully returns.
Constraints
- 01
Real user funds from day one — no staging period where mistakes were cheap.
- 02
The TRON network doesn't wait: deposits arrive whether or not your indexer is healthy, so recovery and catch-up paths mattered as much as the happy path.
- 03
Long horizon: the same system had to survive five years of product pivots, new features, and my own role changing four times around it.
What I built
Wallet lifecycle management on TRON APIs: address generation, deposit detection, withdrawal processing, and transaction-state tracking keyed by txid from broadcast to confirmation.
A reconciliation process that continuously matches internal balances against on-chain history, so the books and the chain never silently drift apart — the résumé line "reconciled to the cent" was the operating standard, not a slogan.
The payment and account infrastructure underneath 9+ TetherLand products — web apps, public APIs, and internal tools all drawing on the same wallet core.
As CTO, the technical direction for all of it: architecture, schema design, deployment (Docker on Linux servers), and the engineering decisions across five years of shipping.
The hard decision
The chain is the source of truth — the database is a claim
The tempting design treats your database as reality and the blockchain as an external service. It's simpler right up until a retried job or a dropped webhook makes the two disagree, and then you have no principled way to decide which is right.
We inverted it: on-chain history is authoritative, internal balances are a derived view that must be re-derivable at any time, and every state-changing operation is written to be safely repeatable — a withdrawal retried twice must move money exactly once. That discipline costs more up front and pays for itself with every incident that becomes a non-event.
Security & reliability
Key material treated as radioactive: isolated from application code and never present in repositories or logs.
Idempotent money movement — retries, crashes, and duplicate triggers cannot double-spend.
Continuous reconciliation as a safety net: drift between chain and ledger surfaces as an alert, not a customer complaint.
Deployment discipline on our own Linux infrastructure: Docker images, repeatable releases, and a rollback path.
Results
- shipping at TetherLand
- 5y 4m
- products on the same infrastructure
- 9+
- roles: RN dev → Sr Front-End → CTO → Sr Back-End
- 4
- the reconciliation tolerance
- $0.01
What I'd do differently
I'd introduce a formal double-entry ledger schema from the first month instead of evolving toward one — we got there, but the migration under live traffic was work a week of early design would have avoided.