Oftentimes it happens that people send tokens not to a recipient they intend but to a token contract address. In many token contracts this is irreversible transaction: the tokens can't be recovered and the transaction can't be reconciled. We want to increase chances of preventing such mistakes.
What is your hypothesis?
We believe that if we warn users that they are sending tokens to the token contract itself and not to some other address, then the number of the transfer transactions made from safes to token contract addresses will reduce. In this way we would prevent the potential mistakes.
What value does this bring to our customer and/or our mission? What is the goal?
This will make our interfaces more safe to use and reduce potentially costly mistakes that would result in the loss of funds of our users.
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?
Part 1: Define the problem
What problem are you trying to solve?
Oftentimes it happens that people send tokens not to a recipient they intend but to a token contract address. In many token contracts this is irreversible transaction: the tokens can't be recovered and the transaction can't be reconciled. We want to increase chances of preventing such mistakes.
What is your hypothesis?
We believe that if we warn users that they are sending tokens to the token contract itself and not to some other address, then the number of the transfer transactions made from safes to token contract addresses will reduce. In this way we would prevent the potential mistakes.
What value does this bring to our customer and/or our mission? What is the goal?
This will make our interfaces more safe to use and reduce potentially costly mistakes that would result in the loss of funds of our users.
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
Alternative solutions & ideas
Open Questions