Accept cryptocurrencies

Receive digital assets into an institution’s treasury with addresses whose keys no single party holds.

An institution that starts accepting digital assets (from clients, counterparties or its own operations) needs addresses it can publish with confidence, a clear view of what has arrived, and assurance that the keys behind those addresses are not a single point of failure. This solution sets up a treasury wallet per asset class and the reporting around it.

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

Component	Role
Treasury wallets	One MPC wallet per treasury function (operating, client funds, reserves), each key held as shares across the signing nodes.
Assets and addresses	The networks and tokens each wallet accepts, with a deposit address per network.
Roles	Viewers for finance, members for operations, admins for configuration; owners kept to a minimum.
Reporting	Webhook events for real-time notice; transaction lists and CSV export for the books.

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.