Two random creator token observations of note for design team

[bedeho]

1. We probably should from the get-go focus on a design for creator tokens where we distinguish creator token unit, captured by the ticker symbol, from the basic currency unit, analogous to satoshis, or Wei in Ethereum. So say there is some creator Bob, who launches $BOB token, he will specify that the initial supply is 1 million $BOB, which he will hold, and people can send around 3,632 $BOB for example, but under the hood this is represented as a whole number of currency units. The main impact this has for the design is whether we allow a token issuer to control how many decimal places their token has? this is equivalent to asking, how many base units you need to make one $BOB token. If yes, this must be incorporated in issuance step. If no, then should all tokens have the same number of decimals, how many would that be? My opinion is that going for a non-decimal representation, that is dealing with just whole base units like we are doing for $JOY, is a pain, because you need to have a sh*t ton of zeros that people have to count all the time, like 1230000000 (how many 0s), which come from the fact that you really want a large number of base units in order to have very high resolution value representation. So if we have decimals representation in UI, then we probably will be better off giving creator more control, as they will know more about what makes sense for their token.
2. Be aware of the following nuance of vesting schedules: the same account/member can have multiple simultaneous vesting schedules which are simultaneously encumbering distinct pools of funds. The way this can happen is for example if a purchaser participates in multiple sales that happen one after the other in time, sufficiently close that the vesting schedule of the first overlaps with the second. I would say that this is unlikely, but it is possible.

[KubaMikolajczyk]

1. I have to admit that I'm not a tokenomics expert so if I would have to find the perfect base unit for the token I wouldn't probably know where to start. I remember when we talked last time we were discussing the possibility of handling this for the user on the system side and not asking for input. But I agree that there should be some decimal representation of the token, reading those long numbers is not great at all. I wonder if someone can jump on this from the technical side because choosing the default amount of decimals feels really technical for me 😅
2. The same member can have different channels, therefore different coins and different vesting schedules probably happening in the same time, and those can overlap? How does that work exactly?. I don't think I understand that correctly :c

[bedeho]

The same member can have different channels, therefore different coins and different vesting schedules probably happening in the same time, and those can overlap? How does that work exactly?. I don't think I understand that correctly

No I am saying the same account on the same token even, not across tokens, that would obviously be possible also.

I will try to prepare something that explains

1. multiple vesting schedules
2. transferable balance
3. locked coins for revenue split

in one go.

[kdembler]

Maybe we could just use the same number of decimal places as we end up using for the $JOY token to make it simpler? Is there some significant value in letting users pick the number of zeroes?

[bedeho]

Is there some significant value in letting users pick the number of zeroes?

In theory, yes I think so, because if we assume base supply has fixed dynamics/values, but different $CRT has widely different market cap in some numeraire, say $USD, that the issuer will have some decent handle on at the point of issuance, then they have the best chance to pick the number of decimal places that minimzes the number of zeros people need to deal with when specifying/reading amounts.

However, it also seems practical experience strongly goes the other direction

• Proposed ERC20 change: make 18 decimal places compulsory ethereum/EIPs#724
• https://forum.openzeppelin.com/t/change-decimals-for-erc20/7363

So I suggest we just go with 18 hard coded.