<aside> 🚧

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.

</aside>

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:

  1. Complicating the user experience for everyone in the ecosystem—both users and developers.
  2. 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:

  1. Substrate-based SS58 formatted addresses:

    (e.g., 16ZL8yLyXv3V3L3z9ofR1ovFLziyXaN1DPq4yffMAZ9czzBD)

  2. 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?