[EPIC] that price thing

[kremalicious]

Figure out the best UI to get the values needed for publishing:

Battle plan

• [x] new UI for fixed price
• [x] new UI for dynamic price
• [x] new price form widget
• [x] dynamic price: collect and pass correct values to publish method
• [x] output price on asset details page
• [x] output price in asset teasers
• [x] fixed price: wait for new fixed contract, and addition to lib-js
• [x] fixed price: collect and pass correct values to publish method
• [x] visual distinction between fixed/dynamic price on Price output
• [x] output price in asset preview during publish
• [x] fix price display when user is not connected to correct network (should get fixed with https://github.com/oceanprotocol/market/pull/51)
• [x] figure out UI for liquidity/pool infos/providing liquidity/removing liquidity
• [x] output all possible fees during asset creation

User Stories

1. As a publisher I want to receive 10 OCEAN when someone downloads my data set.
2. As a publisher I want to receive 10 OCEAN when someone runs a compute job on my data set. ...

Ideas

• Should we have a distinction between Use (Download/Compute) & Trade, like we prepared for asset details already?
• create data token for each data set?
• have user decide on data token ticker name?

[kremalicious]

Based on what technology currently provides, this would be a simple UI for it from #37:

Good for initial testing but obviously does not make sense for most users.

To support the above mentioned user stories first, it would be great to show a conversion between, well, something... So user sees value in OCEAN/EUR. I'm not sure yet how exactly to go about that, ideas?

[kremalicious]

Trent's initial mockup:

[kremalicious]

Have a split in 2 flows:

1. Simple

Ask for OCEAN, then OCEAN is the data token. No involvement with data tokens at all. In the DDO, set the data token address to the OCEAN token address, where then cost represents the user-entered amount of OCEAN.

For all price output, use the data token address in DDO to figure out the respective token symbol.

2. Advanced

Hidden by default. Allow all the options with creating a data token.

[kremalicious]

new UI in #37 to show where we are heading:

[alexcos20]

Each market can :

• deploy it's own datatoken
• set a fixed price (say 1 DT = 1 OCEAN)
  • use that DT under the hood for all published assets.

We can have a simple smart contract that can do fixed price swap. (ration and address are set in the constructor)

[kremalicious]

Sounds good from frontend side for solving the simple use case. We could continue to show OCEAN but in the background it would be WOCEAN or DOCEAN or something.

For advanced use case we could continue to have this as the place to create a new data token. Although from a user perspective I can't really think of a good use case where it makes sense to have a data token for each data set.

If we go with something like a stable data token for all published assets in market, then we could ditch the advanced interface altogether during publish

[trentmc]

Each market should not have its own datatoken, for the reasons I give here: https://bigchaindb.slack.com/archives/CNDG1849Z/p1595589984243300

Summary is that if we do that, it loses all the composability benefits of data as assets.

[trentmc]

Rather, the 99% case should be that each data asset has its own token. The remaining 1% is when you want to link a new data asset to an existing datatoken. But that should be rare.

[kremalicious]

As a publisher I want to receive 10 OCEAN when someone downloads my data set.

To me this is the 99%, most of our existing marketplace building customers expect that. How would this user story be supported by data tokens? That's why we introduced a simple & advanced mode.

In the same style we need user stories if we want people to use the marketplace we build, we need to get specific and think about this feature from the perspective of us being a marketplace provider. If we implement the balancer stuff and data token for each data set as the only way to price things, we will alienate most of our existing target groups, with something like bleeding-edge yield farmers being left as target group. Fine if we want that but pretty sure we want to encourage e.g. data scientist.

Because for a data owner and publisher we just created a lot more hurdles to publish data, and we made it a paid-for process. Publishing right now with v2 requires:

1. Need a web3 wallet
2. Need to switch to Pacific
3. Need Pacific ETH in that account to cover gas (which we send user automatically)

Now with v3 we introduce all those new hurdles:

1. Need a web3 wallet
2. Need ETH in that account to cover gas, and for providing liquidity
3. Need OCEAN in that account for providing liquidity
4. Need to give away ETH & OCEAN for providing liquidity
5. Need to manually add OCEAN token contract address in that wallet to show up
6. Need to manually add any created data token contract address in that wallet to show up

So the thinking was to provide a simple way where the user only enters OCEAN and we set the defaults in background. Those defaults we currently try to figure out so we're free to do there what we want but ideally we can prevent users from having to move their ETH & OCEAN to publish a data set.

[trentmc]

10 OCEAN... 90% of our users Aka fixed pricing.

Yet those same users, eg dexFreight, are also asking for automatic price discovery.

For a given data asset, you can't have both. It's one or the other.

We should offer both. The user can decide.

[trentmc]

Re:

Publishing right now with v2 requires:

1. Need a web3 wallet
2. Need to switch to Pacific
3. Need Pacific ETH in that account to cover gas (which we send user automatically)

Need to switch to Pacific will lose 90% of users, as we have heard from many. (It's also my personal experience too.)

You need to also account for the flows for people to consume, and opportunities in between.

For people to consume: they need to get OCEAN, bridge it to Pacific, get Pacific ETH, and then they hold the access in a non-standard, non-transferable, non-composable way.

Opportunities in between for v2: none because it follows no standards and is not on Eth mainnet.

Now with v3 we introduce these new hurdles:

1. Need a web3 wallet

Yes. And that's ok for our target users. There are 250K people doing defi now. They all have web3 wallets. I find that the ux of using a web3 wallet to be better than logging in; I'm finding myself idling DEXes a lot and getting annoyed when I have to log into a CEX just to trade.

2. Need ETH in that account to cover gas

Someone needs to provide ETH. I think we should cover it ourselves, and as this ticket proposes. Network. We did this in ascribe days. The best way is to use Gas Station. A recent example: Argent was paying gas fees for all its Aave users.

2. Need OCEAN in that account for providing liquidity

If it's for auto-determined price: yes! And this is a good thing because it establishes an actual market price for the data, rather than hoping that someone will buy data for the fixed price that you set. And of course all the other benefits of using an AMM: auto price discovery, opportunity for others to add liquidity (curation, and an incentive to refer), etc.

Of course if we have a way to offer fixed price as well, where it's non custodial (ie where opf doesn't hold the keys) we should. And that's what this ticket covers, great :) in this case there is no requirement for liquidity, which means the price that's set is "hope that someone buys" (an ask price) rather than actual market price (spot price).

3. Need to give away ETH & OCEAN for providing liquidity

No, we don't. We can have a data liquidity mining program to help catalyze usage. That can be very useful and it's only possible if you have AMMs. I'm short, we don't need it, but AMMs give us the optionality to do so if we choose.

4. Need to manually add OCEAN token contract address in that wallet to show up

Right now, yes. But this is not a showstopper. Even trendy defi tokens like BAL and YFI don't have it, and it hasn't stopped users from adding hundreds of millions in liquidity. But, we can make this easy by working with wallet providers to add OCEAN. And we should -- after migration.

5. Need to manually add any created data token contract address in that wallet to show up

And this is ok too! I'm fact it's a great problem to have, because now you can actually see your data assets in your crypto wallet, which was impossible in v2. Data as assets, that's the goal.

In the meantime, it's OK to have to enter it custom, it never held BAL and YFI like mentioned above. Over time there will be wallets that get tuned for datatokens, eg wallet provider Pillar wants to do this.

The ux hurdles we can solve. And we need to do it in a way that unlocks the benefits of v3 datatokens, rather than wistfully looking at v2 which had none of those.

[trentmc]

if we implement the balancer stuff and data token for each data set as the only way to price things

These are not coupled. You can have a datatoken for an asset without making the user have a Balancer AMM. Like mentioned earlier: the 99% default needs to be one datatoken per data asset, and the user can have the option of fixed price or auto price.

If we go away from one datatoken per asset, we are breaking most of the benefits of v3. That's why we can not do one datatoken per marketplace or per provider.

[kremalicious]

Built out what we have floating around so far as concepts:

Play around with it here: https://market-git-feature-price.oceanprotocol.vercel.app/publish

Now, Trent's mockup implies:

• adding liquidity is separated from publishing, meaning minting data token/transferring data token/adding liquidity needs to happen independent of asset creation. Not sure we can do that right now
• this separation also implies that users could create a data token, add liquidity, but the asset creation could still fail. What then? That's why we should do all that in one process after form submission
• I do not get the formula between price, weight, liquidity. E.g. "If user lowers price, weight auto-rises": how am I supposed to know what the thresholds are?

[mihaisc]

So basically you have:

• ocean tokens
• data tokens
• cost

And the relationship is: ocean tokens / data tokens = cost data tokens = 9 * ocean tokens ( basically fixed 90% weight)

I think i didn't understand this right, if the weight is fixed then ocean tokens / data tokens will always be the same.

[kremalicious]

We sill have to come up with a compelling argument for a publisher why they have to pay to publish. What is the advantage over using fixed pricing?

[kremalicious]

So basically in code:

const weight = '90' // in %
const tokensToMint = Number(ocean) * (Number(weight) / 100)
const cost = Number(ocean) / Number(tokensToMint)

with something like that:

[kremalicious]

Actual background flow which needs to happen:

1. you need to set a price for DT (how many OCEAN do you need to buy a DT)
2. then you need calculate the pool liquidity you are going to add, so the amount of DT and OCEAN divided will be that price)
3. then using weight, you are going to lower the amount of OCEAN needed
4. create the pool, set the weights and add liquidity: dtAmount and loweredOceanAmount
5. you are going to publish a dataset with dtCost = 1 (in the DDO)

[trentmc]

We sill have to come up with a compelling argument for a publisher why they have to pay to publish. What is the advantage over using fixed pricing?

People ask us all the time how to go about pricing their data. So, auto price discovery that you can bootstrap from tiny liquidity is a bit of a holy grail, we're fortunate that AMMs came along and made it easy for us.

But some users will want fixed price. This is why we offer both options.

[kremalicious]

next iteration, think this makes more sense, following common pool creation UIs.

The calculation:

const cost = '1'
const weightOnDataToken = 90 // in %

const ocean = USER_INPUT
const tokensToMint = ocean * (weightOnDataToken / 10)

The UI:

[trentmc]

I like the evolution of this! Nice work. I'm happy to see the two options for price setting. (Sets us up nicely for more options:)

Seeing this, I realize that my prototype didn't emphasize enough the possibility for weight to be higher than 10% (rather than fixed at 10%). The reason is to give the opportunity for higher liquidity, therefore lower slippage, therefore better customer experience. I thought more about it; we should emphasize slippage more. So, here I explain: background, and a suggested better way. I envision that the current UI widget can be updated to account for it.

Background. The amount of price slippage is a function of liquidity. E.g. Uniswap and Balancer GUIs show you the % slippage when you purchase. If there's lots of liquidity, then slippage can be <1% or even <0.1%. But if there's only a bit of liquidity, then slippage will be 5% or 10%. Uniswap GUI will warn you at >5% slippage and won't even let you purchase if >10% slippage. I've been playing with them even more, and found that I really care about slippage (because I don't want to overpay just because of low liquidity).

The datatoken seller will want slippage to be sane, so that buyers have a better experience. The way they do that is put in enough OCEAN liquidity. Max slippage should be 5%, but they may want a better experience for their buyers by adding even more liquidity for lower slippage.

Proposal.

• Datatoken seller can change liquidity and price (of 1.0 datatokens).
• It calculates and displays slippage (e.g. "3.2% for 1.0 datatokens") and weight (e.g. "21.3%"), as a function of liquidity and price.
• Slippage has a constraint of <=5%. Weight has a constraint of >= 10%.
• There are GUI affordances when slippage and weight constraints are not met. E.g. the text is red, and it won't let the user finalize the price.
• Ideally, the user can play with the numbers before committing on blockchain.
• Later on, the datatoken seller can add or remove liquidity. And anyone else too of course. (This does curation, and implicitly referrals.)

It's possible that I missed something, therefore if you see issues please note them:)

[kremalicious]

Good points, on Uniswap the slippage is indeed emphasized and personally I often use this to decide on a swap.

Just not sure we want to have slippage adjustments in first release, and during publish process. The golden path right now is based on that fixed weight. As for UI context, in my current thinking I'm trying to separate the pool interaction into 2 things:

1. Do the bare minimum in price widget to publish the asset, with multiple-step feedback/validation:
   1. inline feedback in price widget, checking balance and more
   2. Some representation of pool creation/assets provided in the right-side asset preview
   3. Submit button of whole form is disabled if price widget doesn't pass our defined validation
2. Interact with the created pool after asset creation
   • on the asset details page in the Trade (working title) tab on right side

So all this liquidity/slippage adjustments could happen in that Trade thingy after the asset has been published/data token created/pool created. But if we can we should show the projected slippage based on the amount of OCEAN put in somehow

[trentmc]

I like the idea of a "golden path" to quickly get through the publish process. OK.

If we're going to have a fixed weight, rather than 10% we should seriously consider to fix it based on the constraint of "<5% slippage when buying 1.0 datatokens". Here's how to calculate slippage: https://medium.com/balancer-protocol/calculating-value-impermanent-loss-and-slippage-for-balancer-pools-4371a21f1a86

There's another variable at play here: the # datatokens that the data provider makes available. But maybe that number falls out if initial weight = 10% and slippage = 5%.

[kremalicious]

then again for UI, tables are kinda boring and we can get all the same values in this more visual layout:

[mihaisc]

In simple when you click on the up arrow the focus goes to down arrow, so if you click multiple times the value will actually decrease. Does not happen in advanced. This is on edge (chromium) and chrome , both windows.

[kremalicious]

yeah, super weird and only happening in Chrome. The cause seems to be that the conversion component takes focus away from input, in all browsers, which is unintended.

[kremalicious]

ok, that weird input defocus bug was caused by the Tab component, unintended re-render, fixed in c1b3444ae12ea340ddd4f40f02dc286a41a5b1d0

[kremalicious]

For now, I refactored the whole thing so that Simple & Advanced use the same logic to collect data. Not so sure yet if tokensToMint will actually stay the same between both variants: https://github.com/oceanprotocol/market/blob/feature/price/src/components/molecules/FormFields/Price/index.tsx#L12

For debugging, the collected data is also thrown on screen:

[mihaisc]

I'm not sure about the simple logic. Because it's not the same relationship between ocean and dt, right? @alexcos20 ?

[kremalicious]

current UI state, advanced getting more advanced:

[mihaisc]

I think there shouldn't be a conversion to euro for the ocean-cav ( data token) . And we don't show the actual estimated price anywhere , or am i missing something?

[kremalicious]

good progress on the pool stuff:

ideas for more info display: -% slippage there is in price to buy 1 DT -Price of DT in denominated in EUR and USD too -total value of assets in pool, denominated in OCEAN, EUR, USD

[mihaisc]

we can have a select control somewhere on the page where you can select euro or usd.

[kremalicious]

sure, makes sense, implies 3 things:

1. global store for user preferences, connected to localStorage
2. User preferences UI somewhere, with currency as first option
3. Modify price conversion fetches to include more currencies, and pick the one based on user preference

edit: moved to https://github.com/oceanprotocol/market/issues/59

[trentmc]

Small thing: default liquidity provider fee should be 0.1%, not 0.3%.

[kremalicious]

@trentmc where do you see 0.3% on https://market-six.now.sh/?

[trentmc]

The image in an earlier prototype has it. But I see now that comment was 14 days ago. Therefore way out of date. Ignore:)

[kremalicious]

current snapshot:

[kremalicious]

Final price input during publishing with all fees: