I am mainly thinking of how future breakaway communities will be presented to the world and be made tradable. Simplicity is always preferable and if we don't have pure 'SMTs' on L1 Hive - the simplest option - then it would be nice to avoid having more than one structure and format for L2 tokens on Hive. However, I appreciate that this may be unavoidable.
I guess that as long as there is a way for external services, such as coin tracker apps and exchanges, to be able to identify the protocol/service being used to run the L2 coin and they code their systems to denote that and treat them accordingly, then there's no real problem other than ensuring end users are aware of exactly what is going on when they use a community's L2 token on Hive.
Yes, nothing stopping that from being developed.
That's great to hear! There is huge potential in this imo. Hive Engine tokens have never really been customisable enough to allow us to test different approaches to their functioning.. Being able to custom create contracts for L2 tokens on Hive could be the solution.
No fees (yet), but VSC will eventually use staked HBD for lite account fee payments in a similar way to Hive RCs.
Also great! Thanks for explaining
I agree. I plan on building a single interface for token-like contracts that inherit the standard VSC Asset spec for tokens. Any other arbitrary logic can be added on the side of that such as custom mint function, supply cap, etc.