# Supported Chains This is the technical per-chain reference for KeepKey multi-chain firmware 7.14.1 and later. For the plain list of supported coins, tokens and what is not supported, see [Supported Coins](/docs/supported-coins). Each chain section below describes the supported operations, derivation paths, address formats, and any chain-specific security behavior. Zcash Orchard (shielded transactions), chain-agnostic EVM clear-signing, and BIP-85 child derivation are in progress — see the in-progress sections at the end. --- ## Bitcoin The most extensively tested chain. Covers all modern address types and signing algorithms. **Derivation paths** - Legacy P2PKH: `m/44'/0'/0'/0/0` → `1...` addresses - P2SH-wrapped SegWit: `m/49'/0'/0'/0/0` → `3...` addresses - Native SegWit bech32: `m/84'/0'/0'/0/0` → `bc1q...` addresses - Taproot P2TR: `m/86'/0'/0'/0/0` → `bc1p...` addresses (Schnorr signatures, BIP-341/342) Native SegWit (`m/84'`) is the default. Taproot is supported by the firmware but is **not** exposed as a default account — hosts must confirm firmware support before offering it, and it fails closed on older firmware. Rationale in [Bitcoin Address Types](/docs/learn/address-types). **Supported operations** - Get address with QR code display - Export xpub for watch-only wallets - Sign transaction (P2PKH, P2SH, P2SH-wrapped SegWit, native SegWit, Taproot) - Multi-input transactions with correct change detection - Multisig (P2SH, requires all co-signer xpubs) - Coinbase (maturity-aware) - Sign message (EIP-191 equivalent for BTC) - Verify signed message on-device **Security behavior** - Every output address is shown in full on the OLED — no truncation - Change output detection: device identifies change outputs (same xpub tree) and does not display them as recipients - Fee warning at `> 100 sat/byte` (configurable threshold) - Attack detection: if the host attempts to substitute a different output address between signing passes, the device detects the mismatch and refuses to sign - Non-BIP44 path warning displayed before proceeding **BTC forks also supported** - Litecoin (coin_type=2, `L...` addresses) - Testnet/TBTC (testnet derivation, `m...` prefix) - Bitcoin Gold (BTG, same signing code, different chain parameters) - Dash (InstantSend-compatible) - Groestlcoin (Groestl hash instead of SHA-256d) - Zcash transparent (Overwinter/Sapling serialization with version group IDs and expiry height) --- ## Ethereum Native ETH, ERC-20 tokens, EIP-1559 gas, personal message signing, and contract interactions. **Derivation path:** `m/44'/60'/0'/0/0` — EIP-55 checksum addresses displayed **Supported operations** - Get address - Sign transaction (no data / with contract data) - ERC-20 token transfer (known tokens show human-readable name + amount) - ERC-20 approve (fixed amount shows `APPROVE X tokens`; MAX_UINT256 shows `UNLIMITED` warning) - EIP-1559 Type 2 transactions (base fee + priority fee, both shown) - EIP-155 replay protection (chain ID embedded in v value) - Personal message signing (EIP-191, shown as text on OLED) - Raw bytes signing (shown as hex) - Verify signed message - Contract interactions: MakerDAO, 0x swaps, Sablier streaming, generic function calls **EVM interpretation and signing policy** Chain signing, token recognition and full transaction interpretation are different capabilities. See [Signing and Approvals](/docs/learn/clear-signing) and [versioned ClearSign status](/docs/firmware/release-status). A metadata signature does not establish KeepKey approval or contract safety. **Security behavior** - EIP-55 checksum enforced — corrupted addresses fail validation - Unlimited approval (MAX_UINT256) shows explicit `UNLIMITED` warning - Unknown contract data displayed as hex with `CONFIRM ETHEREUM DATA` screen - EIP-155 chain ID prevents cross-chain replay attacks --- ## Ripple (XRP) Account-based model (not UTXO). Amounts in drops (1 XRP = 1,000,000 drops), reserve requirements are network parameters and can change; check the current XRP Ledger requirements before funding an account. **Derivation path:** `m/44'/144'/0'/0/0` — full `r...` address displayed with QR **Supported operations** - Get address - Sign payment (destination, amount, fee, destination_tag) - Destination tag display (required for exchange deposits) - Fee validation (rejects fee outside acceptable range — currently min 10 drops) **Security behavior** - Full rAddress shown on OLED (34 chars starting with `r`) — no truncation - Drop amounts converted to human-readable XRP before display - Destination tag shown in full — critical for exchange routing --- ## Cosmos (ATOM) Cosmos Hub anchor chain, with IBC ecosystem support. Uses amino encoding (legacy Cosmos SDK format). **Derivation path:** `m/44'/118'/0'/0/0` — `cosmos1...` bech32 address **Supported operations** - Get address - MsgSend (transfer) with recipient + amount - MsgDelegate (staking to validator) - MsgWithdrawDelegatorReward (claiming staking rewards) - Memo field display (shown in full — required for exchange deposits and IBC transfers) **Security behavior** - Memo is displayed in full on OLED — a compromised host cannot truncate it to misdirect an IBC deposit --- ## THORChain Decentralized cross-chain liquidity protocol. Native RUNE transactions use amino encoding with `thor1...` bech32 addresses. **Derivation path:** `m/44'/931'/0'/0/0` **Supported operations** - Get address (thor1... format) - Sign RUNE transfer - Cross-chain swap via memo routing (e.g. `SWAP:BTC.BTC:bc1q...`) - Liquidity pool add/remove (e.g. `ADD:BTC.BTC:10000`) - LP deposit transaction **Security behavior: Memo is critical** The memo encodes the entire swap/LP instruction. A compromised host that substitutes the destination address in the memo could redirect funds to an attacker. The device displays the **full memo** on the OLED so users can verify: - Destination chain and asset (`BTC.BTC`) - Receiving address (the user's BTC address) - Pool and basis points (for LP operations) Always verify the complete memo before confirming; cancel if the selected firmware cannot show the information you need. --- ## Maya Protocol A THORChain fork for cross-chain liquidity using native CACAO token and `maya1...` bech32 addresses. Identical memo security model. **Derivation path:** `m/44'/931'/0'/0/0` **Supported chains via Maya:** Bitcoin, Ethereum, THORChain, Dash, Kujira --- ## EOS Action-based transaction model. EOS uses 12-char account names instead of addresses and action lists instead of simple transfers. **Supported operations** - Get EOS public key (`EOS...` format, from `m/44'/194'/0'/0/0`) - `eosio.token::transfer` - `delegatebw` / `undelegatebw` (CPU/NET staking) - `voteproducer` (block producer voting) - Account management (`updateauth`, `linkauth`, `newaccount`) Each action in a transaction is displayed individually on the OLED with the contract and action name. --- ## Nano Block-lattice architecture — each account has its own blockchain. Transactions are feeless and near-instant. **Supported operations** - Encode Nano balance (128-bit representation for state block construction) - Sign state block (account + previous + representative + balance + link → hash → sign) --- ## Solana [NEW in 7.14.1] Solana support uses Ed25519 (SLIP-10) and base58 addresses. Instruction and account-resolution coverage depends on firmware and host versions. **Derivation path:** `m/44'/501'/0'` — full 44-character base58 address displayed **Key security fix in 7.14.1:** Full 44-character address display replaces the old 8-character truncation that was a spoofing vector. **Supported operations** - Get address (full 44-char base58 with QR) - System::Transfer (SOL transfer) - SPL Token transfer (shows token amount + recipient) - SPL Token transfer with SolanaTokenInfo metadata (shows human-readable token name) - Stake delegate - Memo instruction - Compute budget (priority fee) - Sign message (arbitrary bytes, requires AdvancedMode) - Sign empty transaction rejection **Security behavior** - Full-address review helps detect address substitution - Empty transaction data rejected - AdvancedMode required for arbitrary message signing (policy gate) --- ## TRON TRC-20 tokens, TRC-10 tokens, resource staking (Energy/Bandwidth), and governance. **Supported operations** - Get address - TransferContract (TRX transfer) - TriggerSmartContract (TRC-20 and arbitrary contract calls) - FreezeBalanceV2 / UnfreezeBalanceV2 (stake for Energy/Bandwidth) - DelegateResource / UnDelegateResource - Vote for Super Representatives - Sign message --- ## TON The Open Network. Account-based, with boc (bag-of-cells) transaction serialization. **Supported operations** (8/8 all passed) - Get address - Sign transfer - Sign with comment/memo - Jetton (TON token standard) transfers - NFT transfers - Encrypted message support --- ## Zcash Orchard — candidate support Orchard is present in candidate work. The inspected September 24 report records 27/27 catalog tests passed for its candidate. This is not a statement that Orchard is enabled in every published firmware or Vault build. See [Test Atlas](/docs/firmware/test-atlas) and [release status](/docs/firmware/release-status). --- ## EVM ClearSign — provider and approved tiers The 7.15 provider tier adds context without removing baseline review. The 7.16 destination adds KeepKey-approved authority under its binding and coverage requirements. See [release status](/docs/firmware/release-status); this does not promise universal dApp decoding. --- ## BIP-85 child derivation — candidate support BIP-85 derives child recovery material from a master wallet. The inspected September 24 report records 6/6 catalog tests passed for its candidate. Availability and the supported handling flow depend on the selected build; see [BIP85](/docs/desktop/bip85) and [Test Atlas](/docs/firmware/test-atlas). --- ## Related - [Device Display Reference](/docs/firmware/device-display) — OLED screenshots for each chain's confirmation flows - [python-keepkey](/docs/firmware/python-keepkey) — test harness reference - [Firmware Overview](/docs/firmware) — CI pipeline, build instructions