# UX Proposal: Consensus-Based Address Formats **URL:** \ **Category:** Tech Talk\ **Tags:** ux\ **Created:** [February 8, 2024, 8:33am UTC](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072 "2024-02-08T08:33:08Z")\ **Posts on this page:** 15\ **Page:** 3
**Author:** ![josep](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/josep/32/2619_2.png) [@josep](https://forum.polkadot.network/u/josep)\ **Post date:** [April 7, 2024, 1:24pm UTC](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/41 "2024-04-07T13:24:23Z")
First and foremost I want to say that I wholeheartedly support this initiative. Although, the following comment: > [@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 identical across whatever chains it wanted to (e.g., all parachains that share a parent Relay). 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](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/2) 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? 🙏 ---
**Author:** ![bkchr](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/bkchr/32/27_2.png) [@bkchr](https://forum.polkadot.network/u/bkchr)\ **Post date:** [April 8, 2024, 2:53pm UTC](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/42 "2024-04-08T14:53:55Z")
> [@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 on chain. It was added to for example use it in [contracts](https://github.com/paritytech/substrate/pull/7810). (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. > [@josep](#): > > 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. Fine to do it this way. I would assume that if the proposal here gets enacted, chains change this prefix to Polkadot/Kusama. ---
**Author:** ![josep](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/josep/32/2619_2.png) [@josep](https://forum.polkadot.network/u/josep)\ **Post date:** [April 8, 2024, 3:18pm UTC](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/43 "2024-04-08T15:18:33Z")
> [@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. > [@bkchr](#): > > 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. 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: > [@joepetrowski](#): > > 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. All I’m saying is that it’s a bit more than a UX recommendation, because it does have some some on-chain implications. ---
**Author:** ![bkchr](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/bkchr/32/27_2.png) [@bkchr](https://forum.polkadot.network/u/bkchr)\ **Post date:** [April 8, 2024, 3:22pm UTC](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/44 "2024-04-08T15:22:36Z")
> [@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. > [@josep](#): > > All I’m saying is that it’s a bit more than a UX recommendation, because it does have some some on-chain implications. 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. ---
**Author:** ![jak-pan](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/jak-pan/32/1962_2.png) [@jak-pan](https://forum.polkadot.network/u/jak-pan)\ **Post date:** [June 26, 2024, 12:54pm UTC](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/45 "2024-06-26T12:54:48Z")
> [@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 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 =) ) ---
**Author:** ![jak-pan](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/jak-pan/32/1962_2.png) [@jak-pan](https://forum.polkadot.network/u/jak-pan)\ **Post date:** [June 26, 2024, 12:59pm UTC](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/46 "2024-06-26T12:59:55Z")
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) ---
**Author:** ![gavofyork](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/gavofyork/32/189_2.png) [@gavofyork](https://forum.polkadot.network/u/gavofyork)\ **Post date:** [July 8, 2024, 11:03am UTC](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/47 "2024-07-08T11:03:05Z")
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. ---
**Author:** ![jak-pan](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/jak-pan/32/1962_2.png) [@jak-pan](https://forum.polkadot.network/u/jak-pan)\ **Post date:** [July 9, 2024, 11:26am UTC](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/48 "2024-07-09T11:26:41Z")
[x.com](https://x.com/VitalikButerin/status/1810633473750683974) There is similar thing going on in ETH ecosystem. I think it would be super beneficial to be compliant if possible. ---
**Author:** ![bLd](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/bld/32/303_2.png) [@bLd](https://forum.polkadot.network/u/bLd)\ **Post date:** [July 13, 2024, 10:41pm UTC](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/49 "2024-07-13T22:41:55Z")
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. ---
**Author:** ![bkchr](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/bkchr/32/27_2.png) [@bkchr](https://forum.polkadot.network/u/bkchr)\ **Post date:** [July 23, 2024, 1:39pm UTC](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/50 "2024-07-23T13:39:15Z")
> [@jak-pan](#): > > [x.com](https://x.com/VitalikButerin/status/1810633473750683974) There is similar thing going on in ETH ecosystem. I think it would be super beneficial to be compliant if possible. Sounds like a good idea, but it seems that they currently don’t support 32 byte addresses: [x.com](https://x.com/adietrichs/status/1810642012695154726) ---
**Author:** ![ThomasR](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/thomasr/32/1227_2.png) [@ThomasR](https://forum.polkadot.network/u/ThomasR)\ **Post date:** [August 28, 2024, 9:34am UTC](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/51 "2024-08-28T09:34:12Z")
Hi guys, Have we defined a standard in the end for all chains ? Hydration uses the generic address and prefix 5xxx → Is it where you want to go ? Or is it the prefix = 0xxx ? Or is it Polkadot prefix on Polkadot side and Kusama prefix on Kusama side ? ---
**Author:** ![jak-pan](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/jak-pan/32/1962_2.png) [@jak-pan](https://forum.polkadot.network/u/jak-pan)\ **Post date:** [August 28, 2024, 12:37pm UTC](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/52 "2024-08-28T12:37:34Z")
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: 1. unified substrate addresses. 2. 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. ---
**Author:** ![Alex](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/alex/32/765_2.png) [@Alex](https://forum.polkadot.network/u/Alex)\ **Post date:** [September 15, 2024, 9:06am UTC](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/53 "2024-09-15T09:06:16Z")
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. ---
**Author:** ![sodazone](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/sodazone/32/7216_2.png) [@sodazone](https://forum.polkadot.network/u/sodazone)\ **Post date:** [September 15, 2024, 8:23pm UTC](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/54 "2024-09-15T20:23:36Z")
> [@Alex](#): > > Because even if a mishap happens I still control the key and don’t lose my funds. 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… ---
**Author:** ![jak-pan](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/jak-pan/32/1962_2.png) [@jak-pan](https://forum.polkadot.network/u/jak-pan)\ **Post date:** [September 16, 2024, 3:06pm UTC](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072/55 "2024-09-16T15:06:40Z")
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 > [@Unifying Polkadot ecosystem address format](https://forum.polkadot.network/t/unifying-polkadot-ecosystem-address-format/10042): > > Unifying Polkadot address format This initiative falls under the UX Bounty scope and the necessary resources will be covered by its budget. You can find all relevant materials [here.](https://www.notion.so/UX-Issue-1-Unified-Address-Format-597d5387b5db433ba828020b31a14daa?pvs=21) As of today, there are over 150 registered [entries](https://github.com/paritytech/ss58-registry/blob/b6f5ca9b4203ad293e487476cf711cb5f2793a76/ss58-registry.json) in the Polkadot ecosystem using different SS58 address prefixes. This creates significant fragmentation, as each prefix represents an entity with a unique address format. Some projects, like Moonbeam and Myth, don’t even use this registered prefix as they are usin… [Previous page](https://forum.polkadot.network/t/ux-proposal-consensus-based-address-formats/6072.md?page=2)