set minimum price to 0.01

[kremalicious]

• Testing implications of lower minimum OCEAN price
• custom cap (to be defined)

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/oceanprotocol/market/55CDSAw3PoxBRWPtCtfQ8NzsPL5v
✅ Preview: https://market-git-feature-micro-cap-oceanprotocol.vercel.app

[realdatawhale]

Hey @kremalicious , though I'll just shoot you a comment here. Thanks for the Rinkeby tokens.

I've tried to create the pricing on the pool, however it looks that I'm unable to mint the amount of Data Tokens that I'm looking for. I'll provide upwards of $OCEAN 5000+ initial liquidity at an IDO price of 0.02 - 0.05. So the amount of Data Tokens available will be between 50K - 120K. Is it possible to change this, so I'm able to mint that much?
I think the total supply is currently capped at 1000.

Let me know if you can help us for this.

[kremalicious]

Change in this PR would be totally fine so far.

But the datatoken cap indeed is hardcoded right now, or more precisely the market does not capture or pass it, making ocean.js fall back to 1000. The tricky part here is that the cap would need to be set right in the publish form and not during price creation as creating the metadata also mints the initial data tokens. And it's hard to make majority of users understand this when they just create metadata and don't think about pricing yet. Which is why we were holding off on just adding it as a new field in the UI in publish form. The ideal solution here would be to split up metadata publishing & datatoken creation, which we already have in mind but no ETA. On the other hand in v4 this all seems to be not an issue anymore.

Some options I can think of to make your use case possible in a timely way where we can pick one:

1. Hardcoded custom cap which we pass to ocean.js during publish. So add to this PR, and you would use its preview link for publishing your assets. Quickest solution for everybody but you would have to live with the same cap on every asset.
2. Expose cap as a new optional input field in publish form for everybody. This might get feasible already to be put behind a new collapse-by-default Advanced Settings area in publish form introduced in Add custom provider to publish form #707. So this is not as quick as 1 as we need to finalize the other PR first and then look into more UI & copy work for the cap input field.
3. Wait for v4, but most likely not an option for you.

[realdatawhale]

Hi @kremalicious ,

thanks a lot for presenting all the options. I’m inclined towards Option 1, as it seems to be the most timely solution. Also I feel Option 2 will be obsolete when v4 launches and since the micro-cap IDO is a trial & error, I don’t want to create too much work for your team.

Before going ahead, could you please help to clarify the below for my understanding?

• will the hardcoded custom cap be linked to my publishing address? Say, I settle on a supply of 250K for this IDO, then for any future IDOs, this would be my personal maximum supply cap correct?

thanks again for helping and supporting 🙏

[kremalicious]

will the hardcoded custom cap be linked to my publishing address

well it just depends on the code change in this PR. I just hardcoded here to 250000 https://github.com/oceanprotocol/market/pull/742/files#diff-bba8d9ed1230a954af8de00f6f6031d48f460a2a6e296609655f1a163a218f25R42

So if you now use the preview of this PR everything you publish through it will have this cap. Until we change it in here again. You can see this in the debug output under publish form too:

[kremalicious]

Well you have to publish a new asset, only that will have the cap hardcoded in here. The cap is set during the datatoken creation which is happening before the price creation. So you can't set it during price creation because the datatoken is already minted. Price creation is creating the pool (or fixed rate exchange), not the datatoken itself.

So nothing in the DDO regarding the cap there will be affected by anything you do on that existing asset https://market-git-feature-micro-cap-oceanprotocol.vercel.app/asset/did:op:81DC6629b05F43D522049382a013EB7E2772cC99

Seeing this asset makes me think you might have a flow to publish programmatically already setup (as name & symbol is custom) so would suggest to just continue in that flow and just additionally pass the cap yourself when calling ocean.assets.create()?

[realdatawhale]

Just created the price & supply of 100'000 Data Tokens! Exciting!

@kremalicious , please advise how do we go about the custom ticker ?

https://market-git-feature-micro-cap-oceanprotocol.vercel.app/asset/did:op:7FBEDfF92F39ae900393B17370E192D508458FDB

[kremalicious]

please advise how do we go about the custom ticker

to allow this in the UI would be a bit more complex to setup, hardcoding could work but also needs quick investigation as we auto-generate a new one on initial render of form. But we are not going to update it for you for every planned IDO anyway. As I said, ideally you would create the initial asset programmatically which you seem to have done in the past already and would give you all the flexibility you need as the cap is part of the DatatokenOptions just like name & symbol. Once it's published you can then just pick it up and continue in the UI normally to create the price for which the first change in this PR would still be useful. To make things simple and quick we could hardcore the data token symbol for first IDO but then would suggest to get some basic coding support for the next ones

[realdatawhale]

Hi @kremalicious , appreciate the offer to hardcode it for this one. Once it's done, will I have to create it via the link or will it show up immediately? If this is the case, let's wait until I'm fully ready with the dataset in about 15 days or so.

Thanks

[qlty-cloud-legacy]

Code Climate has analyzed commit cb0a988 and detected 2 issues on this pull request.

Here's the issue category breakdown:

Category	Count
Duplication	2

View more on Code Climate.

[kremalicious]

Revisit after v4