UX Proposal: Consensus-Based Address Formats

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.

What am I missing here? :pray:

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.

1 Like

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.

1 Like

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 =) )

2 Likes

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)

2 Likes

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.

4 Likes

x.com There is similar thing going on in ETH ecosystem. I think it would be super beneficial to be compliant if possible.

2 Likes

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.

1 Like