3 min read

The Clash Between Web and Ethereum Addresses

The Clash Between Web and Ethereum Addresses

TLDR: Many people still assume an "address" either refers to a Web URL or a physical address. This mental model clash with Ethereum Addresses is a cause of friction for many new users. We propose a solution of specialized tools designed to onboard users earlier into the process or more generally, playing around with web3 native design elements that don't share similarities to web2 design elements. Keep the predictability of certain actions but don't make it feel web2.

When you think of the word address. What comes to mind?

Physical Address?

pic: sean patrick

Web Address?

pic: my browser

Addressing an audience?

pic: ICSA

Ethereum Address?

pic: vitaliks public address (at the top)

Addresses can mean many different things, to different people.

And that just about sums up the challenge with many of the Web3 concepts that exist today.

They tend to build off of Web2 ideas.

For example: If you ask someone to give you their address, you might just get some random web URL from the page they were just on or the address to their home.

The concept of an address for many people on the web is still based on the idea of a Web URL or physical location.

Why Web2 Concepts Clash With Web3

One word: expectations.

When we use certain design elements from Web2, we set the user up to expect similar Web2-ish behaviour.

This can lead to issues. 

If people are expecting your application to act like a web2 application because YOU USED Web2 elements, then you can't be surprised when they get stuck or frustrated during use.

Web3 user flows are inherently different and require IMMENSE initial onboarding to understand fully. It is not enough to use older, more comfortable design elements when all that does is set people up for failure and frustration because their expectations weren't properly developed.


Either Onboard Early or Create Web3 Native Design Elements

So I think we have 2 good options here.

  1. Onboard early

This will give the best value for your buck. We should, as a community, funnel new users to tools & DAOs that are designed to bring this knowledge to users.

So you can imagine when you visit a dApp, there is an integration with some onboarding software that walks users through the differences between what they are usually expecting from a website and the dApp they are about to use.

Onboard early. Save time later.

2. Use Web3 Design Elements

Maybe the solution is to really switch things up.

We know:

  • Web3 requires people to build a new mental model
  • It takes time to get used to Web3
  • Sometimes people will confuse Web2 behaviors with Web3 ones.

So what if we decided to add elements to an interface that was completely foreign in its design?

Probably a recipe for disaster.


It might be the UX unlock we need for adoption.

So we might completely remix what a webpage ought to look like in favor of highlighting the benefits of web3 technology by introducing new, and potentially odd design elements to a page.

Things we can play around with:

  1. Input Controls
  2. Navigational Components
  3. Informational Components
  4. Containers

Input Controls

a category of UI elements that allow users to input information into a system.

Nav Components

the things on the interface that help users move around your product

Info Components

how information is shared with users


things holding related content together

32 UI Elements Designers Need To Know
What are UI elements? Discover everything you need to know in this comprehensive UI element glossary, with all key terms explained by an expert.

So lets be a bit more proactive with our users and get their expectations set earlier in the process.

Thanks for reading!