Skip to Content
DocumentationFirmwareSupported Chains

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.

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.

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 and versioned ClearSign 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 and 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; 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 and Test Atlas.

Last updated on
Firmware 7.14.2Device Display Reference