search

5afe / safe

Repo to collect Gnosis Safe ideas, feature requests and epics in order to make the roadmap more clear
23 stars 4 forks source link

Token payment #34

Closed tschubotz closed 5 years ago

tschubotz commented 5 years ago

Story

As a user I am able to use tokens for Safe creation as well as Safe transactions in order to not need ETH for everything.

Background

Acceptance criteria

(Just the most important ones, has to be refined during UX research phase.)

Open questions

Mettenim commented 5 years ago

Will there be a set list of tokens that a user can choose from, or will we allow the use of any token? @tschubotz

tschubotz commented 5 years ago

Will there be a set list of tokens that a user can choose from, or will we allow the use of any token? We need to specifically whitelist tokens, i.e. there will be a list that our backend supports. ETH will always be whitelisted, OWL and DAI are logical first ones. Also perhaps WETH could be another one.

There is no need for a token search right now. It is fine to optimize for 3-5 available tokens right now. Realistically, there won't be a crazy number of tokens anytime soon. And even if so, we can add a search later.

At what point during creation, does the user need to decide for a token? Before we display the address to the user the first time.

What happens if they selected a token, but then deposited ETH? The Safe will not be created until they deposited the minimum token amount. The deposited ETH will be available in the Safe after creation though and can be withdrawn again.

Essentially the user needs to first select a token before we ask them to make a desposit. The selected token cannot be changed afterwards anymore, due to current technical reasons.

There are some edge cases / error scenarios to consider:

tschubotz commented 5 years ago

We also have to consider token payment for the "restore Safe" use case.

Uxio0 commented 5 years ago

Hi @tschubotz, it would not be very difficult to provide an endpoint with the estimation of a safe creation (using ether or tokens, it would be the same)

Uxio0 commented 5 years ago

@tschubotz, https://github.com/gnosis/safe-relay-service/issues/56

Mettenim commented 5 years ago

As per Invision commments: https://projects.invisionapp.com/d/#/console/16397934/340046072/comments/109178966

Mettenim commented 5 years ago

As per @rmeissner request: https://projects.invisionapp.com/d/#/console/16397934/340046080/comments

Mettenim commented 5 years ago

As per @biocom suggestion on V1: (To move fee closer to address section). https://projects.invisionapp.com/d/#/console/16397934/340046081/comments/109189946

This is already implemented in this screen on V2: https://projects.invisionapp.com/d/#/console/16397934/340046078/preview

Mettenim commented 5 years ago

For reference, find the general Invision screen/prototypes here: https://invis.io/Z9PWAYC2JRC

Mettenim commented 5 years ago

Created V5 (V1 with token icons in drop-down menu): https://projects.invisionapp.com/d/#/console/16397934/340756481/preview

tschubotz commented 5 years ago

@posthnikova asked via slack. I'm putting the answers here for future reference:

1) Does selection apply only to Safe creation or to all future transactions? Is it possible to change the selected token later?

It is possible to change it later for future txs. Tech-wise, the user could use a different token for every tx they do. When the user selects RDN for Safe creation, I would pre-select RDN for future txs though.

2) What happens the user chooses one token and sends another? Is it possible to detect which token was sent, the amount and how much is remaining?

I'm not sure I get the question. You mean when the user chooses RDN for payment but send GNO? This should be possible, yes. (Same like using ETH for payment of a GNO transfer.

3) In case there are multiple Safes, does token selection apply to all or it’s possible to choose another token while creating additional Safes?

Tech-wise we could build it both ways. So it's more a UX/product decision what to do. I would actually prefer that we could choose/select different payment tokens per Safe tbh.

4) Do we plan to let users select token when recovering Safe? Sorry if it had been discussed before.

Yes :)

cc @rmeissner @biocom

tschubotz commented 5 years ago
  1. In case there are multiple Safes, does token selection apply to all or it’s possible to choose another token while creating additional Safes?

Richard mentioned to me, that 1 token for all Safes would be easier to implement. I wouldn't restrict ideas, yet, though, and rather explore the ideal case, UX wise. Afterwards, we can cut back on things. But that's something to keep in mind before we finalize the UI ✌️

fairlighteth commented 5 years ago

Thank you for the answers @tschubotz

As for point 2:

  1. What happens the user chooses one token and sends another? Is it possible to detect which token was sent, the amount and how much is remaining?

I'm not sure I get the question. You mean when the user chooses RDN for payment but send GNO? This should be possible, yes. (Same like using ETH for payment of a GNO transfer.

That's what we mean. I think the UI challenge we try to solve is:

Would we change the selected token display on a screen like this https://invis.io/ARPG0XSTJMZ#/345235231_New_Safe_-_Deposit_-Not_Enough_Funds_Received- to GNO (given user sent GNO and not ETH) or just leave the selected token (ETH) but show the adjusted amount (remainder where GNO amount is subtracted).

I know that it's likely not going to be the most common use case, given we assume the user selects the token they intend to send.

rmeissner commented 5 years ago

If the creation was triggered with a specific token (or eth) it cannot be changed. So if the user sends a different token, it will be on the Safe but will not count towards the creation fee.

fairlighteth commented 5 years ago

@rmeissner Oke got it. So selecting the right token is important. Couple of more questions:

rmeissner commented 5 years ago

When starting the creation the client sends the safe configuration (owners, threshold, which token for the creation fee) to the server and the server generates a creation transaction. That includes the configuration and how much will need to be paid in the specifies token. The address of the Safe depends on these parameters. So if one of it changes (e.g. the token for the fee) the address will change.

So keeping that in mind it is important to tell the user that he cannot change the token after the creation has been triggered.

fairlighteth commented 5 years ago

So keeping that in mind it is important to tell the user that he cannot change the token after the creation has been triggered.

Does that mean that the user still can change the token, before having sent any funds? It's only after they sent a certain amount (if not all) of the selected token, that you cannot change it anymore?

rmeissner commented 5 years ago

Changing the token -> new safe address

If the user send any funds already, they will be lost. The funds will only be accessible AFTER the Safe has been deployed. If you change the token, technically we will need to retrigger the creation.

rmeissner commented 5 years ago

Triggering creation = sending the configuration to the server

fairlighteth commented 5 years ago

If the user send any funds already, they will be lost. The funds will only be accessible AFTER the Safe has been deployed.

If the user sent (not enough) ETH funds to a new Safe, then switches the token and sends the full amount (say GNO) will the ETH be available in that new Safe? Because on one hand you mention it being lost but also being accessible AFTER deployment of the Safe. Not sure I missed something.

tschubotz commented 5 years ago

If the user sent (not enough) ETH funds to a new Safe

That means they selected ETH as payment, the app displayed addressA and the user send (not enough) ETH to addressA

then switches the token and sends the full amount (say GNO)

That means, a new addresss is calculated: addressB. The user sends (enough) GNO to this address, so the Safe is created at addressB

will the ETH be available in that new Safe?

Nope, since addressA != addressB, they won't be able to access the ETH.

Because on one hand you mention it being lost but also being accessible AFTER deployment of the Safe.

If the address wouldn't change, they would be accessble after, i.e. if they would send ETH to addressB before sending enough GNO, then the ETH would be accessible.

"Lost" means, if a new address is calculated, then the user won't be seeing the old one anymore.

The reason for all this is, that we use this "trustless deployment" process which ensures that we can only deploy the right code to the address and they can be sure that we only get payment up to a previously signed limit. So the payment token is part of that transaction, also (more importantly) how much they need to pay. For each token, the limit is different due to different exchange rates. Since the token is part of the transaction, a different transaction hash is created and ultimately the address of the future Safe contract will change.

Does this help clarifying this a bit @biocom? :)

posthnikova commented 5 years ago

Project is up for review here: https://invis.io/FXPSG91SV8B#/346046040_01_Select_Token_ (interactive)

I have two versions:

1) The one where we show the list of tokens and all fees upfront: https://invis.io/FXPSG91SV8B#/346046040_01_Select_Token_. This is optimal when the list is short.

2) For longer lists we could display all tokens on a separate screen: https://invis.io/FXPSG91SV8B#/346046079_05_Select_Token_

DmitryBespalov commented 5 years ago

@posthnikova for the 2nd screen, I would show first 3 tokens to select and then additional row that would say "Show more tokens (53) >" that will go to the separate screen.

Alternatively, if the list is big, we cand display first 3 tokens, and then also display button "Show more" that will expand the list to the full screen width, and animate the "Use that token" button to the bottom of the screen. So that the list can be scrollable, and still the button is visible.

tschubotz commented 5 years ago

Thanks for creating these prototypes! 🙌 I commented on Invision 💬

I prefer version 2, because:

What do you think about this version 3? (Optimizing for the 90% use case that users will use ETH and hiding the token payment more)

posthnikova commented 5 years ago

for the 2nd screen, I would show first 3 tokens to select and then additional row that would say "Show more tokens (53) >" that will go to the separate screen.

Good idea, I used it: https://invis.io/FXPSG91SV8B#/346046079_05_Select_Token_ So we show 3 tokens upfront, everything else is hidden on another screen. When the user selects token from the long list it moves to the top of the list on the first screen. If token is selected on the first screen, it stays where it is.

What do you think about this version 3?

I like this version more because this way it's like an additional step for advanced users. So I made a prototype: https://invis.io/FXPSG91SV8B#/346119435_15_Make_First_Deposit_Link_ (interactive)

Wording and some other things are corrected after comments on Invision

tschubotz commented 5 years ago

it's like an additional step for advanced users.

Agree, that's what I thought, too. I commented on Invision that I think we should emphasize the fact, that changing the token would render the previous address useless. And the user should know what they are doing. What's your opinion on the 3 versions @fmrsabino @rmeissner @lukasschor @biocom ?

rmeissner commented 5 years ago

In my opinion it should not be possible to change the tokens once the address has been displayed.

fairlighteth commented 5 years ago

@tschubotz I replied on inVision.

In general I think allowing to change the token could be helpful for experienced users, given we don't dead-wall them in case they chose the wrong token initially.

On the other hand, inexperienced/non-aware users might make the mistake of depositing funds in the wrong Safe address. I think we can mitigate this risk by 'burying' the feature as an advanced step and providing an initial text warning + extra consent in a dialog/popup (see my inVision comments).

rmeissner commented 5 years ago

What are inexperienced users for us? And for whom is this feature?

In my opinion we should not think about experienced/ in-experienced users. For me this is a feature that everybody should use. If we want to hide it, then we don't need to adjust the UX and just keep the current version. I don't think a simple additional step will be a problem in this flow. The user already noted down their recovery phrase so 1 additional button click should not matter. We could also think of other ways to display the estimate to the user ... e.g. we could have a screen that looks the same as the funding screen, but without an address. And the user would need to "reveal" the address to finalise the setup.

fairlighteth commented 5 years ago

@rmeissner I think my definition of inexperienced/unaware is basically anyone not aware of what implications, changing the payment token, will have to the Safe address.

In that light, I agree that given it's a feature we shouldn't necessarily hide it. I'm for having the choice to chance the token, assuming we have a double consent for doing so.

posthnikova commented 5 years ago

New changes are here: https://invis.io/FXPSG91SV8B#/346119435_15_Make_First_Deposit_Link_

What's been done:

https://invis.io/FXPSG91SV8B#/346334625_18_Make_First_Deposit_Change_Alert_

https://invis.io/FXPSG91SV8B#/346335182_20_OWL_Selected_Alert_

posthnikova commented 5 years ago

New version is up for review: https://invis.io/FXPSG91SV8B#/347431584_01_Safe_Creation_ETH_ (interactive)

What's been done after user tests and Stefan's feedback:

1) Choosing token is the first step now with an opportunity to skip

2) Renamed "Retry" to "Refresh"

3) Renamed deposit to "Pay the Safe creation fee"

4) Fee is called "Safe creation fee" consistently

5) Removed text in parenthesis

6) Amounts moved to card

7) "Only send ETH" warnings added

8) Amount to send is now more prominent now

tschubotz commented 5 years ago

Commented on Invision :)

fairlighteth commented 5 years ago

Also commented on inVision, but will also post here, given we've got quite some comments in there:

In my opinion we should keep the 'Safe creation fee' screen as simple as possible. Right now it feels like an overload of options:

I think the screen lacks a clear main action. E.g. the blue main action button should convey in itself, what the main objective will be of this and the upcoming screen.

My proposition would be to:

I think using the label 'Pay with ETH' makes things clear for two reasons: 1 - It implies that the next step will be a 'payment' step (in fact depositing funds..) 2 - You will be using ETH to pay for this

Let me know your thoughts.

sche commented 5 years ago

@tschubotz If a user pays with some token, should this token be displayed by default on the main screen?

rmeissner commented 5 years ago

I like @biocom proposal.

@sche I would say so, but that is probably more important for the spec than for this issue

tschubotz commented 5 years ago

Ux weekly:

posthnikova commented 5 years ago

New version is up for review: https://invis.io/FXPSG91SV8B#/347431584_01_Safe_Creation_ETH_

What's been done:

1) ETH is the default option, all other methods are on the separate screen

2) Changed visualisation so amounts are not like balances

3) Corrected texts

4) Changed text on address screen: "You'll be able to use this address after you create Safe"

fairlighteth commented 5 years ago

Thank you @posthnikova Overall definitely an improvement.

Left some comments on inVision.

posthnikova commented 5 years ago

New version is up for review: https://invis.io/FXPSG91SV8B#/347431584_01_Safe_Creation_ETH_

What's been done: mainly wording changes. I replied to everyone on Invision

JordanTranchina commented 5 years ago

hey everyone, anything I can help with here or on a separate flow? I'm a UX designer

posthnikova commented 5 years ago

Some wording changes: https://invis.io/FXPSG91SV8B#/347431584_01_Safe_Creation_ETH_

tschubotz commented 5 years ago

👍 looks good. Did you have time to work on the other flows already?

posthnikova commented 5 years ago

I have a proposal for changing it from the menu and during sending (change ETH to OWL while sending ETH and change ETH to GNO while sending GNO):

https://invis.io/3XQVZ474E9U

Other flows will be later

posthnikova commented 5 years ago

New version of Menu and sending is up for review (change ETH to OWL while sending ETH and change ETH to GNO while sending GNO):

https://invis.io/3XQVZ474E9U

What's been done:

tschubotz commented 5 years ago

UX sync:

sche commented 5 years ago

@tschubotz If payment methods are safe specific, then following the same logic "Mange tokens" should be safe specific as well.

fairlighteth commented 5 years ago

@sche I understand your point. But here are some points for perspective:

In terms of simplicity, together with the assumption a lot of users will have a single Safe, having a general high level 'manage tokens' might be the most efficient approach.

The argument being that for selecting a payment method you only make 1 choice (the token you want to pay fees with).

For manage tokens you have an equal amount of choices (enable/disable token) as there are tokens available. Multiply that by the amount of Safes and suddenly the burden is on the user to manage all the available tokens on each individual Safe.

Last point is that as for the payment method (token) the user is able to change this on the 'SEND TOKEN' screen, by selecting the current used payment method (token). Thus allowing for flexibility in the user flows.

posthnikova commented 5 years ago

Changes after UX sync: removed "default"

Create Safe: https://invis.io/FXPSG91SV8B#/347431584_01_Safe_Creation_ETH_ https://invis.io/FXPSG91SV8B#/347431644_04_Show_More_Tokens

From the Menu: https://invis.io/3XQVZ474E9U#/350900042_02_Change_Payment_Method https://invis.io/3XQVZ474E9U#/350900043_03_OWL_Selected

Send ETH: https://invis.io/3XQVZ474E9U#/350900050_09_Change_Payment_Method https://invis.io/3XQVZ474E9U#/350900051_10_OWL_Selected

Send token: https://invis.io/3XQVZ474E9U#/350900058_18_Change_Payment_Method https://invis.io/3XQVZ474E9U#/350900059_19_GNO_Selected

fairlighteth commented 5 years ago

We also need token payment screens for: