Skip to main content

Wallet Compatibility

TL;DR: One recovery phrase can open different accounts in different ZIGChain wallets, because wallets derive keys with coin type 60 or 118. From v6, zigchaind creates coin type 60 keys like MetaMask, and pre-v6 keys need --legacy.

Overview​

ZIGChain wallet compatibility depends on two settings that each wallet uses to derive an account from a recovery phrase: the coin type in the derivation path and the key type. The v6 upgrade adds an EVM to ZIGChain and changes the zigchaind CLI default from coin type 118 with secp256k1 to coin type 60 with eth_secp256k1. The change affects only how keys are created, and nothing changes on chain, so existing coin type 118 accounts keep working.

This page is for ZIG Token holders and builders who use more than one wallet, or who restore a recovery phrase after the upgrade.

Key Concepts​

  • Coin type: The number in the BIP-44 derivation path, for example m/44'/118'/… or m/44'/60'/…. A different coin type derives a different private key, and therefore a different account, from the same recovery phrase.
  • secp256k1 (Cosmos account): The classic Cosmos key type. The address is ripemd160(sha256(compressed public key)). Every zig1… address also has a 0x… form of the same bytes, and native ZIG sent to it arrives, but a secp256k1 key can't sign EVM transactions.
  • eth_secp256k1 (Ethereum-style account): The Ethereum key type. The address is the last 20 bytes of keccak256(uncompressed public key without its prefix byte), and the zig1… and 0x… forms are two encodings of the same account.
  • EIP-712: The typed-data signing standard that MetaMask uses (eth_signTypedData_v4) to sign Cosmos transactions, such as Hub staking and CosmWasm contract calls.

ZIGChain Wallet Compatibility Table​

Each row shows the account a wallet derives on ZIGChain and the kinds of transactions that account can sign after the v6 upgrade.

WalletCoin type and key typeCosmos transactionsEVM transactionsNotes
MetaMask60, eth_secp256k1Yes, through the ZIGChain Hub on testnet, and CosmWasm contract calls through EIP-712YesThe zig1… and 0x… addresses are the same account and share one balance.
Keplr, ZIGChain entry118, secp256k1YesNoShows the zig1… account. Its balance is separate from the ZIGChain EVM entry.
Keplr, ZIGChain EVM entry60, eth_secp256k1No (EVM-only entry)YesShows the same 0x… account as MetaMask and zigchaind. Its balance is separate from the ZIGChain entry.
zigchaind CLI, new keys60, eth_secp256k1 (default)YesYes, with zigchaind tx evm send and zigchaind tx evm rawSame derivation as MetaMask (m/44'/60').
zigchaind CLI, pre-v6 keys118, secp256k1 (existing keys, or recovered with --legacy)YesNoMove funds to an Ethereum-style account to use the EVM.
Ledger with zigchaind118, secp256k1YesNoCoin type 60 Ledger keys are not possible in zigchaind.
Ledger with Keplr118, secp256k1YesNoUses the Ledger Cosmos app with Keplr's ZIGChain entry.
Ledger with MetaMask60, eth_secp256k1Yes, through the ZIGChain Hub on testnetYesUses the Ledger Ethereum app with Blind Signing turned on, which MetaMask needs even for ZIG transfers. The testnet Hub signs Cosmos transactions from MetaMask with EIP-712.
Trezor60, eth_secp256k1Yes, through the ZIGChain Hub on testnetYesTrezor connected to MetaMask. The Trezor shows Hub actions as readable EIP-712 typed data. See Set Up Trezor for ZIGChain EVM.

Same Recovery Phrase, Different Accounts​

One recovery phrase can give two unrelated ZIGChain accounts, because the coin type changes the private key and the key type changes how the address is hashed.

  • MetaMask account: The zig1… and 0x… addresses are one account in two encodings. Both show the same balance, and MetaMask can send ZIG from one 0x… address to another.
  • Keplr accounts: Keplr lists ZIGChain twice. The ZIGChain entry derives a Cosmos account at coin type 118. That account is separate from the MetaMask and CLI account, does not share its balance and can't sign EVM transactions. The ZIGChain EVM entry derives the coin type 60 account, the same 0x… account as MetaMask and zigchaind. One Keplr wallet holds both entries, and each shows its own balance. Don't use the 0x… form of the ZIGChain entry's address as an EVM recipient, because tokens that exist only on the EVM side can't be moved from there.
  • zigchaind account: From v6, a new zigchaind key uses the same derivation as MetaMask, so the same recovery phrase gives the same address in MetaMask and in the CLI.

Recover a Pre-v6 Account With the CLI​

Restoring an old recovery phrase with the new zigchaind default shows a different, empty wallet. The funds have not moved: they stay in the coin type 118 account, which the new default does not derive. Validators and other operational wallets are most at risk.

To reproduce the original coin type 118 secp256k1 account, add --legacy to zigchaind keys add --recover. Passing --recover --coin-type 118 alone keeps the eth_secp256k1 key type, so it derives a third account instead of the original one.

zigchaind keys add WALLET_NAME --recover --legacy

--legacy sets coin type 118 and secp256k1 together, and it works with --recover for a recovery phrase, or with --ledger for a Ledger device account. On a pre-v6 binary, a plain --recover already uses coin type 118.

To use an existing recovery phrase for the EVM, derive the Ethereum-style account and transfer the funds to it from the old account. Staked ZIG must be unbonded before you can move it:

zigchaind keys add WALLET_NAME --recover \
--key-type eth_secp256k1 --coin-type 60

On v6, --key-type eth_secp256k1 and --coin-type 60 are the defaults, so a plain --recover derives the same account. The command shows them for clarity.

From v6, zigchaind keys import-hex imports keys as eth_secp256k1 by default. Add --key-type secp256k1 to import a legacy key.

Ledger and EVM Transactions​

Ledger keys in zigchaind stay at coin type 118 with secp256k1, and existing Ledger keys keep working for Cosmos transactions. Adding a Ledger key from v6 needs --legacy, because coin type 60 Ledger keys are not possible in zigchaind, so a Ledger cannot send EVM transactions through zigchaind.

zigchaind keys add WALLET_NAME --ledger --legacy

A Ledger can sign EVM transactions on ZIGChain through its Ethereum app, with MetaMask connected to the Ledger or with cast --ledger. Both use the ZIGChain EVM JSON-RPC endpoint; the network details are in Set Up MetaMask for ZIGChain. The Ethereum app derives a different account from the Cosmos app, so the 0x address in MetaMask doesn't hold the ZIG in your Keplr Ledger account; move funds between them with a normal transfer. MetaMask needs Blind Signing turned on in the Ethereum app, even for a ZIG transfer. Device setup is in Set Up Ledger Wallet for ZIGChain.

MetaMask and CosmWasm Contracts​

The ZIGChain Hub supports MetaMask. MetaMask users sign Cosmos transactions that call existing CosmWasm contracts through EIP-712, using the MetaMask EIP-712 adapter that ships with the ZIGChain JS SDK. MetaMask signs the EIP-712 typed data with eth_signTypedData_v4, and the chain receives the call as an ordinary Cosmos transaction. The MetaMask prompt shows the message as raw strings.