Questions about the Requirement Document

[pimato]

Hey,

I started to read through the readme @Rune23 wrote and want to start a discussion about it.

In Step One :

Step one is a minimal page/“ux box” with a single button saying “create your proxy contract” (or account or something else). Below the button is a small description saying something like “a proxy contract allows you to deposit cryptocurrency to use for instant trading on oasis direct”, reassuring the user that this is the next step in the UX flow.

As our biggest aim is to make the UX as simple as possible, I think we should not use words like proxy contract rather create something symbolic like a bot/servant/waiter. Zandy described it well in the last governance meeting. At DappHub we are thinking about something like in the early days of microsoft words, the bracket. We should create something symbolic which represents safety, security who can hold the users funds.

What do you guys think about it ?

If the user has 0 or close to 0 ETH in his metamask account, there should be a warning above the button saying something like “warning, you need more ETH to pay for gas” - we should estimate the total amount of gas required for the full interaction since it will be quite gas intensive and always ensure the user has enough gas to complete the interaction and withdraw everything.

We cannot estimate the total amount of gas required for the full interaction because we cannot define what "full interaction" means. We had the same problem here: https://github.com/OasisDEX/oasis/issues/319#issuecomment-329698892 and we came to the conclusion that we cannot set a fixed amount of ETH. The user need to be educated about this bad usability issue every dapp has to fight.

To get the best user experiences, should we integrate coinbase instant buy widget ?

[NiklasKunkel]

I think we should not use words like proxy contract

Agreed. This is an implementation layer detail and should be abstracted away from the user. Neither would I want things like bot/server/waiter. Creating an account I think has good abstraction, and is something very familiar to a user from using centralized exchanges. You deposit/withdraw tokens to your account and execute orders from your account. Simple. There is no reason to break this norm.

we should estimate the total amount of gas required for the full interaction since it will be quite gas intensive and always ensure the user has enough gas to complete the interaction and withdraw everything.

Gas estimation is notoriously difficult because it also relies on the gas price which is constantly in flux, especially since most users (I assume, correct me if you believe I'm wrong) use the default MetaMask gas price for transactions. Even solving the problem of current gas price estimation through a custom API of ethgasstation wouldn't guarantee these are the values MetaMask would use. Therefore I agree with @pimato that the solution to this is user education through warning messages. Like @pimato said, this is not a Oasis problem but an ethereum-centric problem.

[pimato]

@NiklasKunkel Your recommendation to use an account as naming the proxy contract is simple and actually very good in my view. Could we all elaborate what kind of benefits the user will get, if he creates an account ?

• saving gas?
• are we going to add a time limited deposit feature, so the funds are going to be transfered back to the user after a while ?
• Creating an Account once and use the trading and margin platform with the same account would be a benefit.

[r001]

I vote for account instead of smart contract. We should have a set of principles at Maker:

1. Use the least possible terms to describe our system.
2. The terms used if possible should be chosen from the set that financial users know, and not invent our own.

Gas: since creation of CDPs can require substantial gas, and if transaction fails users gas will be spent anyway, and this is annoying, I think we should make an effort to estimate gas usage, not as a whole, but at least per transaction.

[pimato]

I agree to those actually very important principles @r001 mentioned.

I am currently thinking about the fact to combine those two steps :

Step one: Create your account Step two: Fund your account

because you need some ETH either-way to create your account. It would be awesome to pay only once for an transaction (create an account/ fund your account).

[Rune23]

Combining step 1 & 2 is possible if the user wants to fund with native ETH, but won't work with other ERC20 tokens. We could check to see if the user only has native ETH, and then present an extra option for step 1 that goes something like "create and fund account with ETH", that makes them jump straight to step 3.

[Rune23]

@NiklasKunkel should weigh in on this, since you're our smart contract expert

[NiklasKunkel]

I am currently thinking about the fact to combine those two steps: Step one: Create your account Step two: Fund your account

Not sure I agree. From a UX point of view I think making each step concise and specific leads to a better experience than one bloated step. I'm assuming the UI would have some kind of text or visuals to educate the user on the details of each step. "Keep things simple" seems to be the driving mantra I got from @Rune23's requirements.

Could we all elaborate what kind of benefits the user will get, if he creates an account ?

An account (proxy contract):

1. Gives the user access to the platform.
2. Allows trustless holding of assets
3. Enables multiple actions to be executed in a single transaction.
4. Can send ETH/tokens to any address
5. Records transaction history for a user (this is useful data for both the user and us).

Something to discuss. Should we allow the user to change the ownership of the account (proxy contract)? My initial inclination is no as I view an account as an identity, but I'm open to hearing counterarguments.

[Rune23]

Not sure I agree. From a UX point of view I think making each step concise and specific leads to a better experience than one bloated step. I'm assuming the UI would have some kind of text or visuals to educate the user on the details of each step. "Keep things simple" seems to be the driving mantra I got from @Rune23's requirements.

Yeah, I agree with this that for the MVP we shouldn't add this option yet. But in the future I think it's a really cool feature to have, when we figure out how to implement it correctly, since something like 90% of our users will probably start from native ETH, so avoiding having to type your password an extra time on initial setup would mean a lot of people would be even more impressed with how easy and quick to use the dapp is. But yeah, lets keep it out of the MVP and save it for a future update

[pimato]

Can send ETH/tokens to any address Allows trustless holding of assets Can send ETH/tokens to any address Records transaction history for a user (this is useful data for both the user and us).

I don`t think those points are a benefit for the user because they can do the same with a normal Ethereum wallet address. So the real benefit is:

Enables multiple actions to be executed in a single transaction.

which can be broken down too:

1. Enables instant and trustless buy/sell for Ethereum based Tokens.
2. Enables decentralised margin trading.
3. No need to wrap your ETH to interact with the dapp.
4. Create one account and use it everywhere (trading/margin).

what do you guys think about those points ?

Something to discuss. Should we allow the user to change the ownership of the account (proxy contract)? My initial inclination is no as I view an account as an identity, but I'm open to hearing counterarguments.

definitely something we want to have in the first versions of the dapp. Maybe in the future.

[NiklasKunkel]

@pimato I like your points better =]

[pimato]

We really need to keep the discussion on this. What do you think about this more complex version of oasis.direct? Thoughts in general ?

new shorter version of the document is out :

step 1

button for creating proxy contract

step 2

header: temporary box showing status of proxy contract transaction - clicking next disabled until it has confirmed, but user can still fill out and choose crypto.

top: show the information (address and QR code) of proxy contract for external deposit

middle: show the crypto icons in proxy contract + personal account: user chooses which one he wants to use

bottom: enter amount of crypto you want to deposit

user clicks next and a transaction to deposit is triggered of the crypto chosen and the amount chosen

if metamask detects an “external transaction” sent to the proxy contract it treats it as if user clicked next with crypto and amount based on the external transaction sent

step 3

header: temporary box showing status of step 2 transaction - clicking next cannot be done until transaction has confirmed

top: choose crypto you want to get

middle: confirm amount you want to trade with + show estimated price

bottom: (if user has sai and wants to buy ETH, or if user has ETH and wants to buy ETH) checkbox to choose if you want to margin trade - ((( choose amount of sai you want to issue (default is amount equal to 2x leverage) - show estimated leverage percentage)))) <- this only shows up if the checkbox for margin trading is chosen

step 4

header: temporary box showing status of step 3 tx5

review step: show the user what he has done and what he has ended up with

if he did a regular trade show the amount he spent, amount he received, and price

if he made a CDP show him cdp data including amount of collateral, amount of debt, collateralization ratio, leverage %, liquidation ratio and stability fee

[pimato]

I had the chance to work a little bit on the new landing page(first step) and the normal website with the second step:

first step:

second step:

[pimato]

After talking with @Rune23 about the new mockups I did a few changes to fit to the new mockups:

Changes:

• Removed the Account section
• Removed the second Token Picker because we only want to focus on which and how much of a token the user wants to spend.
• Description texted changed to a simple version with a bigger Inputfield which will include a "Spend MAX" Button.

[pimato]

Changes:

• Replaced the ticker with a much simpler one, because our mvp will only work with ETH/MKR/SAI
• the whole widget got smaller

[jpritikin]

Is there any way to execute this set of trades as a single ethereum transaction?

[NiklasKunkel]

@jpritikin Yes through the use of a proxy contract you can execute a sequence of transactions with a single signed tx.

[pimato]

Okay,

finally I had some time to work on the new design. I wanted to have a very simple and clean design:

If you want to change your asset, just click on one of it and a picker page will appear:

Would love to get some feedback on this one.

[seriouslylost]

Hi,

The above design looks beautiful and simple, but I am afraid it is hard to scale. Imagine you can borrow Sai/Dai with 127 coins, not the above 6. The UI will become very hard to use. Drop-down? Searchbox? Just my 2 cents

[pimato]

@seriouslylost At first thanks for the feedback and taking your time. I am already thinking about to add a Searchbox on the picker so people can easily search their assets much quicker.

[peculiarity]

Search will fix the problem with fast lookup. What about displaying the actual coins ( listing ) ? @seriouslylost good point btw. In general I like the design. I don't understand what those depositing and buying are?

[pimato]

@peculiarity good point I am going to include the actual balance of tokens in the picker page.

Depositing and buying are actions where you need to do a transaction. I will change that so people know those are transactions you need to make.

[kennyrowe]

@pimato Will there be limits on how much can be swapped or leveraged? Otherwise, this is a very clean familiar look that I think should work very well!

[pimato]

Scenario I

• User does NOT need to create an Account at the beginning
• User picks assets to trade
• User can play around with numbers to get information about:
  • The final price
  • Estimated transactions fees
• If user accept the offer:
  • A) If user has no account —> create a proxy
    • Proceed with B
  • B) If user has an account already
    • 1) If asset to trade with is not enabled on the proxy
      • Enable asset on the proxy (transaction 1)
      • Do the trade (transaction 2)
    • 2)If asset is already enabled on the proxy:
      • Do the trade ( transaction 1)

Positiv:

• Users can play around with the widget without doing any transaction

Negativ:

• User will get confused why he/she needs todo 3 or 2 or 1 transaction at the end (depends if he created his account already, if he already enabled the asset)
• We need to have a contract preloaded with a bunch of crypto that people can call to measure stuff (needed for the price and transaction fees).

[pimato]

Scenario II

• User needs to create an Account at the beginning
  • User picks a few assets he wants to trade with
  • Need to do a transaction for each asset to enable it to the contract
• User picks assets to trade with
• User can play around with numbers to get information about:
  • The final price
  • Estimated transaction fees.
• If user accept the offer:
  • Do the trade

Positiv:

• Clear user experience
• User clearly understand that he has an Account where he sends funds too.

Negativ:

• User can not play around with the widget without an account, so users will first need to pay at least two transactions (but could be even 5-6 transactions):
  • Transaction I (Account creation)
  • Transaction II (enable Asset A on the Proxy)
  • ….. repeat Transaction II for every Asset you want to enable

[pimato]

After a few discussions the last days, we came to the conclusion that we have two scenarios of how oasis-direct could work. Both are not perfect solutions, so we need to find consensus of what is the best way forward. It would be good to have an opinion posted from everyone.

[jpritikin]

Can you imagine changes to the EVM that would permit a smoother user experience?

[peculiarity]

I would go with first scenario. It's more flexible. It includes same operations as scenario II but give you the possibility to play around. Also like in OasisDEX you might use it only for information such as the current price , how much gas it might cost you and etc

[pimato]

It seems we came to a conclusion via chat.makerdao.com :

Oasis.Direct MVP Requirement Plan :

• Using Scenario I
• Iframe widget with simple integration possibility
• Only native ETH to ERC-20 exchange at the beginning
• Only one transaction required

[pimato]

for further discussion : https://github.com/OasisDEX/oasis-direct/issues/2