FixedExchangeRate creates an unnecessary token

[TimDaub]

At RPI, we're trying to publish our API on the Ocean Marketplace.

In the past, we asked ourselves if e.g. we could publish an asset with a token and a price discovery pool but our lawyers in Germany came back and told us that this would involve incorporating in a token-friendly jurisdiction and lots of other jazz. Since the gain of using dynamic price discovery seemed negligible given the number of API users, we scrapped the whole idea for a while and decide to sit out the problem.

But then this week, we thought that we could maybe just use the FixedExchangeRate asset. Our mental model was that it'd entail deploying a smart contract that simply took OCEANs in exchange for API usage.

But going through the publishing steps now, it's become clear that indeed there too, an actual token is launched:

• https://market.oceanprotocol.com/asset/did:op:eb651bF2FFaE34E859431Eeba8ff6c686A4EcE55
• https://rinkeby.etherscan.io/token/0xeb651bF2FFaE34E859431Eeba8ff6c686A4EcE55

The problem with launching a token is regulatory uncertainty but in this case also the non-necessity. Conceptually, what we need to launch our API without talking to 3 lawyers in 4 countries is a contract that can take OCEAN in and then allows the sender to access a URI on the provider API based on the respective on-chain event. It's fairly simple from a technical perspective I believe.

It'd be important that there are explicitly no tokens used or deployed. E.g if we had deployed a FixedExchangeRate token on the Ethereum mainnet that'd allow transferring, wouldn't it allow anyone to create a dynamically priced pool and hence make us the emitters of a security?

We'd like to ensure that this won't happen, so we find deploying a token for a FixedExchangeRate unnecesary.

[kremalicious]

The access mechanism of Ocean Protocol since v3 is all around data tokens and for every access data tokens need to move around, so the product decision was made to keep that principle consistent no matter the pricing scheme. I agree with you that technically it sounds over-engineered for what fixed price as a mental model does in the end.

In any case moving this to contracts repos as this is where any change regarding this would need to happen which is very unlikely at this point in time going from v3 to v4.

[TimDaub]

Say I was to refactor the FixedPriceExchange such that it only ingests OCEANs, redirects them to the publisher, and emits the respective event for the provider: If I sent a PR, would it get merged? Or are there any internal (e.g. political) reasons that could stop this?

I want to know as I'd like to avoid doing work that is potentially wasted.

IMO, reducing the FixedPriceExchange's complexity to simply ingest and redirect OCEANs can have many benefits:

• Its compliance with security laws tremendously lowers the hurdle for data publishers to click "publish"; more data publishers will click "publish"
• On all peripheral components (e.g. ocean.js) and others, it means less code to get the same thing done; No handling of a virtual data token necessary anymore
• On the Ocean Marketplace UI, I believe having to send a token contract create tx wouldn't be necessary anymore hence reducing one potential step of failure and complexity in the UI
• In the potential V4 smart contract audit, a simpler solution for the FixedPriceExchange would likely do better and cost less money. It'd probably also be safer.
• Overall, IMO this would increase Data Consume Volume significantly.

[trentmc]

The heart of ocean's architecture is erc20 tokens for access control. Having this allows great interoperability. Eg the tokens can live in wallets, DAOs, amm exchanges, centralized exchanges, and more. Everything that defi is building, basically.

This datatoken design decouples pricing from tokens. They were coupled in Ocean v1 and it created a bunch of customers code with no interoperability. You might think it's "simpler" to couple them for fixed price plus consume at once, but it would only be for that one use case in the backend (wouldn't affect FE), and then would require a whole parallel track of code completely divorced from the rest of Ocean code.

In short: erc20 datatokens are here to stay, for reasons of interoperability and simplicity.

[TimDaub]

If e.g. the FixedExchangeRate contract would only mint tokens upon consumption and so nobody could ever hold a data token for a data set in the FixedExchangeRate world: Then I believe this would help us and others tremendously.

E.g. right now if we deploy a FixedExchangeRate token, we'd run into legal issues as e.g. anyone could just buy a bunch of FixedExchangeRate data tokens and e.g. launch a pool on Uniswap. Now, we'd be the issuer of an illegal security. I believe there are many token holders on the OCEAN marketplace that may not even be aware that they're doing something probably illegal currently.

Also for us specifically, we don't need a token now.

I think I'm not specifically talking about decoupling or coupling. All we need is a contract that can ingest OCEAN e.g. 10 OCEAN = 1 consume (fixed rate) and then those 10 OCEANs get split according to the CommunityFee splitter so 0.98 to the publisher, 0.01 to DAO, etc. I think the only difference really would be that instead of data tokens for access, now you can send around OCEANs for access.

I'm open to making that work with ERC20 tokens, as long as it means that nobody has control over the ERC20 data token but the FixedRateExchange for the above-mentioned legal compliance which is our showstopper.

[alexcos20]

hold on, I will have something on this

[alexcos20]

@TimDaub - check the PR above