> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blockops.network/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](/overview/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

<Steps>
  <Step title="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`.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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](/overview/deployment-models) you chose; the receiving flow is identical in all three.

## Related

* [Automate deposits](/solutions/payments/automate-deposits): an address per customer instead of per treasury.
* [Govern wallet access](/solutions/custody/govern-wallet-access): who can see and do what.
* [Who holds the keys](/security/who-holds-the-keys): the custody position for each model.