Author: Sperax Core Team
Reference: Current docs, SPA Gauge, SIP-32, SIP-33
Created: August 15, 2023
Labels: Product-Features
Summary / Abstract
Earlier in 2023, SperaxDAO decided on the SPA budget for emission through Gauge (SIP-32) and redirecting veSPA emissions to bribes on Gauge (SIP-33). Every week, Gauge emits 2.9 M SPA and veSPA voters are bribed 383K SPA. This SPA should be used more prominently and assertively to drive USDs growth and bring new adoption.
Motivation
Since the start of SPA Gauge, USDs total supply has decreased from $2M to $1.78M. In the meantime, SPA Gauge has emitted about 80M SPA amounting to $392K. The SPA circulating supply has increased from 1.593B to 1.658B.
Emitting SPA in a predetermined manner and without assessing the market dynamics is improper utilization of resources. Since our target is to increase USDs adoption which will help in growing the Sperax ecosystem and its participants, we must rethink our overall strategy.
Overview
Apart from maintaining the target to make SPA deflationary, SperaxDAO should ensure that the emission is invested back into the ecosystem and contributes directly towards increasing the USDs adoption and supply.
All SPA emissions should have a looping effect such that a good portion of SPA distributed should be invested back into the ecosystem in the form of veSPA and increase the burning rate of SPA.
Since the emissions are not helping in increasing either USDs adoption or the locked tokens. The recent increment in veSPA numbers is primarily driven by the team token allocation in veSPA. The Sperax ecosystem is steadily moving towards complete decentralization of protocols and hence should have more governance participation.
The Sperax ecosystem should have a new reward token. A token which can be staked as veSPA or redeemed for SPA. After drawing some inspiration from the Camelot emission strategy, the core team proposes the launch of a new token called xSPA. Users can either stake 1 xSPA for one veSPA or redeem 1 xSPA for 1 SPA.
Technical overview
Users can redeem 1 xSPA token for SPA by depositing their xSPA token through the redemption contract. Users can stake 1 xSPA in veSPA to increase their staked SPA balance. The relation between xSPA, SPA, and veSPA will be governed by the following rules
- 1 xSPA will be equivalent to 1 SPA.
- Users can redeem 1 xSPA for 1 SPA if they lock the xSPA in the redemption contract for 180 days, the maximum redemption period.
- Users can redeem 1 xSPA for 0.5 SPA if they lock the xSPA in the redemption contract of 15 days, the minimum redemption period.
- If the redemption period is ‘x’, between 15 and 180 days, the amount of SPA a user gets is governed by the following equation.
- Receivable SPA = [{(x-15)/(180-x)}*0.5 + 0.5]*xSPA
- A redemption request cannot be modified or canceled.
- The redemption contract will instantly burn any differential SPA
- In case of the minimum locking period of 15 days, half the SPA tokens will be burnt right away and users can claim their SPA tokens after 15 days.
- In case of a maximum locking period of 180 days, no SPA will be burnt and users can claim their SPA token after 180 days.
- In case of a period between 15 and 180 days, SPA burnt will be xSPA*[0.5 - {(x-15)/(180-x)}*0.5] and users can claim their SPA tokens after ‘x’ days.
- Users can stake 1 xSPA token in the veSPA contract to increase their staked SPA balance by 1 SPA token for the existing lockup period if the lockup period is greater than 180 days.
- If the user has 0 staked balance, the system will throw an error and will ask the user to create a staked position with a minimum staking period of 180 days
- If the user has staked balance but the lockup is less than 180 days, the system will throw an error and ask the user to increase the locking period to a minimum of 180 days
- Users will be able to increase their staked position if the lockup period is above 180 days.
- xSPA token will be transferrable.
- The staking and redemption criteria can be updated/modified through governance.
Voting
For
Launch new xSPA token as per mentioned specifications
Against
Continue as it is without the new token
