Update supply related attributes

[ya7on]

In #14 it was suggested to get rid of max_supply field since it's implicit. It's more explicit and more optimized for gas consumption to use a boolean mintable, which takes 1 bit instead of 256 for coins type (uint256)

• Add new mintable attribute with boolean type
• Update max_supply attribute. Make it optional
• Handle updating of both attributes in JettonSetParameter

Considering the following limits:

• a mintable attribute that can permanently disable the minting
• minting process is stopped when max_supply is reached (if its not set to null for unlimited), it could be increased via JettonSetParameter
• do not allow the max_supply to be set to null (unlimited) outside the init process (JettonInit message)

[iamIcarus]

Proposal: Updates to max_supply Logic

I believe the max_supply variable is still essential for the following logic:

nativeThrowIf(ERROR_MAX_SUPPLY_EXCEEDED, (self.current_supply + msg.amount) > self.max_supply);

Proposed Updates to the Logic

1. Ensure max_supply is greater than 0
2. Any new value for max_supply must always be greater than the current max_supply (If changing max_supply should be a feature )
3. Add a mintable flag to disable minting entirely, regardless of the max_supply.
4. When setting mintable flag to false should be final. (In this case max_supply value can be set from current_supply)

[ya7on]

If we keep max_supply, should we make it optional? For situations when total supply is have to be unlimited. In that case minting will check supply only if max_supply is present, if it's not minting will be unlimited.

receive(msg: JettonMint){
    ...
    if (self.max_supply != null) {
        nativeThrowIf(ERROR_MAX_SUPPLY_EXCEEDED, (self.current_supply + msg.amount) > self.max_supply!!);
    }
    ...
}

If changing max_supply should be a feature

There are couple of questions, if we make this feature:

1. On the topic of what I wrote above. If we make max_supply optional, could user set from defined supply limit to null. Thus removing the restrictions to supply. Or vise versa from null to defined?
2. Should it be allowed to set max_supply as "final" value without possibility to change it anymore?

[iamIcarus]

Good questions,

If we think jettons as tokens associated with the typical token value, i believe the minting process should be restricted, transparent, and simple. But for jettons that are used for exchange of computational services, with no implied intrinsic value, then fully controlling the minting makes total sense and should be the option to go.

So for a jetton with implied intrinsic value, i would personally set some minting limits such as

1. a mintable attribute that can permanently disable the minting (regardless of max_supply)
2. minting process is stopped when max_supply is reached (if its not set to null for unlimited), with the option to increase it (maybe through a DAO decision)
3. do not allow the max_supply to be set to null (unlimited) outside the init process. Although theoretically we can keep increasing the max_supply or be set to a really big number.

Implementing all options is possible, but not gas effective and increases complexity

What are your thoughts on this? How would this jetton fits in your vision?

[ya7on]

I like limits you suggested!
Initially, when I started writing this jetton, I tried to do so it could be used as DAO governance token and could be configured by community.
In that conception more attributes that can be controlled seems like a good solution.

gas effective

I was thinking about it. I'm not 100% sure how memory management works in Tact, but in theory if max_supply will be optional parameter, setting it to null save gas because it will be stored only as 1 bit. So if someone wanted to not use this parameter and save gas, it sets max_supply to null.

increases complexity

Yes it could be an issue. Probably we should described this logic in documentation.

[iamIcarus]

I was thinking of using a single token as a governance and as intrinsic value. For example holders who have more than x amount can vote or holders who have the token locked for 6 months can vote (or both)

How do you see that with TON and Tact. I have more exp in ETH

Edit: Not sure if a single token to handle Gov and Rewards could be the best case for TON and how the chain is setup. I'll review the best approach on this case

[ya7on]

I wondered about DAO and governance tokens in TON, but I couldn't find any project that would implement this using smart contracts, not regular backend.

I tried to design on-chain voting based on smart contracts in Tact in that repo. I have not done yet.
And I have couldn't find of a way how to vote with jettons without locking tokens for while (for voting period). There is always double spending otherwise.

I am not very experienced in web3 development. I work as backend web developer and develop smart contracts for TON as hobby. So i may not have base knowledge. Why is there will be an issue with using single token for voting and for other purposes?

[iamIcarus]

I've noticed your DAO repo, i didn't have the chance to play with it yet, but since i'm wondering with DAO as well i'll probably contribute to your DAO repo at some point.

On top of my head, if a single jetton and or the minter contract gets too big with functionality and state variables, the rent will increase as well. So maybe we don't want to introduce this functionality to the jetton token and pay higher rent if the user will use the voting right only 2-3 times a year.

Maybe its best to have a minter of government jettons when the vote takes place (at voting action), based on the user voting power, if that makes sense.

I'm still exploring and researching ideas and TON in general so this might not be the best approach, apologies if its not.

[iamIcarus]

Hi @ya7on share your thoughts when you finilise how you like this jetton to take place. I'm actively working on TON contracts with Tact ( jetton, rewards-distributor , and a DAO ) so i will revisit this repo and contribute more at some point, but i wouldn't want to contribute logic that is not aligned with your vision 😄

[ya7on]

Hello, @iamIcarus. I am very grateful for your interest. I apologize for not making these things clear. I will be opening issues in repos and try to describe my vision of project there. Would this be ok for you?

[iamIcarus]

yes, i can contribute to some of the ideas that alight to what you have in mind. This repo is well written and makes it fun to work with 😄

[ya7on]

Thank you! I really appreciate you like it!

[iamIcarus]

@ya7on , i'll pick the mintable change some time today or tomorrow so we can close this ticket

[ya7on]

Great. Thank you so much!