Kraken Wallet Manifesto: Redefining Self-Custody for Active On-Chain Investors
According to a report from Coin Gabbar, Kraken has published the Kraken Wallet Manifesto — a design document specifying the account types, integrations, and custody assumptions behind its new self-custody product.

The exchange is positioning the wallet at experienced on-chain operators rather than mass-market retail, framing two recent shifts — a 2021-era hardware-wallet firmware flaw tied to losses exceeding $100 million across thousands of addresses, and the value captured by early participants in protocols such as Hyperliquid — as the reason cold storage alone no longer covers an active holder.
Account Architecture And Threat Model
Five account models run in parallel inside the wallet: standard EOAs, EIP-7702 smart accounts, embedded accounts, hardware-signer connections, and multisignature setups. The recommended operational pattern is split allocation — bulk reserves held in a high-security multisig, smaller balances in a more active account for daily transactions. A co-signer multisig option is planned, with Kraken holding one key fragment and authorizing operations through two-factor login on an existing Kraken account.
Audit-relevant parameters:
- The co-signer model converts the wallet from pure self-custody into a 2-of-N arrangement where one signer is a regulated exchange. Counterparty, jurisdiction, and sanctions exposure enter the threat model.
- Kraken cites a 15-year operating history and the claim that it has never lost client funds to a hack as the trust anchor for that role. Operational track record is not equivalent to key-custody track record; the two should be evaluated separately.
- The "$100M firmware flaw" reference reinforces that hardware-signer firmware provenance — supply chain, update path, attestation mechanism — still requires independent verification regardless of vendor reputation.
Curated Integration Surface
Kraken states it will natively integrate only services its own security team has reviewed. Initial scope, per the manifesto: lending and borrowing on the Ink network, xStocks tokenized equity exposure, a non-custodial Visa card through payments partner Reap, K-Assets (a receipt-token system backed by holdings in Kraken's qualified custody), and native Ink ecosystem support including early points programs. Anything outside that list requires an external connection or manual contract interaction. Native support narrows the attack surface but introduces single-vendor dependency — a structural risk factor that maps onto the same diversification logic applied to multi-asset portfolios managing systematic risk.
What To Verify Before Moving Funds
1. Map each account type to the specific threat it mitigates. A multisig with a third-party co-signer reduces single-key compromise risk; it does not eliminate key-ceremony risk or counterparty risk.
2. Confirm whether the target yield source sits inside the approved integration set or requires an unsigned contract call. Out-of-set interactions bypass Kraken's internal review.
3. Document the recovery path for each account type independently. Co-signer recovery inherits Kraken's account-recovery process; pure-multisig recovery does not.
4. Treat the cited Hyperliquid distribution as a reminder that early-protocol participation is a yield source — but only for users with the operational latency to enter before listings close. That is a participation-cost problem, not a wallet problem.
Verdict: the architecture is coherent for users who already hold significant balances on Kraken and want partial on-chain exposure. For users seeking true single-key self-custody, the co-signer path should be evaluated as a custodial add-on, not as self-custody.