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

  • 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:

Chat with us on Telegram
Follow us on Twitter

A synthetic stablecoin protocol that derives it's supply and price values from true market demand.