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.
As of today, there are over 150 registered entries 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 using entirely different account systems.
This fragmentation complicates the user experience, as users are often confused about why they need different addresses across the ecosystem or why their address changes depending on the wallet or dApp they use. This, in turn, puts pressure on developers who are trying to build the best possible experiences. While there may be valid reasons for using different prefixes, we will walk through these and propose a solution that addresses the underlying issues in a more streamlined way.
The problem summary
As discussed in the forum post in more detail, the current approach creates numerous UX challenges, and there are still problems it doesn’t address, including:
- Complicating the user experience for everyone in the ecosystem—both users and developers.
- Users accidentally sending assets to the wrong chain, whether it’s an exchange account, hardware wallet, or proxy. Fortunately, the last two are being addressed.
Currently, we primarily see two types of address formats (and wallets) in use with ecosystem front ends:
-
Substrate-based SS58 formatted addresses:
(e.g.,
16ZL8yLyXv3V3L3z9ofR1ovFLziyXaN1DPq4yffMAZ9czzBD) -
EVM-based H160 addresses:
(e.g.,
0x6B175474E89094C44Da98b954EedeAC495271d0F)
To streamline the process, we can break these problems down into smaller tasks and propose solutions for each, keeping the individual tasks manageable and focused.
Fragmentation problem
In the first part, we will focus on the fragmentation issue caused by SS58 prefixes.
Most Substrate-based chains use account systems compatible with this format, making it one of the biggest obstacles for users — even the ones building on Polkadot — to fully understand.
Why is the same underlying account represented with completely different address on each chain?
The SS58 format isn’t a “prefix” in the typical sense you would normally think about. It’s an address format that uses a prefix for the encoding function of the public key to generate a unique-looking address.
In most cases, addresses encoded with the same prefix will start with the same few letters. However, it doesn’t just change the first few characters — it alters the entire address. This causes confusion, especially compared to other ecosystems, where the same address can be reused across rollups or even solo chains.
While this system initially looks cool and promotes greater security, it becomes problematic when users want to use the same account across 50+ app chains. It creates friction when trying to build a seamless, familiar UX for users across the ecosystem.
The proposed solution is to unify the address format for all compatible chains within the Polkadot ecosystem. However, this comes with some implications that need to be addressed, and we’d like to discuss these with the broader community before moving forward with a formal proposal.
Wallets, dApps and informing users
There will be a transition period during which all wallet interfaces, dApps, and other platforms will need to be updated to inform users of the change.
We will create detailed guides to help developers ensure a seamless transition, along with resources to address the UX challenges. Additionally, we’ll provide explanatory documents and tools for users who may encounter issues during the transition.
Polkadot vault
Until recently, the go-to cold wallet provider used chain prefixes for account derivation and address display. We’ll need to guide users of older wallet versions to ensure a smooth transition during this change.
Exchanges
We generally see that CEXs are very rigid and resistant to change. This change subsequently worsens the issue of users sending funds to the wrong chain to on-ramp, because all of the address will look correct. One potential solution is to adopt address prefixes as suggested by EIP-3770, where the destination chain prefix is a human-readable short name, similar to the network field in our current SS58 registry. This will be discussed in more detail later in the proposal.
Fortunately, the reverse scenario — sending funds from a CEX to the wrong chain — typically doesn’t result in lost funds, as the accounts are interoperable between all of the compatible chains, but it still presents an UX issue. It will take time for CEXs to adapt to new address formats, and they may continue to require the old formats for withdrawals. To address this, wallet and dApp UIs will need to accommodate this by providing options to copy the appropriate address format.
Solving the fragmentation
We are proposing to use the following:
-
Prefix:0 for compatible Polkadot parachains (usually starting with ‘1’)
All compatible chains would use the same address format, allowing users to easily recognize their accounts across different chains, and eliminating the need for the SS58 registry in the current format. There is an ongoing referendum on Bifrost to adopt this prefix for their chain already.
-
Prefix:42 - Substrate generic address format (usually starting with ‘5’)
This prefix was supposed to be used by chains that don’t want to connect to Polkadot or Kusama relay-chains. Some wallets, like SubWallet and Talisman, already use this format by default to display all addresses. However, in the long run, chains that want to consider connecting to Polkadot or Kusama might want to use relay respective prefixes to prevent migration later on. -
Optional Kusama prefix discussion posted in separate thread
Other suggestions
If you have any alternative suggestions, we encourage you to share them in the discussion.
Sending funds to correct chain
As explained earlier, another part of the problem is identifying the destination chain for asset transfers to prevent mistakes. While this is usually not an issue within a single dApp, it becomes problematic in the context of app chains. One promising solution is using readable address prefixes, as outlined in EIP-3770.
We recognize that this is not fully compatible with Substrate-based addresses, as the proposal doesn’t support 32-byte addresses, let alone SS58 formatting. However, this doesn’t pose a significant risk to users. It means users won’t be able to send tokens to unsupported addresses in unsupported applications, which is generally better than risking the loss of funds.
The advantage of this approach is that it helps users understand that their address or account is the same across different chains. This pattern, while not yet fully accepted by Ethereum, is already implemented in various ecosystems and used by apps like Gnosis Safe.
Summary
Together, these two proposals can significantly enhance the user experience within the Polkadot ecosystem. While they come with challenges, we will make sure all builders have the resources they need to make this transition as seamless as possible. We welcome any feedback on the proposal before posting it as a WFC (Wish for Change).
Note: This initiative serves as guidance only — chains and dApps are free to choose their own approach, as this is mostly a front-end matter of how account addresses are displayed. We highly recommend updating the on-chain SS58 prefix as this is the source of truth for many UIs and libraries and mismatch could potentially cause ledger and vault apps to stop showing correct address. We hope the benefits will be clear and that projects will come together to improve the overall UX in the ecosystem.
