I strongly support this. As people have pointed out, it would require some coordinated effort but after that the UX improvements would be big.
1 Like
Hello,
Love the effort but want to make sure some of the edge cases are taken care of. At Talisman, we’ve had a few of instances where addresses aren’t actually universal in practice:
-
Sometimes exchanges only support a certain network for ingest of funds. We’ve had users send funds to a deposit address but on a parachain/chain that is not supported by the CEX, and then are told that those funds are not recoverable. It’s reason why our “Copy Funds” in the wallet has so many steps in it. (p.s. we are simplifying that now). Maybe this goes away as AssetHub is adopted.
-
The non-generic ledger apps do not have a universal address. We’ve had users send/receive funds or participate in crowdloans using a Ledger using a different parachain and then not be able to recover funds unless they burn their seed phrase. This should go away with the generic ledger app, but there will definitely be an upgrade issue for devices in the wild as maybe people don’t want to upgrade their ledgers.
-
As tbaut mentions above, pure proxies only function on one particular chain, so assets sent to the universal version of those addresses would certainly be lost.
Those being said, let’s take the pain now and the future will be brighter for it.
- William
This is obviously not true from a technical standpoint (although I fully believe it happens in practive). We should support those exchanges in making sure users can get their assets.
Like it! Keep it simple. 
Nice idea! I think even Kusama and Polkadot can use the same prefix, as there will be a bridge between them anyway.
This is a must-have and must-support proposal. SubWallet is 100% in favor of this idea and we are more than happy to collaborate from the wallet side.
The fact that parachains and relaychains each have a different address is creating more friction than convenience for both users and wallet developers alike. Getting the correct address for a specific network takes an extra 1 to 2 clicks, and that means users are more likely to lose their assets by transferring to the wrong network, especially when transferring to CEX or Ledger (given that they only support independent addresses and networks). This has unsurprisingly led to frustration from users who are familiar with 1 address only for all EVM chains.
The best way to enhance user experience I think we should use 1 address only for both Polkadot and Kusama. This approach also fits with the dApp-centric mindset rather than network-centric. Users can focus 100% on the dApp experience without facing the barrier when switching networks (Polkadot, Kusama, etc…)
On SubWallet, we have also been trying to minimize the address complexity by using Prefix: 42 (starting with 5) as the default address for all wallets since that’s the default Substrate format. However, it doesn’t work very well since parachains and relaychains are using too many different address formats. I believe standardizing all default Substrate, Polkadot, Kusama and parachain address formats to Prefix: 0 type is the way to go.
1 Like
Loving it. Would be wesome if Polkadot, Kusama, and all Substrate base chain all of the same address for users?
I would personally still prefer to have different addresses based on consensus, so one address for everything Polkadot and one for everything Kusama. This makes it clear that you’re “in a different world”.
1 Like
What do you think about running AB Testing for users to try out 2 options and recording their feedback so that we can decide the more optimized option? Whether both Polkadot and Kusama having the same address format or each ecosystem using their own address format is still better than each parachain having their own address format.
Plus, in my opinion we should change the default Substrate format into prefix 0 to be consistent with Polkadot for Polkadot SDK
As we are looking into “linking” claims together, it would be absolutely critical to be able to rely on a unique identifier for all the different accounts. Especially when we look at accounts as string identifiers rather than simple public key encoding, this becomes important. There is some work by the ChainAgnostic group to define standard ways to represent chains and accounts. I opened an issue there to try to come up with a unique way of identifying all accounts under the same namespace. It feels that the outcome of the discussion here would influence the direction forward in the CASA repo, and I am willing to take on the work myself to bridge that gap, once we reach a conclusion here.
Just wanted to make people aware that there is effort made also within other ecosystems and across other ecosystems.
This seems like a bad idea IMO. The unique identifier doesn’t need to be human readable in a friendly way. The rendering should do that. You could just as easily represent data as a QR code, the context should render it appropriately.
This is unfortunately a necessity when subjects must be identified by URIs. A URI must include some representation of the subject, so there has to be a way to serialise such information. Yes, chains do not really care, wallets probably also, but in other contexts a string identifier is a necessity.
I think that you are mixing different problems. You could derive a URI friendly identifier. Example addressing the problem in another context: RFC 9278 - JWK Thumbprint URI
Yes, I am not arguing this. I am arguing that there needs to be a way to represent Polkadot-based accounts as URIs. You could argue that is not dependent on the decision made here, we I could agree with, but it does not mean that one cannot influence the direction of the other.
If you try to attest a claim about a subject, and want to consume it outside of a blockchain runtime, there needs to be a way for the subject to remain “stable” across claims, and that would be the ultimate goal of a serialisation proposal for accounts.
Exactly. So, if you have a general representation, like ‘polkadot:pubkey:…’, the problem might be with the account IDs that are not derived from public keys? Maybe adding special subprefixes for such addresses could work?
Anyways, it seems like a topic tangential to this post that would be better discussed in its own thread with concrete examples and context 
There isn’t usually a way to know if something came from a pubkey or not, they are all cast into this MultiAddress primitive. If you look at some 32 bytes, there’s no way to tell if it has a known private key or if it was generated some other way (like a hash of some data).
It sounds like the format could just be variants of MultiAddress. So, polkadot:Address32:.... A UI can choose how to render the information.
1 Like
That would be an option, yes, but then what to put after AccountId32 would still be decided based on this discussion, or then go with the default way of encoding accounts, which as far as I understand would be the generic Substrate prefix (?)
Almost. What I proposed in my original post here is that all chains within a parent consensus system use the same format. For Polkadot, that is a prefix of 0, and for Kusama it is 2. That means that KILT, Acala, Centrifuge, etc. would all be 0, not 42 (the default Substrate prefix).
I still don’t understand why you even need this prefix in the identifier, since any encoding with a prefix by definition contains the AccountId, any prefix/checksum/rendering info is purely extra and you can still verify that an encoding represents the underlying identifier.
What I am trying to convey here, is that this holds as long as you are dealing with other components within the ecosystem. This information is too specific for anyone outside of Polkadot to care. Plus, the need for the prefix is to simply propose a Polkadot-based URI for account addresses which, again, outside of the blockchain, makes a lot of sense, and that’s the effort CASA and other organizations are trying to bring forward. Anyway, I think this discussion does not pertain this post, and it will probably happen in a new post once we make one to show the way we envision identities their claims to be represented.
All in all, I am all in favor of having the same format used for all chains, and I would go even beyond and say it should be the same for all chains that support AccountId32s, as it will be up to higher level protocols to do something meaningful with them, e.g., namespacing, where appropriate.
Agreed with this, I think we can discuss a prefix to reach a consensus ASAP.
IMO, I believe that using a unified prefix = 0 is beneficial because it is straightforward and currently the prefix used by Polkadot. In the next one to three years, both parachains and wallets can default to using 0 as a prefix. When the number of parachain users grows significantly, they also can then opt to use their own custom prefix to identify their sovereignty.
2 Likes