Are you stuck in the BIP path and address derivation svamp? This article may bring some clarity. There are many conflicting implementations in the wild. This article is mainly intended for developers implementing support for Songbird, Flare or Coston and trying to achieve compatibility between different wallets.

Hierarchical deterministic wallets implementing the BIP32 and BIP44 standards use an address derivation path with 5 levels that looks like this:

The purpose value is typically set to 44. The coin_type value differs between different types of cryptocurrencies. Songbird, Flare and Coston all use coin_type 60, the same coin_type as Ethereum, Binance Smart Chain and Avalanche C-Chain. The remaining values are set to zero for the first receiving address. This results in a derivation path on the following form:

The first address is typically the same, if the same recovery phrase is imported to different wallets. This is a result of account and address_index both starting on zero. For later addresses, different wallets increase different parts of the derivation path. This breaks compatibility between different wallets. As an example, Ledger hardware wallets increase the account value, meaning that later addresses are derived using:

As another example, MetaMask software wallets increase the address_index value, meaning that later addresses are derived using:

If we move onto Exodus and Cobo Vault, specifically for Songbird, Coston and Flare, it gets even trickier. Due to a misunderstanding during the early days of Coston testing, Exodus and Cobo Vault used coin_type 554 (deprecated) to derive Songbird and Flare claim addresses:

For any new developer looking to implement support for Songbird, Coston or Flare, always use coin_type 60 and the following recommended derivation paths:

This provides best support and compatibility with other wallets including Bifrost Wallet, which defaults to m/44'/60'/account'/0/0 for all EVM-compatible chains without their own coin type. Bifrost Wallet derives the first address with account = 0 and increases account by one for every new receive address. Bifrost Wallet always uses the complete BIP44 path including the change and address_index, even for non-UTXO blockchains.