The current standard derivation path used by Stacks wallets to derive addresses is
m/44'/5757'/0'/0/. And it follows the Multi-Account Hierarchy for Deterministic Wallets standard defined in BIP-0044. The unique coin type for Stacks
5757 is registered in SLIP-0044
This presents problems for wallets that support both BTC and STX. Since NFTs built on Stacks and settle on Bitcoin are marketed as Bitcoin NFTs, it should be the case that you can send and receive NFTs using Bitcoin addresses. This is possible currently as all Stacks addresses have a Bitcoin equivalent. i.e. using a
b58check encoded address instead of the
c32check used for Stacks addresses.
The Stacks address
corresponds to a legacy BTC address
One can simply take BTC addresses as an input for the recipient of an NFT transfer and convert it to a Stacks address by changing the encoding. Then send the NFT to the resulting Stacks address.
The BTC address is not on a standard BTC address derivation path, meaning if you used the same seed phrase in another Bitcoin wallet, you would not be able to generate this address. This makes the address difficult to use for sending/receiving BTC, since users expect that if they migrated to a different Bitcoin wallet their Bitcoin would still be there. Though there is an argument to be made here that seed phrases are only for backup and shouldn’t be used to migrate between wallets.
The address is a legacy BTC address, meaning if you were to use it for sending/receiving BTC, the transaction fees will be higher than using a segwit address.
Stacks wallets use standard Bitcoin derivation paths for both Stacks and Bitcoin addresses. For example, the
m/49'/0'/0'/0/ path used for P2WPKH-nested-in-P2SH accounts (wrapped segwit address).
This means the Stacks address generated from the seed phrase will be different from current wallets. But the equivalent BTC address will be one that would be derived by other Bitcoin wallets. And it is a segwit address. (Xverse wallet currently derives a wrapped segwit Bitcoin address for the Bitcoin wallet)
This solves the 2 problems mentioned above. And in the future where Bitcoin transactions are activating Clarity smart contracts, and assets need to be transferred to the sender’s Stacks address, the address does not need to be specified separately.
Consider a Bitcoin transaction that triggers a Clarity contract to mint an NFT and transfer it to the sender. In this transaction, the sender would have paid for the minting in BTC and the contract could transfer the NFT directly to the sender’s BTC address.
This also has the advantage in that the Bitcoin and Stacks wallets feel more like one wallet. And Stacks feels more like the smart contract layer instead of a completely separate blockchain.
Hardware wallet makers may not play nice. If Stacks is using the same derivation path as Bitcoin, the hardware wallet may refuse to sign Stacks transactions for security reasons.
As Bitcoin derivation paths change, Stacks wallets would need to keep up. This also results in potential user experience issues since users may not understand or care about derivation paths.
Wallets will need to either offer users a choice of creating/restoring “legacy” Stacks wallets for backward compatibility or automatically scan addresses on both paths and automatically handle the legacy addresses.
More discussion on Twitter for reference: https://twitter.com/TO/status/1479603116643336198