Discussion: Handling stock splits

Adding a quick summary to kick start the discussion.

How do we handle stock split if it happens today:

- Price protection would very likely take care of any unexpected splits
- Needs to be above the 30% deviation range to be protected.
- So while a 1:2 split will be protected, a 3:4 split or 4:5 split will be unprotected.
- Deviation range can be quickly adjusted with on-chain gov along with it, if needed, however will apply globally - so should be used with ample consideration.
- Community votes on a DFIP for oracle side multiplier.
- Oracle price multiplier will be applied at a particular block such that the price will remain the same. The tokens will retain the exact price as before the split. Later, one of the future approaches will apply to it.

Future approach:

- Split will be initiated via on-chain gov.
- Multiple ways to handle the actual split:
- Tokens as immutable.
- Token price will never split or merge - always hold it's tracked price.
- No. of tokens held by an account will never change.
- This provides easier cross-chain capability.
- But this involves new tokens being created along with each split and be migrated either automatically, or manually.
- The creation and deletion can constantly get a bit crazy, though easier if automated and can be seamless.
- Tokens will need to be renamed. And pre-split and post-split tokens will continue to exist in the system forever, regardless of auto migration or manual. How to deal with them, or if and when these need to disabled, what happens to it's pool - migratory path, timeframes and all of those have to be decided upon - can get tedious for each.
- Tokens as mutable.
- Tokens price can be split or merged and be re-balanced with it's number.
- No. of tokens held by an account will automatically rebalance.
- But the moment the token is taken out of the DeFiChain ecosystem, this price is now lost if there's a split or merge after. This exponentially reduce the reliability of the tokens outside of the ecosystem.
- Everything from pools and DEXs are auto adjust due to the global re-balancing. No further changes.
- Simplest process and everything is just `auto-magical`.
- **Optimal approach**: Tokens as versioned.
- Combines the best of both worlds above.
- More similar to `Tokens as mutable`, but rather than being mutable, it will be versioned, adding a version tag to tokens.
- All internal mechanism will auto re-balance to use the next version of the token.
- But this will not change the tokens in your wallet. This remains untouched. But when such a token is used - v1 of a token can be used with v2 token area in the system. For example, when a v1 token is used in the DEX to swap, it will automatically migrate to v2 and hence utilise the correct price.
- Tokens taken out of the ecosystem will never lose it's price, since when they come back in, it'll reversion itself and be reflected with the new and correct price.