An exchange or broker lives on two promises: deposits show up in the right account, and withdrawals go out fast without ever going out wrong. Behind them sit thousands of deposit addresses, a hot wallet that must stay funded, and a ledger that has to agree with the chain every day.
What you need from wallet infrastructure
- Permanent deposit addresses for every account holder, on every network you list.
- Deposits credited once, and only when final, with reorganizations handled for you.
- Withdrawals under limits, so a compromised service can't drain the hot wallet.
- A clean split between a small hot float and a well-guarded treasury.
How it runs on Valtu
| Wallet | Type | Role |
|---|---|---|
| One per account holder | user | Permanent deposit addresses: one EVM address for every supported EVM network, plus Tron and Bitcoin. Your user id is the wallet's externalId. |
| Treasury | treasury | Most of the funds. Sends only to saved addresses, with two approvers. |
| Hot wallet | operational | Pays withdrawals. Holds a day or two of them, no more. |
| Gas wallet | operational | Pays network fees for sweeps and token withdrawals. |
- Deposit. A user sends USDT to their address. Valtu watches the chain and sends
deposit.confirmedonce it's final. You credit it once, keyed on the deposit id. - Collect. A sweep task moves confirmed deposits into treasury on your schedule, above a minimum worth moving.
- Withdraw. Your withdrawal service creates a payout from the hot wallet with your withdrawal id as
externalId, so a retry can't pay twice. - Refill. When the hot wallet runs low, your team moves funds from treasury, under the treasury's approvals.
Coins are pooled, as on any exchange: a user's deposit is swept away from their address, and their withdrawal is paid from the shared hot wallet. Your ledger, not the wallet balances, says what each user owns.
Controls that matter for an exchange
- Velocity rules on the hot wallet. For example: withdrawals up to $2,000 pass automatically while the wallet's hourly outflow stays under $50,000; above that, a person approves. If a withdrawal service is ever compromised, the cap limits the damage to what you set.
- Scoped API keys. The deposit service's key can create user wallets and read deposits, and nothing else. The withdrawal key can only touch the hot wallet. Each key has its own IP allowlist.
- Saved addresses for treasury. New addresses wait out a cooldown (24 hours by default) before they count, which gives you time to notice a change you didn't make.
- Screening with your own provider. Withdrawal destinations and deposit senders can be checked with your Elliptic, Chainalysis, Blockaid or Webacy account. See KYT.
- Keys you can verify. Signing happens in hardware enclaves, and anyone can check the running code with remote attestation.
What you build, and what Valtu runs
| You build | Valtu runs |
|---|---|
| Accounts, KYC, your order book or brokerage | Keys, signing and approvals |
| The ledger of who owns what | Nodes and deposit detection on each network |
| The deposit and withdrawal screens | Confirmations, reorgs, sweeps and gas |
| Your policies and limits | Webhooks, reconciliation APIs, audit log |
Good to know
- The networks and coins available today are on the networks page.
- Valtu's internal security review is complete; the external audit isn't done yet. The security page keeps that list current.
- Licensing and customer due diligence for your business stay with you. Check with your own counsel what your jurisdictions require.
Start with the exchanges and brokers guide in the docs, or build the deposit flow with Node.js or FastAPI.