Kraken requires provider-aware asset normalization

Kraken can return exchange-specific asset codes and suffixes associated with rewards or staking variants. The connector maps known forms into a clear normalized asset view without discarding reported quantity. Unknown codes remain observable so a provider change cannot silently turn a real position into zero.

Query Funds and ledger reads are sufficient

Balance tracking needs Query Funds; cash-flow analysis benefits from Query Ledger Entries. Trading, deposits and withdrawals must remain disabled. Kraken also supports expiration, date and IP restrictions, which should be applied only when they match the deployed integration and do not prevent the service from making legitimate signed reads.

Held amounts and credit fields need interpretation

Kraken balance information may include held quantities and credit-related fields. A normalized response should distinguish availability without dropping the economic position. Consumer UI can show a simple aggregate while a detailed account view preserves available and held values for reconciliation.

Ledger windows determine performance confidence

Synchronization combines current balances with available ledger history and a new portfolio snapshot. Query windows, missing permission and historical pricing gaps can all limit cash-flow adjustment. The performance endpoint communicates this as coverage rather than substituting a precise return unsupported by the provider data.

Provider codes should not leak into your domain

Keep Kraken request signing, nonce handling, asset aliases and provider errors inside the adapter boundary. Your application should consume stable normalized symbols and problem codes. When Kraken adds a code or changes a restriction, update one integration boundary rather than every product component and customer export.