Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(Wizard 2.0) Disable to buy minimal amount(decimals) if decimals>16 #853

Closed
dennis00010011b opened this issue May 6, 2018 · 8 comments
Closed
Assignees
Milestone

Comments

@dennis00010011b
Copy link

Test URL: https://5aec92f21f12b70339c64d4a--architect-coin-64174.netlify.com/

Steps:

  1. Create crowdsale with any valid parameters, decimals =17 or 18.
  2. Open invest page
  3. Try to buy minimal amount: 0.000000000000000001 for decimals =18

Expected result:

  • user should be able to buy any amount from diapason : decimals ... total supply
    Actual result:
  • disabled to buy decimals
  • loader displayed, transaction isn't created

If you are reporting a problem with Token Wizard, please include the following information:

Which network did you use? (Mainnet, Kovan, Rinkeby, etc.)

Ropsten

If you were able to create it, what is the URL of your crowdsale?

*https://5aec92f21f12b70339c64d4a--architect-coin-64174.netlify.com/invest?exec-id=0x45cd5779ef7840269cf3fc9e2490ea72ff119027401f8ac0a61c932cd1b64c5f&networkID=3
*

Do you have screenshots showing the problem?

screen shot 2018-05-06 at 11 03 38

Do you see errors in the dev console? If yes, please include a screenshot

To open the dev console in Google Chrome, press F12, or go to View -> Developer -> Developer Tools, and open the Console tab

If you see errors, please right click on them and "Save as..". Zip saved file and attach it to the Issue.

Your answer


@vbaranov
Copy link
Collaborator

vbaranov commented May 7, 2018

@dennis00010011b
I will try to explain, why this issue exists. Let's take rate = 1000 and decimals = 18, for example.
rate - is the number of tokens per 1 eth. And you want to buy 1e-18 tokens. 1 token costs 1e15 wei. Thus, 1e-18 tokens should cost 0.001 wei. What is impossible, because wei is not divisible. Basically, rate / 10**decimals - it is the minimum amount of tokens, that every user can buy. It is like natural global min cap. I think we should calculate natural global min cap in step 3 and set it in global min cap field with adding validation.

@fernandomg fernandomg self-assigned this May 7, 2018
@vbaranov
Copy link
Collaborator

vbaranov commented May 8, 2018

@dennis00010011b @fernandomg
I rethought. The final formula should be:

X_G = max(RATE * 1e-18; 1e-${decimals})

where
X_G - "natural" global min cap in tokens
RATE - amount of tokens per 1 ETH
decimals - how token is divisible

It is simple to check, that X_G = RATE * 1e-18 will not work in boundary case, when decimals = 0, for example.

Please let me know, if I'm wrong.

@fernandomg
Copy link
Contributor

As I understand minCap will be the minimum value allowed for the first tx, which won't solve the whole problem.

In the other hand, if we think about rate as a value dependent on decimals, we can validate rate in step 3, preventing inconsistent outcomes.

For instance, if the user sets decimals to 0, then max allowed rate will be 1e18; if sets decimals to 3, then max allowed rate will be 1e15; and so on, then: max_rate = 1e(18-decimals).

I'm thinking about it from this perspective, due to the steps in the wizard. User will set first the amount of decimals for the token, based on that, I thought about inform the user the max rate that he/she will be able to set, depending on the amount of decimals.

max_rate

@vbaranov
Copy link
Collaborator

vbaranov commented May 8, 2018

As I understand minCap will be the minimum value allowed for the first tx, which won't solve the whole problem.

right

For instance, if the user sets decimals to 0, then max allowed rate will be 1e18; if sets decimals to 3, then max allowed rate will be 1e15; and so on, then: max_rate = 1e(18-decimals).

I'm thinking about it from this perspective, due to the steps in the wizard. User will set first the amount of decimals for the token, based on that, I thought about inform the user the max rate that he/she will be able to set, depending on the amount of decimals.

but I am not sure, validating of a rate in such manner it is a good idea. Why, for example, if token decimals = 18, the rate should be <= 1? we can see from https://etherscan.io/tokens, that overwhelming number of tokens has 18 decimals with different rates > 1. I rather think that token decimals and rate could be arbitrary, but we need to warn contributors and crowdsale owner what will be the minimal amount to contribute. Maybe,

For owner:
we could display warning when he/she will choose rate, what will be the minimal amount of tokens to contribute at any tier in this case.

For contributors:
we could display individual minimum amount to contribute at invest page, just below the input or below the text "Think twice before contributing to Crowdsales Tokens will be deposited on a wallet you used to buy tokens."? And this minimum amount will include "natural" limit + global min cap or individual min cap from whitelist if any.

@fernandomg @fvictorio @pablofullana @dennis00010011b what do you think?

@fvictorio
Copy link
Contributor

So, this is my understanding:

If you create a crowdsale with both a big rate and a lot of decimals, then a contributor won't be able to buy any theoretically allowed amount of tokens. More precisely, not all multiples of 10^(-decimals) will be allowed. This happens because weis are not divisible, so for many theoretically allowed amounts, you have to round the (non-whole) number of weis that correspond to that amount of tokens.

In other words, the worst case scenario is that a user "loses" 1 wei.

Is this really important? I honestly don't think is even worth a warning. Maybe some small print below the contribute input, even smaller than the "Think twice before...".

If this is important for some reason, then we should check that the number of tokens that the user typed can be bought by a whole number of weis. If not, we would show some kind of message saying how many tokens will actually be bought. This message would look like "You want to buy 0.000000000000000001, but the closest allowed value you can buy is 0.000000000000000003".

But then again, I doubt users will care.

@vbaranov
Copy link
Collaborator

In other words, the worst case scenario is that a user "loses" 1 wei.

Users lose nothing. We convert to an integer before sending transaction. I would say, the issue is not with the non-integer amount of wei but with the fact, that buy transaction will be failed, when user will try to buy less then min cap ("natural", global or individual). I look on displaying of the minimal amount to buy, like a helpful feature. It is clear and fair for a user.

@fvictorio
Copy link
Contributor

Users lose nothing. We convert to an integer before sending transaction.

Yes, sorry. What I meant was that if we round up to the next wei, the user will be spending (at most) 1 wei more than they intended. But I said that because I thought we were doing that rounding up, which will avoid the issue with the min buy, but I take from your answer that we are not? In that case, doing that rounding is a possible solution, but a message indicating the minimum amount that can be bought sounds fine too.

@vbaranov
Copy link
Collaborator

I thought we were doing that rounding up, which will avoid the issue with the min buy, but I take from your answer that we are not?

Yeah, we are doing that rounding up, but for some specific parameters (of crowdsale and token) 1 wei which user will be trying to pay will not be enough due to min cap ("natural", global or individual) and a transaction will be failed like from Dennis's experience from this issue. Also, I agree that this is a rare boundary case. My suggestion here is just to give a user maximum info on the page in order to avoid misunderstandings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants