johannesmoormann commented 2 years ago

Part 1: Define the problem

What problem are you trying to solve?

Spam tokens on Mainnet are a present issue, especially for publicly known Safes, and are likely to increase on L2s due to reduced spam costs. The manually curated spam token list does solve the issue of spam tokens appearing in our users interfaces.

What is your hypothesis?

What value does this bring to our customer and/or our mission? What is the goal?

Information provided by the interface such as total portfolio balance becomes irrelevant or misleading. Spam tokens are a highly subjective manner and we do not have a clear definition of what a spam token is nor is it likely that we can keep up with a manually curated spam token list. Increased loading times for Safes with a high number of spam tokens. Our L2 strategy opens up the door for low transaction costs on L2s make spamming more likely. Entities providing their Safe Address Spam tokens are a highly subjective manner and we do not have a clear definition of what a spam token is nor is it likely that we can keep up with a manually curated spam token list.

How do we measure it?

Links:

Top 5 Safes in terms of ETH value with Tokens marked as Spam or Misleading by Etherscan on Mainnet

9/10 of highest USD value assets: https://gnosis-safe.io/app/eth:0x220866B1A2219f40e72f5c628B65D54268cA3A9D/balances 2/3 of highest USD value assets: https://gnosis-safe.io/app/eth:0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4/balances 2/10 of highest USD value assets: https://gnosis-safe.io/app/eth:0x78605df79524164911c144801f41e9811b7db73d/balances 1/6 of highest USD value assets: https://gnosis-safe.io/app/eth:0xC61b9BB3A7a0767E3179713f3A5c7a9aeDCE193C/balances 1/6 of highest USD value assets: https://gnosis-safe.io/app/eth:0xDCA6aB9508D28c0eB7b120b8252041edcb56753F/balances

Part 2: Shaping the problem

// Once the problem statement has passed the Great Filter, work with the team on the problem statement and elaborate on the following points to create more certainty around the problem and possible solutions. Make sure to identify dependencies and invite the necessary stakeholders early into the shaping process.

Problem Owner

@schmanu

Non Goal(s)

Dealing with NFTs (ERC 721)

Solution

// At the end of the process, if possible, leave only the solution here that you want to be considered during the prioritization vote. Move all other solutions or ideas to Alternative solutions.

Solution 1: Allowlist using Tokenlist Standard

New Safe setting to only show ERC20 tokens from official tokenlists. Show verification level for each ERC20 token to build trust. For the tokenlists we use a selection of lists from the Uniswap Tokenlists standard.

How does the solution work?

By default: Only verified tokens are displayed to the user
- verified means: Appears in at least one tokenlist
- In the Settings / on the Asset Page is a toggle to display only verified tokens
- Security by default ⇒ only verified on by default
In the Assets Page we display a badge next to ERC20 Tokens indicating if they are verified and by how many lists:
- We have three verification states:
  - verified (green) (in at least two tokenlists)
  - verified (yellow) (only on one tokenlist)
  - not verified (in no tokenlist)
Give a warning when attempting to transfer unverified tokens
- before submitting a transaction users should have to “Accept the risk” first
- Overlapping the Submit Button or where we usually display errors on the lower side of modals or elsewhere?

Rough Scoping & Timeline

Implementation Tasks (by Team)

🤳🏼 Mobile (if we wanna keep mobile / web in sync)

[ ] Toggle “only verified”
[ ] Warning when creating transfers for unverified tokens
[ ] Badge

🎨 Design

[ ] Warning before interacting with unverified ERC20 tokens (send funds modal)
[ ] Badge + Info
[ ] Toggle to show all tokens / only verified tokens
[ ] (Same for mobile)

🐙 Web

[ ] Add Badge to tokens
[ ] New option to show all / only verified tokens / balances
[ ] fetch only trusted / verified token balances (If Setting is active)
[ ] warning when creating transfer(s) for unverified token
[ ] Update react-gateway-sdk TokenInfo type / getBalancer Params
[ ] handle networks without tokenlists

📱 Apps

[ ] Ping App team to possibly include warnings for Tx Builder?

🛣️ Infra

Change getBalance() API

[ ] Fetch (selected) token lists and update them (daily?)
[ ] Add verified parameter / reuse trusted parameter. If verified only return tokens that are verified by at least 1 token list

[ ] Return verification info in TokenInfo for networks with token lists:

{
  "fiatTotal":"332.64618",
  "items" : [
    {
      "tokenInfo" : {
        "type" : "ERC20",
        "address" : "0x9C58BAcC331c9aa871AFD802DB6379a98e80CEdb",
        "decimals" : 18,
        "symbol" : "GNO",
        "name" : "Gnosis Token on xDai",
        "logoUri" : "https://safe-transaction-assets.gnosis-safe.io/tokens/logos/0x9C58BAcC331c9aa871AFD802DB6379a98e80CEdb.png",
        "verifiedBy" : [
          {"name": "Uniswap Tokenlist", "url": "https://gateway.ipfs.io/ipns/tokens.uniswap.org"},
          {"name": "Zerion", "url": "https://tokenlist.zerion.eth"},
        ] | "unavailable" // for networks without token lists?
      },
      "balance" : "1000000000000000000",
      "fiatBalance" : "216.42783",
      "fiatConversion" : "216.4278360245963"
    },

[ ] Return in ChainInfo if a chain supports tokenlist verification
- Or we deduct it by some other value such as “unavailable” in the verifiedBy field of the tokenInfo Risk(s), Key Trade Offs & Decisions
  Pros:
Most secure approach: Unexperienced users won’t be intimidated to interact with spam tokens
Those token lists are publicly available and actively maintained
Can be done in backend ⇒ Good performance
Quite common approach: Most DEXes use such lists in their auto-completion to avoid people falling for scams

Cons:

Some especially newer tokens or liquidity pool tokens won’t be included. This could cause confusion / panic / support requests
Not customizable.
Not supported for all networks?

Concept Mocks Mock_not_verified Mock_verified

Alternative solutions & ideas

Open Questions

rmeissner commented 2 years ago

Could we be more specific what the problem is (or what the sub problems are)?

What I go from the issue so far:

There is no clear process how to mark a spam token nor is there a definition what is a spam token
It is not feasible to maintain a spam token list manually
Spam tokens have "wrong" value

The problems above would be more problems that should be handled by the infrastructure team in my opinion and not web.

Related problems that would be more in the scope of the web app for me would be:

User cannot report spam tokens
User cannot locally hide specific tokens
User cannot toggle the spam token filter (always "on" right now)