Undoubtedly, DeFi is the trend of the crypto world in 2020. The DeFi concept provides for a decentralized exchange, investment, and lending system. Fewer limitations, more democracy, more control over your funds — now you trust them to smart contracts and algorithms instead of specific persons.
Uniswap has become a big revelation for the Ethereum ecosystem. We strongly believe that Uniswap caused a bootstrap of the whole DeFi ecosystem because such systems as Uniswap have broadened the horizons for a great number of projects. Now we have access to liquidity and “stock” trading. This has also created completely new ways of economic interaction. For example, we can use tokens, which represent pools’ shares, for such additional rewards as liquidity mining.
QuipuSwap is just the beginning of the Defi ecosystem story on Tezos. We believe that this will boost new and other Dapp projects on Tezos.
QuipuSwap can already be tested on the testnet. Read here how to do it.
Tokens
Tezos has 2 token standards now — FA 1.2 (interchangeable tokens; in other words, there is no difference between the same tokens of this standard) and FA 2 (a token standard that allows you to attribute different characteristics to tokens; for example, to make them interchangeable by analogy with FA 1.2 or attribute the characteristics of NFT tokens to them).
Thereby, our QuipuSwap supports FA 1.2 tokens and interchangeable FA 2 tokens.
The review of QuipuSwap contracts
After observing the QuipuSwap website, you may think that this system is quite simple, but it is not. QuipuSwap standardizes exchange mechanisms through a set of smart contracts.
Let us elaborate on two types of these contracts:
- Factory
- Dex
https://github.com/madfish-solutions/quipuswap-core
Dex is a contract of the TokenX/XTZ pair. With its help, users can exchange, manage liquidity, and participate in voting.
Factory is a “service” contract that allows you to create new pair contracts and store TokenX-Dex matches (to make them easier to find).
New pairs are added via the launchExchange function of Factory contract. Since the protocol is decentralized, any user can list a token on the exchange and provide initial liquidity. If the token has not yet been added and the initial liquidity in TokenX and XTZ is greater than zero, Factory will create a new pair contract and transfer the custom tokens to the pair’s pool. The “creator” of the pair will receive 1000 shares, namely internal tokens that represent his influence in this pool. Shares disappear when liquidity is withdrawn and emerge when liquidity is added.
The current solution provides support for FA1.2 and FA2 tokens separately. There are two versions of Factory and Dex that have all the functionality described above:
- Factory1.2 and Dex1.2
- Factory2 and Dex2
Their only difference is how they interact with the token. Since the exchange of a token for a token occurs through the exchange of the first token for XTZ and the exchange of received XTZ token for the target token, the exchange of tokens of different standards is not a problem.
It also affects the format of stored/transmitted data, since FA2 is a multi-token contract. In other words, you need to know its ID, not just an address. In this case, the creation process will require this parameter to be specified when called.
Governance and unique features
You may wonder how the governance system looks like in the Uniswap-like protocol. It would be desirable to support the unique features of Tezos and participate in baking simultaneously, wouldn’t it?:)
Since each QuipuSwap pool stores not only tokens but also Tezos, this Tezos liquidity can be used to delegate it to the baker. Thereby, pool holders earn additional income.
That’s when our questions begin. Which baker to vote for? Who is eligible to vote and what is the value of each vote? What if the baker is misbehaving or avoiding paying to Tezos?
The first suggestion on how to manage the baker selection process (in the last post) was formalized in a new, recently published document, “Governance framework for Quipuswap — automated decentralized exchange”. In this paper, we have also discussed how to share profit between users. There are also some new details related to WatchTowers’ topic.
For the management of the delegation, 2 protocols were proposed:
- Analysis from the incentives’ viewpoint
So, we have many holders and we can choose only one baker for each liquidity pool. It means that if a user has their preferences and affiliations with a particular baker, they have two incentives that can be contradictory.
The first incentive is the wish that their baker would win. The second incentive is the wish that all bakers would pay a reward to the protocol regardless of whether they win or lose. In this situation, we have a free-rider effect, since each user votes for a particular baker. If the protocol is modified so that users have veto power, the free-rider effect will disappear, because users will not have to change their preferences related to voting for their favourite. You can find a detailed mathematical model in the document (link).
By the way, it is very symbolic if we take into account the specifics of our current political processes since in many democratic countries it is possible to impeach the head of the country. The only difference is that in our case we have real direct democracy 🙂
2. Profits’ distribution
Profits from within QuipuSwap will be distributed not only in proportion to the user’s stake but also in proportion to the time how long this money was inside the pool. If we use the classical linear dependence, in this situation we will not have to unite into large accounts artificially or divide money invested in the liquidity pool among small accounts. Why is it so important to consider not only the proportion of the stake but also the time? Since the baker does not start paying immediately, this delay should be used for new liquidity providers. It minimizes the risk of bakers’ manipulations on the part of bakers or other people who know the approximate time of their reward payments. If you have this information, you can mortgage most of the liquidity right before the payment of the baker’s reward and take a significant chunk of it.
3. A little bit about WatchTower
To prevent the baker’s malicious behaviour, one assumes that the voter should set up the WatchTower, i.e. the software for monitoring the baker’s behaviour with the punishment (veto) mechanism.
WatchTower reacts (i.e. vetoing) if a baker does not send the reward or takes more than the fee amount.
4. Participation in the protocol
If QuipuSwap is deployed on the mainnet, it will be useful for everyone who will fill the liquidity pool to vote with liquidity within the QuipuSwap pool for their preferred baker and follow him via WatchTower.
We will be very grateful if you take a look at the full document on governance and come back with your feedback. Many thanks!
Special thanks to the authors of this article:
Matvii Sivoraksha,
Anastasiia Kondaurova,
Andrey Sobol (twitter)
Useful Links
Quipuswap UI — user-friendly interface for interacting with Quipuswap protocol,
- UI source code
https://github.com/madfish-solutions/quipuswap-webapp
- Quipuswap Core Smart-contracts— sources of protocol’s smart-contracts
https://github.com/madfish-solutions/quipuswap-core
Guide — How to try QuipuSwap on testnet?
Governance framework for Quipuswap — automated decentralized Exchange — full research
Our Twitter: https://twitter.com/madfishofficial
