At the weekly meetup, participants discussed the third stage of the Polkadot bridge, the second stage of the DEX contest and the oracle contests. They also touched on the topic of the unique interface for DEX aggregators.
Polkadot bridge contest. Third stage
The Wintex.pro team is almost ready to start the third stage of the contest. The last three weeks have been quite low in activity due to a large research, huge part of which was devoted to the distribution of responsibilities in the bridge. As a result, we came to the conclusion that the implementation of VRF on smart contracts can come to huge commissions. It was suggested to use the native Free TON cryptography. However, VRF will still be used on the substrate base as it is already implemented and works well.
As for the third stage, the distribution of relayer responsibilities is a hard criterion. The second is the commission calculation. This step includes calculating the amount of gas for the message, but without the real commission payment. The third one is the CLI tool for relayer’s keys generation. And, as usual, updating DevOps tools to run multiple relayer nodes. Documentation is also necessary for this type of contest. The draft of this document will be published in the Telegram chat.
Vladislav asks everyone to get acquainted with the project and provide some feedback.
DEX contest. Second stage
Anzor believes it is necessary to adhere to more functional requirements than interface requirements, such as Pool Explorer. It is simply a display of the data that is already there. It is necessary to focus on efficiency, on optimizing the use of specific Free TON technologies, which will help make DEX cooler, faster, more cost effective. The solution should demonstrate how reliable it is for a large number of operations. It should also be stable. DeBot interfaces must also be there so that using DeBot, the user can do everything that a Uniswap user or any centralized exchange user can do.
Mitja supports the previous comment regarding the criteria. He believes there is no need for a large number of stages. The criteria should definitely be broader.
The second stage, according to Vladislav, should be aimed at the end user:
- It should be manageable so that the user can add a new pair and start trading it;
- It should be accessible so that the user can access this DEX and conduct transactions;
- It should be productive enough. A large number of transactions should not take too long for the user to make an exchange.
Vladislav recalls that a kind of consortium for TIP-3 standardization, at least for DEX implementation, is already underway.
Mitya says that in TIP-3 there must be a code inside any contract that wants to verify it. This means that if you are making a truly distributed system, you care about the size of the code. If we create a universal code for TIP-3, we will have a huge contract with a huge number of interfaces in it, which contradicts the basic principle of TIP-3. Even if all the teams minimize the interface to one, it will not fit into 116 kilobytes. But there is a solution: you can easily get wrappers or converters between all these exchanges. The transaction cost is minimal, it is incomparable to the cost you would pay if you had only one contract with all interfaces.
Unique interface for DEX aggregators
Vladislav proposes to create a unique interface for aggregators for various DEXes, since now big aggregators with DEX are more convenient for users. If all DEXs have a more or less similar interface for aggregators to access, this will facilitate liquidity flows and facilitate the user experience.
- Instead of creating a single TIP-3 interface standard, you propose to create a single DeBot interface standard, right?
It makes no sense to have a TIP-3 interface. What you need is an interface to a smart contract, this is DeBot.
- Do we need to wait until the end of the oracle contest to launch the second stage of the DEX contest?
I don’t think they are related in any way.
Oracles contest discussion
Vladislav’s team reviewed the draft of the oracle’s contest and had only one remark: there was no need to set a vendor lock to TON SDK. The contest will be launched early next week.
Listing of WTON (Wrapped TON) on Uniswap
We wrapped TON to WTON and put some liquidity on Uniswap for testing. There are now two technical problems that need to be solved in the Ethereum system. The first problem is the verification of the smart contract. The second one is to set a place in Uniswap, as there is another WTON, which came as a surprise. The first “field farming” mechanics is about to start. Liquidity providers will all receive special tokens in the Ethereum system. It will be possible to move these tokens across the bridge to the Free TON ecosystem and we will get TON Crystals for that.
- What are your plans to promote WTON?
The first thing is the “field farming” mechanics. We want to deliver TON Crystals to some of the major liquidity providers in the Ethereum ecosystem. After that, we will create mechanics for transferring liquidity between Uniswap and DEX.
The wrapped TON is just a part of the ecosystem and is tied to the progress of our DeFi ecosystem as a whole.
Vladislav reminds everyone that the conference will be held in Dubai on May 25-26. One of the Free TON sections there will be dedicated to DeFi. In order to participate in this meetup, it is necessary to take part in the contest. The number of tickets is limited.