Skip to Content
DocumentationFirmwareSupported Chains

Supported Chains

KeepKey firmware 7.14.1 natively signs transactions on 11 chains and protocols: Bitcoin, Ethereum, Ripple (XRP), Cosmos (ATOM), THORChain, Maya Protocol, EOS, Nano, Solana, TRON, and TON. Through Ethereum’s EVM support it also handles any ERC-20 token and any EVM-compatible chain (identified by an EIP-155 chain ID); through Bitcoin it supports the Bitcoin family (Litecoin, Bitcoin Gold, Dash, Groestlcoin, and Zcash transparent). Solana, TRON, and TON are new in 7.14.1.

Not natively supported: Cardano (ADA), Polkadot (DOT), and Monero (XMR). Avalanche is reachable as an EVM chain rather than a separate integration.

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)

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 Clear-Signing [NEW in 7.14.1]

When the host provides a signed metadata blob (contract name, function name, decoded parameters), the device:

  1. Verifies the blob signature against a trusted key
  2. Displays a VERIFIED icon with the method name and decoded arguments
  3. Falls back to blind-sign path if no metadata is provided

This allows wallets to show human-readable DeFi interactions (“Approve USDC to Uniswap”) instead of raw hex.

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), minimum reserve 20 XRP.

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)

The device will not truncate the memo. Always verify it before confirming.

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]

Full Solana support with Ed25519 (SLIP-10), base58 addresses, and 37 instruction types across 7 programs.

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 display prevents address spoofing
  • 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 [NEW — in progress]

Zcash shielded transactions using the Orchard protocol. 9 tests currently pending (OLED fixtures needed for CI). Enable via Settings → Feature Flags → Zcash Shielded Privacy in the desktop application.

EVM Clear-Signing [NEW — in progress]

Chain-agnostic EVM metadata verification. 5 of 8 tests currently pending OLED fixtures. When complete, this will apply to Ethereum mainnet, Polygon, Arbitrum, Optimism, and any other EVM chain.

BIP-85 Child Derivation [NEW — in progress]

Derive deterministic child seeds from the master seed for use in hot wallets or other hardware wallets. 6 tests pending. Enable via Settings → Feature Flags → BIP85 Seed Vault in the desktop application.

Last updated on
OverviewDevice Display Reference