Cost-aware crypto API design

It's easy to design a crypto API that's expensive to operate. Here are some choices we've made specifically because they keep our infrastructure costs sustainable:

Master-wallet-shared-across-EVM

Generating a fresh HD root for each EVM chain (Ethereum, Polygon, BSC, Arbitrum, Optimism, Base, Avalanche, Fantom, Cronos) would be silly — they all derive the same address. We have ONE EVM master per tenant and reuse the addresses. UTXO chains and Solana / Tron each need their own master because they don't share a derivation.

Cache balance reads with TTL

Every “what's the balance of this wallet” call goes to an RPC node. RPC providers charge per call. We cache balances with a 30-second TTL and only invalidate on confirmed inbound or outbound transactions. The 30-second window means dashboards are fast; the invalidation means correctness when something changes.

Webhook delivery uses a worker pool, not per-event functions

If you fire off a serverless function for every webhook event, you pay for cold starts on every retry. We use a fixed worker pool with a queue. Throughput is bounded but predictable, and our bill scales sub-linearly with retry volume.

Postgres advisory locks instead of distributed locks

Our cron service uses pg_try_advisory_lock to ensure only one instance processes the sweep queue. We don't need Redlock or a separate lock service — Postgres is already there and the semantics are well-understood.

None of these are clever. They're just the choices that keep our infrastructure simple and our bill linear.