So, therefore the relationship is:
account plate1–>1wallet
The Yoroi API layer allows for multi-account and even arbitrary standards for derivation paths that we abstract to something we call a “public deriver” – we just don’t have anything in the UI that exposes this. The reason the CIP isn’t called “account plate” or anything referring “account” is because it’s a generic scheme for any wallet generation strategy that contains a public key.
E.g a modified or extended version of the
BIP32-ED25519that contains how the master (extended) key is generated as atm all the different wallets implementing their own
Perhaps you’re looking for CIP3?
Address serialisation specification
For Haskell Shelley it’s defined here and for Jormungandr it’s defined here. Unfortunately we don’t have a standard that allocated bech32 prefixes though (but Haskell reuses the same prefixes as Jormungandr like addr1). For Byron-era addresses, I’m not aware of a clearly written specification – just documentation of the code.
for export/import that contains some derivation metadata we do not have any, it’s a nice to have feature
You may be interested in my specification for wallet export & import. It also described the “public deriver” concept I mentioned earlier in this post.
we need make some standard for these points
I agree, which is why I’ve authored a lot of specifications and pushed hard to get the CIP process started.