Digital assets
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
Section titled “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
Section titled “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) and keeps credentials in your own store.
- 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.
- Go to Setup and admin → Connectors, find the provider (search for it, or filter by Digital assets), and choose Connect.
- Name the fields listed for the provider, and leave the access level at Read.
- Paste the key. Your browser seals it to your deployment; LightHouse never sees it.
- Your deployment keeps it, checks what it may do at the provider, and the card shows the result.
What the health codes mean
Section titled “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
Section titled “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.
- 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
Section titled “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
Section titled “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
Section titled “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
Section titled “Where the credential is held”LightHouse never opens these credentials. They are sealed in your browser, or by lighthouse-ai connect <provider> --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.
Removing it
Section titled “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.