Replies: 2 comments 5 replies
-
|
Even if they fork it, I think those wouldn't be considered NAs as they're not "whitelisted" (or coming from the official NA factory, depending on the chosen architecture). |
Beta Was this translation helpful? Give feedback.
-
|
The VM-level NT precompiles won't have any knowledge of decimals. They will store Therefore, forked assets with different numbers of decimals would still be proper NTs, just not part of the standard (I am working on a standards repository called SFRs as we speak). Are you in favor of restricting to 18 decimals, or not? |
Beta Was this translation helpful? Give feedback.
-
|
bump @razgraf |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, looks like I missed this. Yes, in favor of restricting to 18 decimals. |
Beta Was this translation helpful? Give feedback.
-
|
Great, thanks. |
Beta Was this translation helpful? Give feedback.
-
|
I will assume that you @IaroslavMazur agree with this proposal. If not, feel free to reopen and debate. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I agree. It's a good idea to not complicate things more than is vitally-needed, especially, until the whole concept is proven 🙌 |
Beta Was this translation helpful? Give feedback.
-
I've opened a discussion about this on Twitter, and the community appears to agree that it would have been better had the ERC-20 standard enforced 18 decimals.
Should we enforce 18 decimals for our NAs?
Note: enforcing means hard-coding the value to 18 decimals in the NA standard/ template we will provide. It's perfectly possible for people to fork that and change the 18 decimals, but then, they wouldn't follow our community standard anymore.
CC @sablier-labs/sabvm
Beta Was this translation helpful? Give feedback.
All reactions