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 (inc…

[image] sodazone: the problem might be with the account IDs that are not derived from public keys? Maybe adding special subprefixes for such addresses could work? 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 y…

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 u…

[image] joepetrowski: 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…

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 …

First and foremost I want to say that I wholeheartedly support this initiative. Although, the following comment: [image] joepetrowski: 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 identica…

[image] josep: 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. The prefix is there o…

[image] bkchr: 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. [image] bkchr: As @joepetrowski correctly said the transactions contain the public key …

[image] josep: 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) They can not really do this. However, the UI could also just take the SS58 from the relay chain the parachain is connected to. […

[image] joepetrowski: exchanges 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 re…

UX Proposal: Consensus-Based Address Formats

Tech Talk

jak-pan September 16, 2024, 3:06pm 55

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

Topic		Replies	Views
Unifying Polkadot ecosystem address format Ecosystem ux	29	2182	May 21, 2025
What is substrate address? Can account holder receive/send funds using it? Tech Talk	15	1999	November 22, 2023
UX Bounty - Unified Address Format Update Ecosystem ux	1	127	September 23, 2025
Unifying Kusama ecosystem address format Ecosystem ux	7	216	December 20, 2024
How will wallets work in JAM? Tech Talk	6	345	August 26, 2024

UX Proposal: Consensus-Based Address Formats

Related topics