I have discussed the core thesis behind XStable at length in the previous article. Let us dig a bit deeper into the contracts that power the protocol, how they function, and the operational mechanics.
At its base, XStable currently relies on Uniswap pools to identify the buy and sell volumes. The protocol will be launching with 1 pool XST-ETH but will be adding XST-USDC and XST-WBTC pools once the total supply crosses 10mn. This will help XST in achieving balanced stability vs ETH — USDC — BTC trio.
Identifying the transaction
With the Uniswap pools, the first challenge is to identify and differentiate the 4 types of interactions with the pool — buy, sell, add liquidity and remove liquidity. These 4 transactions work as below:
As you can see, at the time of interaction with XST contract, both add and sell transactions are virtually the same and as such, there is no reliable way to differentiate these transactions during the transaction. Even with Buy and Withdraw transactions, it is not so straightforward. State updates happen during the transaction after the interaction with XST contract is done, which we have no way of tracking reliably.
So, if we maintain 4 metrics that are updated with each transaction — XST balance, TKN balance, LP balance, XST/TKN ratio, we can reliably differentiate between a withdraw and buy, except for two scenarios — a) buy follows a sell, b) withdraw follows an add. You can see below how the metrics are impacted in these two circumstances.
In case of a withdraw followed by an add, LP Balance could be higher or lower than that of the previous record. Similarly, for a buy followed by a sell, token ratio could be higher or lower. While using these metrics, there is a clear clash when both result in the exact same state. In such a scenario, it essentially means that either a previously added liquidity has been fully withdrawn or the exact same number of tokens that have been sold in the previous transaction have been bought back, both of which are unlikely. But if the unlikely event were to occur, we consider it as a buy and additional minting of tokens would happen in this scenario. There is a chance that a malicious player might just add liquidity and withdraw liquidity to mint a large number of tokens. We introduce the next step to eliminate this possibility.
Any liquidity addition directly to Uniswap pool will result in considering this as a regular transfer and the transfer tax as well as the utility fee will be applied to that transaction. As such, if a malicious actor were to add liquidity and remove liquidity to trigger mints, the system will still be in equilibrium as the mint from the remove will equal that of the burn from the add, causing no issues. In addition, the actor is disincentivized because the burn happens only from him while the mint is distributed to all the holders. There is also an additional function provided to route the liquidity additions via the contract that bypasses the tax. The state is also fully updated after the liquidity addition is completed here and a full withdrawal is directly identified from the LP token burn.
This is the first step towards the contract functionality, identification of the 4 different types of interactions with the Uniswap pool.
Main Contracts & functions:
The major contracts and their corresponding core functionalities are discussed below:
- XST Contract — This is the primary token contract with mint and burn functionalities.
- Presale mints 100,000 tokens, remaining tokens are minted as per the announced distribution along with the locking mechanisms right after the presale ends. This ad-hoc minting mechanism is auto-disabled by the contract after the presale is marked as done. There is no option available to unmark this once it is marked.
- Liquidity is auto deployed to Uniswap after the presale ends and token transfers will be auto-enabled once the liquidity deployment is done.
- Every buy transaction triggers a mint to be distributed instantly to all token holders. At the beginning of each epoch, base mint is at 1% of the transaction size. If the buys are stacked up and buy volume is disproportionately larger than sell volume, this mint rate starts climbing as a quadratic function. So, if a pool has 100,000 XST and 100 Eth at the beginning of the epoch, the beginning ratio is 100:1. After a while, due to buys, if this ratio gets to 90:1, then the ratio is skewed10:9. So, the mint factor = (10/9)²-1 = 23% of transaction. This is distributed in a 90:5:5 ratio to the holders, stabilizer, and treasury.
- Every sell transaction triggers a tax and burn. At the beginning of each epoch, the base burn is at 1% and the utility fee is at 0.5%. So, if there is a disproportionate sell volume that skews the ratio from 100:1 to 110:1, then the tax would be 21% for burn + 0.5% for utility fee. However, at the initial stages of the protocol where liquidity is small, such volatility is important and protocol should be allowed to expand. As such, at the moment, sell burn tax is capped at 10% while the liquidity building happens in the primary pool. 0.5% utility fee is transferred to the liquidity reserve that translates to permanently locked liquidity.
- All transfers to unsupported pools or wallets also incur taxes at the same level as that of a sell. Liquidity addition to the pool is supported via the liquidity contract. Direct addition via the Uniswap interface will result in a tax and burn.
Presale
- We will discuss the core mechanics of the presale contract in the next article that discusses the presale. Meanwhile, some important metrics for Presale are discussed in the next section.
Liquidity
- This contract provides the function to add liquidity to Uniswap pools without incurring any tax. At present only liquidity addition via a single asset, ETH is supported. But over time, we will add features to swap any ERC20 tokens into XST liquidity, in addition to LP incentives.
Liquidity Reserve
- The utility fee from each sell transaction is routed to the liquidity reserve contract. This converts the utility fee into permanently locked liquidity. Any wallet can call the convertToLiquidity() function to trigger this. Conditions being the caller wallet should hold a minimum of 500 XST tokens and the reserve should have a minimum of 500 XST tokens. The caller gets awarded 25XST in lieu of the gas costs incurred in calling this.
Stabilizer
- This will be discussed in a future article as the stabilizer comes into effect once the total supply reaches 10mn XST. As such, the current contract is only a placeholder to receive the percentage of inflation. This contract will be upgraded later with the required functionality.
Important Contract Parameters
To learn more about XStable.Fiance:
