UX Proposal: Consensus-Based Address Formats

Tech Talk
1

Many newcomers to the Polkadot ecosystem (and even some experienced users) find the varying address formats on different chains to be confusing. I’d like to propose that all parachains within a network use the same address format such that your address looks the same within the Polkadot network (including all parachains).

This would require no state migrations, but would require:

  1. Parachains to update their chainspecs to change their SS58 prefix; and
  2. Wallets/UIs (+exchanges etc.) to change their display formats and probably do some user FAQ.

Format Refresher

There are many resources on the SS58 format (see e.g. Substrate docs, Polkadot Wiki), but as a reminder, the address you see in most wallets (i.e. the one that starts with a 1 for Polkadot or a letter for Kusama) actually contains three pieces of information:

  1. A prefix, telling the UI how to format the address;
  2. An account ID (usually* a public key, usually* 32 bytes); and
  3. A checksum.

Part (2), the account ID, is the only thing that is actually stored on-chain. That means that UIs could all decide to start displaying your address as identical across whatever chains it wanted to (e.g., all parachains that share a parent Relay).

Try it out for yourself: Go to Subscan’s Account Format Transform tool and enter an address. You will get a very long list of addresses in different formats. These addresses that appear different are all the same exact address, but are formatted differently depending on to which chain they correspond. What I am suggesting here is that UIs format these in a single way.

Network Boundaries and Outliers

The original intent of different SS58 prefixes (and thus formats) was to make obvious to a user that they were operating in a different network context. This is not obvious when looking at a plain 20- or 32-byte hex value. But there was never strong consensus on what “different network” meant. I would propose here that a network includes all subprotocols (chains, smart contracts, etc.) that share the same definition of finality. That is, all parachains within Polkadot would use the same address format in UIs (SS58 prefix 0) and all parachains within Kusama would use the same address format in UIs (SS58 prefix 2).

There may be some outliers here. For example, some chains like Moonbeam support Ethereum wallets, and I do not think that these could be cast into the same format based solely on the H160 address and without access to the actual secp256k1 public key.

Some Endnotes

  1. I’ve discussed this a few times in conversation but don’t think I’ve seen it written down anywhere. If there is an existing thread, happy to migrate there.
  2. I don’t know the best way to enact this change. Fellowship RFC is not appropriate because there isn’t a change to the Polkadot protocol. It’s simply a UX recommendation that I hope people decide to adopt and makes life better.

* Major asterisk here, the AccountId can take many variants, and for example a multisig account ID is the Blake2 hash of the threshold/account IDs that compose it, a secp256k1 account ID is the Blake2 hash of the 33-byte public key, an sr25519/ed25519 keypair has a 32-byte public key that actually is the account ID, and so on. Plus parachains can (and some do) define their own concrete AccountId type that is different from the Relay Chain’s. Let’s just say that I was trying to keep this to a one-liner bullet point but it’s not quite so simple.

37 Likes
2

Alternatively, UIs could just ignore the SS58 prefix value in the chain spec and automatically use 0 or 2 based on whether the chain is a relay chain or parachain. Or do that if the SS58 prefix is missing from the chain spec.

The properties field of the chain spec is in general not the most well designed, and ultimately getting rid of it is IMO a better idea.

6 Likes
3

Would absolutely be in support of this - the different address format is constantly confusing new users and causes some issues with CEX on/ off-ramping.

In our HydraDX UI we’ve actually recently abstracted away the 7xxx format of addresses and instead reflect the address as it’s seen in the connected wallet - e.g. the majority of the time when “allow use on any chain” or a talisman wallet is connected, you would see the Substrate format, so users are seeing consistent address in our app and in their wallet:

image

7 Likes
4

I think it would be a favorable change if there are no technical limitations.

As a user, I believe it is the expected behavior to maintain the same address for the entire Polkadot or Kusama ecosystem and switch networks, similar to how other ecosystems operate. As a new user when creating my first wallet, it took me a while to realize that the initially presented address was a generic Substrate address and not specifically for Polkadot.

3 Likes
5

Yeah true, they could also offer an option, like have the default be to use the parent relay prefix, but have a button where users can say “use chain-specific formatting”.

2 Likes
6

If you’re change encoding then you might consider cascading behavior, maybe by checking how zcash and penumbra use F4jumble.

You can bruit force prefixes or suffixes of an F4jumble encoding too, but if there is metadata in the address, then F4jumble raises the difficulty to similar levels as as bruit forcing other things.

I suppose public keys remain harder than anything symstric so F4jumble of a pure public key does nothing. Also, some metadata looks irrelevant if all signatures contain the metadata too, but again depends.

Some context in ZIP316 and penumbra/docs/protocol/src/protocol/addresses_keys/addresses.md at 47a226497d1c7095222ffc04ffe973b6b4ab832f · penumbra-zone/penumbra · GitHub

Alright…

Zcash seemingly uses F4jumble so the padding in their unified address cannot give users the impression that they compared more bits than they actually did. Afaik Penumbra uses F4jumble purley because Zcash does, but maybe they also have a unified address since they’ve multiple SNARK iterations.

tl;dr We should not give users the impression that they’re comparing key bytes when really they’re comapring metadata or padding.

7

Thanks for the proposal Joe, I think this would be a very welcome change. We need a lot of communication, but UIs could potentially change this behavior at their own pace. Peer pressure and user feedback would then do the rest.

5 Likes
8

But wouldn’t this go against what you propose here? Aka having one account address representation per consensus.

I also heard from Gav at some point that this was the idea from the beginning, but we derailed a little bit from it :sweat_smile: I’m also in favor of having one ss58 prefix per consensus as it makes stuff more easy for users :+1:

9

yes yes yes a thousand times yes. This would massively reduce complexity for the end user. While I understand it’s and adjustment and some people would lose their vanity addresses on certain networks, this is a MUCH required change and a major gripe / complexity for new comers to Polkadot.

It also helps to simplify the usage of system chains, e.g. asset hub. If you have one address for everything UIs can also start to abstract away the different “chains”. This could have second orders of simplification that would further the UX on Polkadot.

ship it

6 Likes
10

Passing the message to the Bifrost team :rainbow:

2 Likes
11

Yes but there is no way to force people to render an address some way. It’d be like saying, “you aren’t allowed to display addresses with a QR code”.

I’m proposing that apps should make the default UI behavior is based on consensus. I hope that for the vast majority of people this will make for a better experience, but there isn’t much to do if someone wants to see things in a different way :person_shrugging:

1 Like
12

This would make the polkadot UX significantly improved. 100% behind this.

2 Likes
13

100% support it! Having said that, I’ll be happy to know why it’s not like this from the beginning. Meaning, I’m sure people were already thinking about it and eventually decided to go with different addresses. What was the reason? Maybe it was a good one.

14

I’m not entirely sure. Like @bkchr said, this was the original intent. I think that in the early days there was some prestige in claiming a prefix, and then it caught on. I don’t know, it’s the past, let’s fix it and make it better for the future.

2 Likes
15

The one thing I think will be tough is the transition period. If you have a CEX telling you “deposit to ABC” and then a wallet/Explorer/ledger/Vault that displays it as a transfer to DEF, ppl will have a hard time realizing it’s all OK. Same for ppl holding for a while.

Also we need to make sure CEX actually support this. To have this transition period as short as possible, I’m thinking about some coordination, where every UI gets ready to ship it a certain day. This could create some noise around it, and force more devs do it. Also we must have pjs apps/extension support this, which means a new release for the extension (hasn’t happened in years).

Edit: some other toughts from the top of my head:

  • pure proxies having the same address cross chain, but actually being inaccessible on all, but the chain it’s been created on.
  • an old user inputs his mnemonic into a wallet, expects an address but gets another one
2 Likes
16

As a mod, I encounter and attempt to help a lot of confused new DOT holders. There are many, many reasons for their confusion, but Polkadot’s address system is definitely a significant one.

A unified address format would be a major boon to non-technical users who don’t want to get into the weeds.

1 Like
17

This is the biggest concern - It will need a co-ordinated approach, with the hardest change being getting the CEXs to complete the work.

It’s deserving of a proper project with resources assigned to manage it end to end.

1 Like
18

I’m glad someone finally opened this discussion. I’m curious to see if we will be able to do it and how long it will take. I spent too much time explaining addresses to newcomers. :smile:

19

This could be achieved today with no changes on the protocol side, just by using @polkadot/keyring to reformat the address for the UI. When it comes to interacting with the chain then the keyring can then ensure it is correctly formatted with the expected SS58 prefix.

This is far from optimal but Dapps could indeed be opinionated and do this today. It could be done this way as a means of experimenting and testing whether there is an increased throughput of whatever metric you envisage measuring. If there is an uptick of metrics then it could be taken beyond the UI and to the core protocol.

As others have mentioned, there is a significant challenge coordinating with the ecosystem - this is somewhat unrealistic given not all maintainers of dapps today are active and / or responsive.

20

This is exactly what we need to attract more users to Polkadot.

I’ve often heard that different addresses for each Polkadot chain are cumbersome and discouraging for newcomers used to Ethereum, L2’s, and Metamask, a one-address-fits-all approach.

In my opinion, this will also significantly improve the cross-chain UX, adding a lot to Polkadot’s value proposition regarding interoperability, security, efficiency, and inclusivity.

Along with wallets like Talisman, Nova, and SubWallet, this brings a new level of UX.

It will for sure require the collective efforts of many ecosystem actors, but I’m sure all Polkadot ecosystem agents will contribute as much as possible to make things happen. I guess we are all here ready for it.