Known addresses: design decisions

Links
Display human readable names for known addresses #337 🐱
Display human readable names for known addresses #1638 🐱
2020-11 Kickoff: Known addresses 📆
Hypothetical press release 📆
List of known contracts 📆
Spec: Human readable names for Known addresses 📆

Platform: web, mobile

App version: tbd.

Which problem do we solve?
See 1 - Owners don’t know what they’re signing 📆.

How does the feature fit into the product and larger product decisions?
This will change the appearance of addresses in transactions list, details and in address book.

What are the metrics and KPIs we will be measuring for this feature?
tbd

Is there user research or quantitative data informing decisions made here?
Data from discovery interviews Q1 2020 💡
Insights from discovery interviews Q1 2020 💡

Screens

1. Contract interaction (undecoded data) – known address

2. Contract interaction (data decoded) – known address

3. Contract interaction (ERC20 token approval) – known address

4. Send – known address

5. Settings change – add owner

6. Safe app transaction – known address

7. NFT transfer – known address

8. Contract interaction when known address is in an address book

9. Contract interaction, known address is in an address book (approveHash call of an imported Safe to another imported Safe)

10. Contract interaction when there is no mapping

11. Replace owner – known address

12. Remove owner – known address

13. Set fallback handler – known address

14. Change mastercopy – known address

15. Safe creation – known address

16. Enable module – known address

17. Disable module – known address

Main design decisions

1. How to display known addresses

The simplest solution is to change the name and swap the identicon for a logo:

The alternatives were to show different labels and checkmarks:

2. To show mapping or not when a parameter inside decoded data is a known address

Don’t look for addresses inside decoded data in the first version.

3. How to differentiate from address book entries

In the first version there is no visual differentiation. Reasoning:

• Faster shipping: reuse existing UI.

However, in the future the user should be able to visually differentiate between local address book entries, safe app names and known contracts. If the same Safe is observed by different owners with different address books they could have different appearance for the same contracts. This can be confusing.

Not applicable on mobile because there is no address book.

4. Does address book or backend have a priority

Local address book name has a priority over the name that came from backend. We show identicon and custom name when the user has added a known contract to the address book:

Reasoning:

• Faster shipping: reuse existing UI.
• If the backend had a priority over custom names it could cause confusion.

Not applicable on mobile because there is no address book.

5. To show Safe app logo for Safe apps transactions or not

Safe apps transactions are a different feature and part of the unified transaction list issue. We show them as contract interactions.

User tests – insights, changes after user tests

tbd

Changes after release, metrics

tbd