The Spartan Protocol allows the generation of synthetic assets (synths) of curated BEP20 pooled assets, using price anchors offered by its own liquidity pools, collateralised by (staking) SPARTA tokens.
This is done through the use of code. As the Spartan Protocol is decentralized and community-driven, you do not need to rely on any intermediary. It is a trustless process.
All assets on the platform are pegged to the price of the protocol's token:
Therefore, there is no need for the use of any oracles.
Liquidity pool shares are on-market, value-stabilised and can be instantly liquidated. Liquidity-sensitive fees ensure positions taken up will scale with the depth of available liquidity, preventing deleveraging spirals common to other systems.
Read about Liquidity Pools here for more info.
Based on the currently proposed implementation; for the first phase of SpartanSynths, the main utility of synths will be to enable its users to open long-
or short positions on any BEP-20 assets with leverage, without the need of know-your-customer processes and without relying on any centralized exchange.
At first, the assets with the deepest liquidity pools on the platform will be supported. These assets are liquid enough to support minting synths and leverage trading.
Synths will likely include at first (but not be limited to):
Future phases could theoretically include supporting a basket of BEP20 assets, rather than 1 particular asset. As well as any gold-backed or stock-backed BEP-20 asset.
In order to create synths on the Spartan Protocol, users need to first hold (or purchase) SPARTA tokens.
With these tokens, users can interact with the Synth Contract.
This SPARTA is then added as an asymmetric-liquidity-add to the relevant pool.
These LP tokens are then held at the SynthFactory; which handles the minting of synthetic assets.
Synths can be enabled for the creation of any asset enabled by the DAO. As communicated above, the protocol first enables this with the assets that have the deepest liquidity pools. Synths mimic the value of the created asset (i.e., BNB). The value of locked SPARTA needs to remain at or above a certain threshold of the synths created. This is automatically calculated, the exact threshold has yet to be communicated. However, the collateral position percentages can be tighter on Spartan Protocol than typical implementations due to the internal pricing mechanism and BSC's fast transaction times.
By creating these synthetic assets, users basically enter a long or short position of the created asset. The LP tokens (and underlying base assets) acts as collateral, whereas the minted assets act as debt. If the value of the locked SPARTA tokens increases, the protocol automatically releases part of the locked tokens. This liquidity can then be used to create more assets again, if wished, to further increase the position.
A special 'compound contract' has been proposed and implementations have already been built with the purpose of enabling users to plug in synthetics to either increase or decrease the leverage of their position. This may or may not make it to the mainnet implementation as it's own separate contract, but the point is that there is a focus on providing the ability for decentralised peers to leverage up their positions in this ecosystem!
The protocol uses internal pricing directly connected to the liquidity pool values. This means there is no reliance on other oracles or externalities.
On top of this, the community contributors are considering introducing the 'Loan Contract' aka 'SpartanLending'. This would enable users to deposit LP tokens or SPARTA tokens into the contract to receive interest. Read about Lending here for more info.
Synthetic assets are not live yet. However multiple implementations are being worked on currently to ensure 'SpartanSynths' is the best it can be.
We recommend you to join our social channels to stay tuned for updates from our community contributors. The wider community is welcome to join in once a testnet UI has been launched.
A tutorial on the creation of synthetic assets is to follow upon the launch of a (public) testnet of a more finalised implementation.
Users that wish to interact with the protocol do need a few things: