Part 1: Define the problem

What problem are you trying to solve?

It is common that if you use your account on Ethereum, you later can receive a spam token - a token that was transferred without your agreement.

This is a potential security risk, as there might be a case that the token contract is malicious and could drain funds or change the Safe settings when interacted with the contract. For example, a user would want to send a spam token to a null address to get rid of them, and the token contract could do something malicious when executing a 'transfer' transaction.

Moreover, this is also an annoyance: over time, an account may accrue different kinds of spam tokens that were sent to it without account holders' consent. In this case, viewing the asset balances of a token becomes an issue: the spam tokens would clutter the list of tokens. For the Safes, we are filtering the spam tokens with our services. However, user still can interact with a spam token's contract via other means, for example, by making a transaction from a uniswap dapp or another wallet connected via wallet connect.

While the risk of malicious contract interaction can be better reduced with a transaction simulation, we still should add a measure that would identify a spam tokens and warn user of risks associated with them.

What is your hypothesis?

We believe that when we mark the tokens clearly as spam in our interface for any interaction or display of such tokens, then the number of transactions with such tokens will reduce.

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

How do we measure it?

Links:

// Include useful research, such as user tests, competitive analysis, metrics, or surveys.

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

// Who is responsible for leading the shaping process of this problem statement. Owner should be assigned directly after the Great Filter meeting. PM will assist.

Non Goal(s)

// Controlling the scope of solving the problem.

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

// Provided structure is here for guidance and can be altered.

Overview

Rough Scoping & Timeline

// At a high level, what's included in V1 vs. later versions? How big of a project is this? What's the roll out / testing plan?

Risk(s), Key Trade Offs & Decisions

// For example, were there any alternatives considered? What are the value, usability, feasability and business risks and how could we address them?

Concept Mocks

safe-global / safe-pm

Transactions with spam tokens in our interface may lead to security issues for our users. #68