-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[NEP-563] Deterministic Derivation Paths for MPC Network #563
base: master
Are you sure you want to change the base?
Conversation
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 |
|
||
## Future Possibilities | ||
|
||
### Standardizing a Data Structure for Chain Identifiers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
It'd also be helpful if we specify naming convention for chain identifiers; for example Alternate solution could also be to use pre-existing chain IDs (ex. BSC = 56) but not all chains have chain IDs |
Some scattered thoughts:
|
@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 :
This PR documents the technical decisions we made when implementing the multichain-tools package |
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! |
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. |
Hello, 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? |
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. |
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. |
Thanks for your answer. |
Cool thanks. Just to not flood a wrong place |
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.