What you’ll need
- A workspace with an owner and at least one admin.
- A decision on which networks and assets you accept; see Supported networks.
- Your finance team’s reconciliation cadence and the format they need.
Components to configure
Steps
1
Create the treasury wallets
Create one wallet per function in the console or with
POST /api/v1/wallets. Naming them after the function (Client funds - ETH) keeps audit logs and reports readable. Wait for wallet.created.2
Attach assets and publish addresses
Attach each accepted asset; the platform derives the address. Publish the address from
GET /api/v1/wallets/{wallet_id}/deposit-address or the console, never from a hand-copied value.3
Decide the confirmation policy
A deposit is reported when detected and reflected in the balance when confirmed. Agree internally at what point a receipt is treated as final for each asset, and instruct operations accordingly.
4
Give finance read access
Invite finance users with the Viewer role, which sees balances, transactions and audit logs but cannot move funds or change settings. If the platform is integrated with a reporting system, issue it an API key with
balances:read and wallets:read only.5
Reconcile
Export
GET /api/v1/workspaces/{workspace_id}/transactions/export on your cadence and match it to bank-style records. Balances come from chain state, so a discrepancy is a signal to investigate, not to adjust.Considerations
- Deposits never require approval: nothing about receiving funds moves value out. Approvals apply to outbound transfers.
- Segregating client funds from operating funds is a wallet-per-function decision at setup time; moving funds between them later is an ordinary, policy-governed withdrawal.
- Where keys live depends on the deployment model you chose; the receiving flow is identical in all three.
Related
- Automate deposits: an address per customer instead of per treasury.
- Govern wallet access: who can see and do what.
- Who holds the keys: the custody position for each model.