verifyfirst
commented
2 years ago Full Support
Closed SamusElderg closed 2 years ago
verifyfirst
commented
2 years ago Full Support
ashuranjananand
commented
2 years ago Can't be more excited.
SamusElderg
commented
2 years ago UTILS updated: 5c079a33ed87ff5f7286d2a034a78db62660c9ab
The feeBurn came about with SPARTAv2 to combat the one time unplanned inflation via the fallenSpartans contract which was created to help make the V1 Spartans partial again
It has done an amazing job of making up for that, and will no doubt play in important deflationary role in the future too but most likely in a different form that is not on the transfer() level. For our current phase however, it might make sense to disable the transfer feeBurn and look to do a more aggressive method of burning each month instead that's not pegged to economic activity as such. It will be less fancy and programmatic, but more effective and friendly for users and partners.
750K+ SPARTA has been burned via feeBurn which is great to see from such a small % burn mechanism, but if we turn it off now and switch to burning from the supply/minted SPARTA instead, we can potentially shave off up to 50M SPARTA from the max supply over the coming months (this is high time preference, the earlier we do it the bigger the burns can be) and in the process, not only speed up our deflation in advance, but also bring the protocol further along the emissions curve thereby reducing daily SPARTA emissions (less inflationary + more deflationary in batches)
This will only work if the SPARTA is sent to a dead/burn address instead of address(0) thereby removing them from the 'circulating' supply permanently and having a major permanent impact on the max supply.
If the internal burn() function was used instead (like the current feeBurn) then: • circulating supply reduces (deflationary) • max supply stays the same (neutral) • emissions curve steps back and emissions increase very slightly (neutral -> inflationary)
Compare that to this proposed method of burning large amounts out of the supply into a dead address: • circulating supply stays equal (neutral) • max supply permanently reduces (deflationary) • emissions curve takes a permanent step forward reducing daily emissions (deflationary)
Advantages: • Reduces the max supply massively (up to probably 50M can be done by estimates) • Makes it impossible for there to be too many Bond allocations (Bond allocations are only possible up to 150M total supply and this proposal will increase total supply whilst not increasing circulating supply and reducing the theoretical max supply) • SPARTA becomes a less complex and more friendly token for partnerships with all projects. There is no question that the feeBurn is a complex thing for projects to have to integrate into their business models from time, complexity, calculation, gas and pocket-expense perspectives • Reduces the cost of users performing transfers of SPARTA between wallets • Improves the output rate of all transactions involving SPARTA including swaps/synths/liquidity (more efficient swaps, more likely to gain aggregator volume) • Reduces the gas costs of all transactions involving SPARTA transfers (again, all of the transactions in the SPARTA ecosystem or interfacing with the SPARTA contracts) • Community DApp will make less RPC calls because it doesn't need to check the current feeBurn rate • Community DApp's estimates will be more accurate especially during a period where the user performs a txn just before the end of an era and it goes thru after the new era starts (feeBurn % changes between what user saw and received)
Disadvantages that I can think of: • Have already done up articles and documentation on the feeBurn which will need to be rounded up and have a disclaimer added to the top to explain the changes (minor issue, protocols should be expected to pivot and for functions to change and we have the capacity to do this in the space of one day as a community) • The community DApp integrates feeBurn calculations for every single step of every estimate, will need to be adjusted (this is also an advantage in that the DApp codebase can be made more efficient) • Community DApp tokenomics drop-down will need to be updated to account for some sort of a 'dead/burn' address that's chosen to track SPARTA balance to remove from the circulating supply (and theoretical max supply?) • In terms of raw tokenomics, a disadvantage here is that we will no longer have a deflationary aspect pulling against the daily emissions forever (this was expected to reach maybe a point between 150M - 250M within roughly the next 10 years or so where inflation would be fairly neutral each day with the burn eating up the emissions each day) BUT I would also propose that emissions simply be turned off at some point in the coming years and effectively do the same thing at a much-much earlier point with a much-much lower circulating supply (DAO can do this via proposal). Also keep in mind a more friendly deflationary aspect can always be added in later on down the track to become 100% deflationary combined with turned off emissions, I challenge all Spartans to begin thinking about this now so we have a cool idea to implement in the future
As you can see above, from angles I have gathered from contributors, can't really see any clear disadvantages from an economic perspective, it all seems to be a NET positive, and discussions between community members have all been very supportive of this so far
The mooners will also enjoy the fact that this is 100000x more marketable in that we could easily be burning 5M SPARTA every month instead of less than 1M SPARTA every 6 months which is quite powerful in many ways 👍
I propose these steps, most of which I am happy to coordinate with the community contributors and we could easily action within a week of settling:
I now open up the comments below for the Spartan community to do what we have always done best; help shape this thing!