[NEP-563] Deterministic Derivation Paths for MPC Network

[BenKurrek]

This pull request introduces a new standard for deterministic derivation paths in the NEAR MPC network. The proposed method allows wallets to regenerate foreign blockchain addresses (e.g., Ethereum, Avalanche) from a NEAR account using a combination of the NEAR account ID, chain ID, and a nonce that starts at 1. This structure supports multiple foreign addresses on the same chain and enables efficient account management across different blockchains.

[SurgeCode]

Any reason for having the the near account id in the derivation path? could be a bit redundant since you will already know which accountId you're deriving to call the mpc contract

[BenKurrek]

Any reason for having the the near account id in the derivation path? could be a bit redundant since you will already know which accountId you're deriving to call the mpc contract

Oh sorry perhaps it was written in a confusing way. I meant the full derivation path the MPC contract uses so technically what you would pass in is ethereum,1 but MPC would use account + ethereum,1

[minqianlu]

An example implementation could be an object that tracks chain IDs, the respective "maximum nonce" as well as any custom derivation paths the user may have created. For example

const userPaths ={
   chains: {
     "ethereum": 2,
     "avalanche": 5,
     "base-sepolia": 9
   }
   custom_keys: ["opeanseas-key", "my-super-secret-key-4"]
}

It can also be argued that a "maximum nonce" is, in most use-cases, unnecessary as a user is unlikely to generate a significant amount enough to warrant an extra nested JSON - extra food for thought moving forward

[minqianlu]

It'd also be helpful if we specify naming convention for chain identifiers; for example ${chain}-${network}-${subnet} transalting to ethereum-testnet-sepolia or ethereum-mainnet

Alternate solution could also be to use pre-existing chain IDs (ex. BSC = 56) but not all chains have chain IDs

[ewiner]

Some scattered thoughts:

1. There's a few existing standards for "chain IDs" that could serve us well to adopt:

   1. SLIP-44 from the creators of the Trezor hardware wallet. Probably the most comprehensive chain directory out there.
   2. CAIP-2, which seems more fork-resistant and well-defined than SLIP-44, and includes testnets as well as mainnets. But it's not very human-readable. and I'm not sure whether it's well-defined for all known chains, including NEAR.
   3. (EVM-only) ERC-3770 relies on the human-readable shortNames in the directory at ethereum-lists/chains. Each filename in that directory is a CAIP-2 chain ID and most listed chains (maybe all of them?) also reference their SLIP-44 chain ID. I really like the idea of using a standardized but human-readable chain ID, but I'm not sure if there's an ethereum-lists equivalent that includes non-EVM chains, other than the SLIP-44 markdown file.

2. Sometimes you want to use the same derivation path on multiple chains. For example, it can be very useful to have one Ethereum wallet address across all EVM-compatible chains. We could have derivation paths that are specific to the literal chain (e.g. "Aurora") or to a whole architecture ("EVM chains"). Some people also just assume that any Ethereum mainnet address (CAIP2: eip155:1, SLIP44: 60, ERC-3770: eth) could exist on any EVM chain, which is pretty reasonable too.

3. For UTXO-based coins like Bitcoin, it's somewhat common to use a new address for each UTXO. You could just increment the nonce each time, but BIP-44 specifies a more detailed hierarchy of account (nonce) / change (bool) / index (nonce) which might be useful. I'm curious how SatoshiBridge is doing address derivation but not sure who to ping on that.

[esaminu]

@BenKurrek A few comments since we have had various discussions on this when implementing https://github.com/near/multichain-tools with @DavidM-D and @Pessina :

1. Using canonical-json RFC-8785 for serialization: required serialization properties outlined here. String concatenation meets some of the properties but not all
2. Use of SLIP-44 for chainId: avoids implementation errors and is more concise - also using 60 for all EVM chains since the same address is often used between EVM chains
3. Use of meta key to allow for multiple keys per chain serves the same purpose as nonce while allowing further properties to be added without breaking older derivations
4. Use of domain keys to allow for signing without prompting the user when the requesting domain can be identified (e.g. in iframe wallets)

This PR documents the technical decisions we made when implementing the multichain-tools package

[DavidM-D]

One thing that @ilblackdragon pointed out to me is that SLIPP-44 is a token identifier not a network identifier, note the lack of Base network because they don't have a native token. Mea culpa!
Network identifiers are defined in EIP-3770 which is also the spec used by the omnitoken standard. @esaminu do you think it's worth changing things on our end since people are still converging on a standard or is it more trouble than it's worth?

[ewiner]

EIP-3770 only covers EVM chains, though. For other chains... make our own? Or use CAIP-2 (https://chainagnostic.org/CAIPs/caip-2 / https://docs.reown.com/cloud/chains/chain-list, sourced from https://explorer-api.walletconnect.com/v3/chains?projectId=8e998cd112127e42dce5e2bf74122539)?

After looking through WalletConnect's actively maintained CAIP-2 chain directory, I'm feeling pretty good about using that as our standard.

[GaloisField2718]

Hello,
Is there a topic open on a forum?

Because I don't understand why to not use BIP32 standards for ethereum and avalanche. And not sure if it's the right place.

[ewiner]

Hello, Is there a topic open on a forum?

Because I don't understand why to not use BIP32 standards for ethereum and avalanche. And not sure if it's the right place.

I think the discussion is mostly happening here. BIP32 is relevant but it's not obvious to me how that helps us – what did you have in mind?

[DavidM-D]

why to not use BIP32 standards

The reason is that the BIP32 derivation standard is harder to do homomorphically as part of the MPC signing process than the derivation standard we settled on. We also have a proof of security for our derivation standard with MPC and presigning that we don't have for the BIP32 standard.

What is your use case, maybe it's possible to add later on.

[flmel]

Hi @BenKurrek – thank you for starting this proposal. As the moderator, I labeled this PR as "Needs author revision" because we assume you are still working on it since you submitted it in "Draft" mode.

Please ping the @near/nep-moderators once you are ready for us to review it.

[GaloisField2718]

why to not use BIP32 standards

The reason is that the BIP32 derivation standard is harder to do homomorphically as part of the MPC signing process than the derivation standard we settled on. We also have a proof of security for our derivation standard with MPC and presigning that we don't have for the BIP32 standard.

What is your use case, maybe it's possible to add later on.

Thanks for your answer.
For now I'm just looking new updates on HDwallet for personal projects.
But it could be important for future cross-chain feature. I'm trying to stay aware.
I'll take a look on MPC thank you!

[GaloisField2718]

Hello, Is there a topic open on a forum?

Because I don't understand why to not use BIP32 standards for ethereum and avalanche. And not sure if it's the right place.

I think the discussion is mostly happening here. BIP32 is relevant but it's not obvious to me how that helps us – what did you have in mind?

Cool thanks. Just to not flood a wrong place