New Phase of Burning
With the release of SPARTAV2 (the token) a deflationary feature referred to as ‘feeBurn’ was added to our Protocol, with the intention of automatically helping to offset the perceived inflation caused by the fallenSpartan fund, and to generally work towards making the protocol deflationary in the long run
feeBurn can be considered a success, with almost 850K $SPARTA being burned humbly and automatically via normal token transfer functions. With V2 (the procotol) now up and running, it makes sense from multiple angles to review and re-assess feeBurn during this phase. A proposal was made to disband the feeBurn and instead focus on reducing the theoretical max supply in a more aggressive, permanent manner.
Whilst this proposal has seen strong community support, it is not a decision to be taken lightly, and there have been some solid debates for and against both the change to feeBurn and the methodology. The feeBurn was an extremely important part of V2’s progress — especially during the migration from our V1 and V2 contracts. We were able to maintain a deflationary element without any active pools.
Now that we are fully live and progressing to a phase of Spartan Protocol involving potential partnerships and protocol efficiencies, it is sensible to disable the feeBurn and perform a more aggressive, permanent token burn.
30M+ SPARTA to be burned
Starting shortly, a campaign to burn at least 30M SPARTA from the mintable supply will commence.
- 5M SPARTA will likely be burned in each round, removing them permanently from the ‘mintable supply’
- SPARTA will be burned to a verified ‘dead’ address (0x000000000000000000000000000000000000dead)
- This is the same address that Spartan Protocol used during its initial Proof of Burn distribution, where users could burn existing BEP20 assets in exchange for newly minted SPARTA
Why use a ‘dead’ address?
Typically when tokens are burned out of the supply (like the feeBurn approach) the tokens can be considered as reversing the total supply and making more room for tokens to be minted in the future. Consider this similar to a never-ending tug of war between emissions and burns (in our case with the feeBurn vs emissions).
By instead sending them to a ‘dead’ address, the protocol’s token emissions now move forwards instead of being pulled back. Whilst the adjusted total supply and circulating supply do not go up or down from this, the max amount of SPARTA that can ever enter the circulating supply will decrease permanently.
This means we are effectively:
- Reducing the theoretical ‘max supply’ down from 300M by every $SPARTA burned with this method
- Reducing the daily emissions (moving further along the emissions curve)
- Creating an easy way to audit the verifiably burned SPARTA (SPARTA held in the dead address = all SPARTA burned in this way)
- Speeding along to the internal 150M cut-off for Bond allocations, thereby reducing the max possible Bond allocations down closer to previous expectations
While there was no active decision made by the Spartan Protocol community to continue Bond beyond a maximum of 100M tokens, some questions and concerns have been raised by the community regarding the potential to increase this to 150M tokens. These token burns will also result in a reduction of the theoretical maximum Bondable tokens.
Where are we with this?
The feeBurn has already been disabled on the contract level & the DApp now reflects the feeBurn being
0 in estimates. Partners have all been contacted (CEXs, DEXs etc) in regard to any possible benefits and beneficial changes that can be implemented around the feeBurn being removed.
An API has been spun up to dynamically calculate the adjusted supply figures to make life easier for CMC/CoinGecko, but while this is communicated and integration is in place, we expect some potentially confusing numbers as it takes time for these partners to update their APIs and processes. We will continue to work with our partners to resolve this as soon as possible, and of course — our DApp will always display the correct values by default.
We now look to perform the first 5M SPARTA burn fairly imminently and kick off our next phase of Spartan Protocol.
The winners of last week’s quiz have been announced and a new quiz is up ready for three Spartans to win 100 SPARTA each. It’s not too late to join, just follow the below link to Twitter and answer the question with a quote-retweet:
Spartan Socials — Twitter
Community Tweet of the Week:
SpartanSocials — Medium
SpartanSocials — Telegram
Its been a busy couple of months since the release of MainNet v2, completing objective after objective. We move into an era of further refinement and shift focus more to the integration of Spartan Protocol into aggregators and the wider BinanceSmartChain Ecosystem as originally intended.
COMPLETE ✅ — Enable Synths
COMPLETE ✅ — Build a ‘positions’ page for the DApp
COMPLETE ✅ — Enable SynthVault Incentives
COMPLETE ✅ — Build some charting/analytics into the DApp
IN PROGRESS — Connect SPARTAv2 pools to aggregators
IN PROGRESS — Move onto phase #2 of SPARTA token burns
Overhaul style/UI of DApp
Post-C4-contest article on the top issues
Work with CMC/CoinGecko to feed in the SPARTA pool info
March onwards with our original goals of building the decentralised, yield-generating synthetics protocol on Binance Smart Chain
GitHub Activity — Spartan Contracts v2
Disabled the feeBurn
msg.senderis the SPARTA address
GitHub Activity — Spartan DApp v2
Fix ResizeObserver issue in some Safari browser versions
- Check for the existence of
window.ResizeObserverand inject a polyfill if false
Added simple short number formating. ie.
- Simple value check and format accordingly
Added max-value sanity check for SPARTA grant amount
- Contracts enforce a percentage of the RESERVE holdings for a DAO SPARTA grant, but DApp previously didn’t do that check, which would result in a txn revert without any explanation of why if a user tried to make a massive grant
- To keep things a bit more simple, a flat grant max of 150K has been added to the DApp
Card underlay images
- As we move closer to having a focus on the visual/style, removing the semi-transparent underlay makes sense to have a cleaner slate for dark/light themes as they are built out
Chart date formatting
- Updated all charts to use full date ie.
28/10/21instead of day of the month
- Removed the date labels from the x axis
- Removed the key in favour of a simple title instead
Removed dividend estimate from
- The dividends were rolled into a ‘revenue’ estimate a while back but this was left behind, has now been removed
Added ‘max’ SPARTA check to new/create pool
- Contracts enforce a max of 100K SPARTA initial add when creating a pool. The DApp didn’t check for this which would result in a reverting txn and no clear error message
- Added a simple validity check for < 100K
- Changed the feedback message shown to the user to
Must be between 20K - 100K SPARTA
Added short number formats to PoolItems (for the visual cap bars)
- Was previously not clear the current vs cap amounts via the UI
- Have added in a simple short-formatted number for each side of the visual cap to make it a bit more clear
Added dynamic ‘current’ data point to token price charts
- The last data point on the token price chart is now a dynamic ‘current’ price based off the current external SPARTA price vs token ratios in the pool
SynthVault move APYs to parent
- Moved the SynthVault APY calculations to the parent ‘SynthVault’ instead of showing the same APY on all SynthVault items
GitHub Activity — Spartan API
Setup simple API to retrieve dynamic supply figures
- Initial structure/deps setup to host the API via Vercel functions
- Added ERC20/BEP20 ABIs
- Setup a simple array of web3 calls to retrieve and calculate the dynamic totalSupply & circulatingSupply
- Website: https://spartanprotocol.org/
- DApp: https://dapp.spartanprotocol.org/
- GitBook (Docs): https://docs.spartanprotocol.org/
- GitHub: https://github.com/spartan-protocol
Spartan Protocol is at its core, a community-driven and led project. In this vein, the more contributors the better. There is a great opportunity for community members to contribute by making LP reward analysis tools, etc.
Recently, community members have been graciously funnelling in to contribute to explainer articles, ideas and even $SPARTA donations to support the growth of the platform.
Binance Smart Chain testnet Faucet
Engage with the community and contributors
Where to find out about all the latest updates or suggest improvements — get involved.