TwitterRSS Feed

SpartanDev: 22NOV21 - 28NOV21

Dev Update

SpartanDev: 22NOV21 - 28NOV21

Read up on the feeBurn being phased out whilst we begin a campaign to burn 30M SPARTA in the coming months

SpartanDev: 22NOV21 - 28NOV21

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.

#FridayFor300 Quiz

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

Contributor's Focus

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

  1. Changed Utils.getFeeOnTransfer() to return 0 always
  2. Changed Utils.calcPart() to return 0 if the msg.sender is the SPARTA address

GitHub Activity — Spartan DApp v2

Fix ResizeObserver issue in some Safari browser versions

  • Check for the existence of window.ResizeObserver and inject a polyfill if false

Added simple short number formating. ie. 1,000,000 -> 1M

  • formatShortNumber() added to utils/bigNumber.js
  • 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

Removed all 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/21 instead 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 LiqRemove

  • 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

  1. Initial structure/deps setup to host the API via Vercel functions
  2. Added ERC20/BEP20 ABIs
  3. Setup a simple array of web3 calls to retrieve and calculate the dynamic totalSupply & circulatingSupply

Project Information

  • Website: https://spartanprotocol.org/
  • DApp: https://dapp.spartanprotocol.org/
  • GitBook (Docs): https://docs.spartanprotocol.org/
  • GitHub: https://github.com/spartan-protocol

Community Contribution

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.