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:



Liquidity Reserve


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.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store

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