Multi-chain treasury that doesn't lose your keys

The client managed operational crypto funds across three blockchains — Ethereum, Tron, and Bitcoin. Not trading, not DeFi yield farming, just the mundane reality of moving money between wallets, funding operations, and keeping track of balances across chains. They had dozens of wallets organized into batches, each batch serving a different operational purpose, and they were managing all of it through a mix of browser extensions, CLI tools, and a spreadsheet that was perpetually out of date. The ask was straightforward: one interface to see everything, fund anything, and know where every satoshi is.

wallets and batches

We built a treasury management system that treats wallets as first-class entities. Wallets are grouped into batches, batches belong to operational categories, and each wallet tracks its balances across all supported chains in real time. The operator sees a unified dashboard — total holdings per chain, per batch, per wallet — and can drill down to individual transaction histories. Funding operations work top-down: select a batch, specify the amount and source chain, and the system handles distribution to nested wallets automatically, calculating gas fees and adjusting amounts so the intended value actually arrives.

cross-chain and bridges

Cross-chain operations were the core engineering challenge. The client needed to move funds between Ethereum and Tron regularly, occasionally bridging to Bitcoin. We integrated Allbridge SDK for cross-chain bridges, ethers.js for Ethereum operations, tronweb for Tron, and bitcoinjs-lib for Bitcoin. Each chain has its own quirks — Ethereum transactions can sit in the mempool for hours during congestion, Tron has a bandwidth/energy model instead of simple gas, and Bitcoin's UTXO model means "wallet balance" is a fundamentally different concept than on account-based chains. We abstracted these differences behind a unified operation interface, but the abstraction is intentionally leaky — operators always see chain-specific details because hiding complexity in crypto means hiding risk.

Bridge transactions deserved their own state machine. A cross-chain transfer isn't a single operation — it's a multi-step process that can take anywhere from two minutes to several hours, with no guaranteed delivery. The system tracks each bridge operation through stages: initiated, source confirmed, bridge processing, destination pending, completed. If a bridge stalls, the operator sees exactly where it stopped and gets actionable options — retry, escalate to manual intervention, or wait with a confidence estimate based on historical bridge performance. We learned early that treating bridges as fire-and-forget was a recipe for lost funds.

security keys and gas

Security architecture was non-negotiable and shaped every design decision. Private keys live exclusively in environment variables — never in the database, never in logs, never in API responses. The application loads keys at startup, holds them in memory for signing, and they exist nowhere else. Database records reference wallets by public address only. We considered hardware security modules but the operational overhead didn't match the use case — these are hot wallets for operational funds, not cold storage for reserves. The tradeoff is documented and accepted by the client.

Gas price volatility on Ethereum made cost prediction unreliable in ways that affected the product. A batch funding operation estimated at $50 in gas could cost $200 by the time it executed if the network spiked. We added a gas price oracle that checks current conditions before each operation, compares against a configurable ceiling, and pauses the operation if costs exceed the threshold. The operator gets a notification: "Gas is at 85 gwei, your ceiling is 40. Resume or wait?" This alone prevented several expensive mistakes during network congestion events.

results

The result is a system that gives the client a real-time, accurate picture of their operational treasury and lets them execute multi-chain operations without context-switching between five different tools. Periodic reconciliation runs nightly — comparing on-chain balances against database records and flagging discrepancies. The takeaway from this project: in crypto tooling, correctness beats features every time. A treasury system that's 90% accurate is worse than a spreadsheet, because at least nobody trusts the spreadsheet.

Frontend & API: Next.js 14 (Route Handlers), Prisma, PostgreSQL

Ethereum: ethers.js (transactions, gas oracle, contract calls)

Tron: tronweb (TRC-20, bandwidth/energy management)

Bitcoin: bitcoinjs-lib (UTXO handling, transaction construction)

Cross-chain: Allbridge SDK (bridge operations, status tracking)