# Digital assets > Connect Fireblocks, Dfns, Coinbase Prime, Kraken or Binance to LightHouse, read-only: the view-only key to make, the fields to name, and what the health codes mean. The engine reads balances, transfers and trade history from your custody provider or exchange into a knowledge base, for treasury and reconciliation agents. Content is read in place, in your deployment, in your own account. LightHouse receives ids, hashes and counts only. Balances and transactions are not transmitted, and LightHouse does not open the credential. ## Read-only, always These connectors only read. LightHouse never holds a credential that can move money, so **read and write is refused** for every one of them: make a view-only key and connect it as **Read**. Your deployment asks the provider what the key may do before every read. A key that can withdraw, transfer, sign, trade or approve payments is refused, naming the permission, and nothing is read with it. ## Connect in LightHouse You need the **Client administrator** (`client_admin`) role, signed in as a person, and a deployment whose engine reads this connector ([compatibility reference](/concepts/telemetry-contract/#compatibility-reference)) and keeps credentials in your own store. 1. Make a view-only key at the provider, as the section for your provider below describes. Pin it to your deployment’s egress addresses where the provider offers an allowlist. 2. Go to **Setup and admin → Connectors**, find the provider (search for it, or filter by **Digital assets**), and choose **Connect**. 3. Name the fields listed for the provider, and leave the access level at **Read**. 4. Paste the key. Your browser seals it to your deployment; LightHouse never sees it. 5. Your deployment keeps it, checks what it may do at the provider, and the card shows the result. ## What the health codes mean | Code | The card says | What to do | | --------------- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | `write_capable` | The key can withdraw, transfer, sign or trade: refused, nothing is read | Make a view-only key at the provider (no withdraw, transfer, sign or trade permission), pin it to your deployment’s egress addresses, and connect it again | | `unverified` | The provider does not state the key’s permissions and it was not confirmed view-only | Check at the provider that the key only reads, then connect it again with **View-only confirmed** set to yes | | `auth_failed` | The provider refused the key | It may have expired or been revoked. Make a new one and connect it again | Coinbase Prime does not state a key’s permissions, so it always needs **View-only confirmed**. Fireblocks does not tell a key its own role: an administrator’s key is refused, and you confirm the rest is a Viewer. []() ## Fireblocks - **Reads**: vault accounts, asset balances (total, available, pending, frozen, locked) and transactions. - **Make**: an API user with the **Viewer** role. - **Paste**: the API user’s key on the first line, then the PEM of the private key of its CSR. Requests are signed in your deployment. - **Name**: **Workspace region** (US, EU, EU2 or the sandbox) and **View-only confirmed**. []() ## Dfns - **Reads**: wallets, balances and transfers. - **Make**: a service account with a read-only role (`Wallets:Read`, `Wallets:Transfers:Read`). - **Paste**: the service account’s token. - **Name**: **Region**, and optionally **Service account ID**. Dfns states the account’s permissions; one that can create transfers or transactions, or sign or export keys, is refused, named. []() ## Coinbase Prime - **Reads**: portfolios, balances, orders, fills and transactions. - **Make**: an API key with the **Read** permission only. - **Paste**: three lines: the access key, the passphrase, then the signing key. - **Name**: **View-only confirmed**, once you have checked the key. []() ## Kraken - **Reads**: balances, ledger entries and trade history. - **Make**: an API key with **Query Funds**, **Query Ledger Entries** and **Query Closed Orders & Trades** only, and an IP allowlist. - **Paste**: two lines: the API key, then its private key. - **Name**: nothing beyond **View-only confirmed**; Kraken states the key’s permissions, and one that can withdraw or trade is refused, named. []() ## Binance - **Reads**: spot and margin balances, trades, deposits and withdrawals. Futures are not read: Binance requires a trading permission for them. - **Make**: an API key with **Enable Reading** only (Ed25519 recommended), restricted to your deployment’s addresses. - **Paste**: the API key on the first line, then its HMAC secret, or the PEM of its Ed25519 private key. - **Name**: **Environment** (production, or the spot testnet; the testnet does not state a key’s restrictions, so it needs **View-only confirmed**). Binance states the key’s restrictions; one with withdrawals, transfers or trading enabled is refused, named. ## Where the credential is held LightHouse never opens these credentials. They are sealed in your browser, or by `lighthouse-ai connect --credential-stdin`, to your deployment’s own key, and your deployment keeps them in your own secrets store. LightHouse keeps the connection’s fingerprint, the access level, when it was checked and the check’s code: never the key, and never what it reads. See [Where every credential is held](/connect/#where-every-credential-is-held). ## Removing it On the card, choose **Disconnect**. Your deployment deletes the credential from your store. Delete the key at the provider too. Documents already written stay in the corpus until you delete them. Source: https://docs.atlanticagenticlabs.com/connect/digital-assets/