First and foremost I want to say that I wholeheartedly support this initiative.
Although, the following comment:
makes it sound like if the SS58 Format is something that’s not stored on chain. However, I think that the SS58 Format is actually (unlike the rest of the fields in the properties entry of the chainspec) stored on-chain under the System.SS58Prefix constant.
This comment from @tomaka also makes it look like the SS58 Format is not stored on-chain…
Polkadot-API actually uses the value of the System.SS58Prefix constant for determining how the ss58-formatted addresses of a given chain should be formatted.
The prefix is there on chain. It was added to for example use it in contracts. (Not sure this ever happened) It isn’t used as far as I can see currently in the runtime. As @joepetrowski correctly said the transactions contain the public key and not the full address with the SS58 prefix. This also being the reason why what being discussed here, will only have impact on UIs. The actual account public key is already the same on all the parachains.
Fine to do it this way. I would assume that if the proposal here gets enacted, chains change this prefix to Polkadot/Kusama.
Awesome! Yeah, that was the point that I was trying to make.
Of course! Yes, I know that the only thing that it’s stored is the public key.
What I meant to say is that if we decide to go down this path, then the proper way to enforce/enact this change is to request all parachains to either:
Change their SS58 Prefix to match the SS58 Prefix of the relay chain.
Or to ask parachains to remove that constant from the runtime of their chain (and then ask UI libraries to use the SS58 Format of the relay-chain)
That should also, IMO kinda solve this:
All I’m saying is that it’s a bit more than a UX recommendation, because it does have some some on-chain implications.
They can not really do this. However, the UI could also just take the SS58 from the relay chain the parachain is connected to.
It doesn’t really have any on chain implications. Yes, you could achieve this by changing this constant that isn’t used by anything AFAIK. Or you do what I proposed above and the UI is just taking the SS58 from the relay chain directly. Still, both things are something that the relay chain can not enforce and these are more like “the rules we are playing by” in the ecosystem. Still, anyone can decide differently.
If we have a problem (we have) with somebody sending assets to exchange addresses on wrong chain. What if exchanges used their own ss58 which would be saved on known exchanges list and we would know on the UI that you are sending to wrong address? This would require literally 0 change other than a json and harder part → convincing exchanges to display deposit addresses differently.
We could then unify all the addresses per consensus or whatever we want. ( Or everybody changes this and we keep exchanges to use polkadot prefix =) )
This would actually work for ledger problem or other wallets that are chain specific only (i.e. polkadot vault). So we would basically change this from “every chain should use their own ss58” → “every app that works only on specific chain/s would use different ss58” (or other format which we’ll have mapping for)
Very much in support of this FWIW. If a substantial degree of coordination is needed, perhaps we can pass a WFC track item to make clear the network’s opinion and help encourage CEXs, explorers, wallets and dApp teams to move to ecosystem-wide SS58s.
The WFC item could also call upon Parity to deprecate the SS58 ID registry.
I am joining the consensus made here, acting that complexity needs to be reduced.
But we’re already deep down this rabbit hole with a large number of use cases and edge cases for address format.
The task to transcript what is originally (and stored on-chain) an hex encoded address is delegated to the API, we have to target API users: dapps. This is a massive pain for these devs to onboard Substrate.
I am personally in favor of a global solution targeting the abstraction of prefix to API users (dapp developers) that would be defaulted to 0 in all cases. I think going up to relay chain level would not help enough.
This way, we could gradually depreciate (or tag “expert only”) the multi representation of SS58 addresses and push developers to only use transcription for hex <> SS58 representation of the public key.
The simpler we are, the more we are able to attract new population of dapp developers who are today repulsed by these kind of complexities.
We actually use what your wallet shows. So if your wallet is set to Hydration we show 7xxx if Polkadot then 1xxxx. Talisman for example shows 5xxxx by default.
On the issue itself, I have started working with members of the UX Bounty and I will be drafting out a proposal on how to tackle this. TLDR; this should be slow rollout in two steps:
unified substrate addresses.
prefixes
Both should be backwards compatible for a long time and only enforced (addresses shown especially with prefix) only when most of the affected parties are ready to accept this format. We might want to also schedule this with the ERC for EVM chains. I want to have a draft proposal ready in the next two weeks and then get a feedback from everybody.
I am strongly in favour of this. When I look at an address all I want to know is “which public key is this?”. The different prefixes just add uncertainty on top of this. Which network the address belongs to doesn’t seem too relevant to me. Because even if a mishap happens I still control the key and don’t lose my funds. So I don’t see a reason to encode the network into this. From my point of view just having a single fixed prefix is the best solution. Having different addresses refer to the same key is really confusing.
Except if you’re sending to a custodial wallet address, then you’ll need collaboration from the custodial party. I imagine that there are some terms and conditions regarding the custody of the assets…
I have posted a discussion thread that is taking this thread, many other discussions and other ecosystem best practices into account and want to gather feedback before we post WFC. @here
