CAIP2 standard

[volovyks]

• Added CAIP2 as our standard for network identification (potentially a breaking change)
• Removed our Roadmap from the repo; it is available on our website.
• Min updates

[jakmeier]

Nice!

What are the breaking changes you had in mind?
Does this require changes to existing smart contracts (MPC contracts and/or user contracts)

[volovyks]

@jakmeier chain_id is a part of our derivation path. You can check how it works here.

Using CAIP 2 for Ethereum would be a breaking change.

Also, we can use CAIP10. Again, a breaking change. In practice, it would mean going from {EPSILON_DERIVATION_PREFIX},{CHAIN_ID_ETHEREUM},{requester} to {EPSILON_DERIVATION_PREFIX}:{CHAIN_ID_ETHEREUM}:{requester}.

Note, our actual derivation path is {EPSILON_DERIVATION_PREFIX},{CHAIN_ID},{requester},{path}, where EPSILON_DERIVATION_PREFIX is sig.network v1.0.0 epsilon derivation and path is what the user passed in their call. I do not think that there is a standard that includes all these parameters.

[volovyks]

Since we do not have a standard that includes both network type and network identifier, some networks had the same derivation path for testnet and mainnet networks. For example:

Ethereum (different derivation paths):

• mainnet: 0x1
• testnet: 0x115511

Solana (same derivation path):

• mainnet: 0x800001f5
• testnet: 0x800001f5

Now this issue will be fixed:

• Solana Mainnet: solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp
• Solana Devnet: solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1
• Ethereum Mainnet: eip155:1
• Ethereum Sepolia: eip155:11155111

But it requires some minor changes.

[volovyks]

If we want to follow CAIP standards more closely, we can remove EPSILON_DERIVATION_PREFIX (sig.network v1.0.0 epsilon derivation), but my understanding is that this is where we may want to change the key version. cc @scafuro

[volovyks]

I've updated the doc, mentioned CAIP-10, etc.
If we merge this, I will continue with updating our KDF logic.
cc @esaminu @jakmeier