Mon. Jul 26th, 2021

    During the weekly meetup, participants discussed the holding of a stablecoin contest, raised the issue of oracles, and planned a payment session. TON Alliance shared the latest updates.

    Weekly DeFi Governance Call #25

    Stablecoin contest staging

    Alexander Vat talks about the need to divide the stablecoin contest into stages (he suggests four). In the Alpha version, a stabilization mechanism was introduced. Alexander proposes to put a criterion for the first stage, which stipulates that each of the participants will provide a roadmap for the next stage.

    Vladislav Ponomarev agrees that the milestones need to be designated, but the stablecoin contest does not require 3-4 stages, in his opinion. It may be possible to distinguish more general stages.

    Vladimir Maslyakov believes the easiest way is to combine the second and third stages. He also agreed that the proposal should be more general. Perhaps oracles need to be excluded from the Alpha stage. Many proposals for design are heavily dependent on oracles.

    Sergey Shashev reviewed the proposal, he had a few questions about oracles, noting that they are an important part of the entire DeFi ecosystem. Sergey offers to organize a contest for oracles as an independent one.

    Vladislav recalls that they have already encountered the situation when teams could not participate in several contests at the same time. He proposes to prioritize the oracle contest, and  then hold a stablecoin contest.  As for Dune, the contest for architecture could be held within a few weeks.

    Vladimir Maslyakov says that based on experience, architecture contests always provide excellent insights for all teams at the implementation stage. If time allows, an architecture contest should be held.

    Updates from TON Alliance

    About five funds are ready to provide liquidity to our bridge. They have some conditions regarding security audits. At least 10 negotiations were held with various audit companies, two are ready to audit our bridge. For them, this is quite a difficult task, few can audit Rust components. Work with them can begin not earlier than June.

    Four companies are ready to develop various projects in our ecosystem. Two big players from the Ethereum ecosystem and one team looking to create a decentralized launch pad. We are in dialogue with them and it may become the first company to work with the DeFi Alliance.

    A bridge update was created, we fixed some problems. For this reason, the Uniswap listing has moved forward one week. We also started creating content about DeFi news, which will soon be available to the entire community in the Free TON chat.

    • Perhaps we need to put the liquidity pool in Uniswap after we have DEX in Free TON?

    We want to create a primitive mechanic in Uniswap and all liquidity providers will receive TON crystals, but in order to get it, we need to install wallets and we need to discover the Free TON ecosystem. 

    When we see the finished DEX, we will contact the teams directly.

    Bitcoin bridge discussion

    One of the Korean funds is ready to put a large amount of bitcoins into Free TON liquidity.  We only have a draft and no team. Sergey Shashev believes that a contest should be held.

    Vladislav supports the idea of holding the Bitcoin Bridge Design and Architecture contest, since it will be different from Etherium. At this stage, it will be possible to find out how many teams are ready to participate. Perhaps it will be possible to attract the Dune community, there are many talented developers there.

    Vladislav reminds the jury members that the 1st stage of DEX contest implementation ends in 8 days. Almost all participants posted a video. Vladislav asks the jury to have a look and provide some feedback.

    • Is there any draft for the second stage of the DEX contest?

    At the moment we are in a rather unclear situation, we do not know exactly what will be implemented at the first stage. For this reason, all these stages are in draft form. The discussion will take place in stages for this contest.

    Vladimir Maslyakov says that the results of the first stage may affect the draft of the second stage. The second point is that it is necessary to prioritize the stablecoin contest, so as not to intertwine these two contests. They need to be held separately from each other, since several teams want to take part in both.

    Anzor touches on the topic of the criteria written for the first stage. He pays his attention to the fact they are quite difficult to understand. Vladislav explains that it was for this reason that he asked the jury members to show and explain how the solution works. The contest was formed in this way, as there were several approaches at the stage of architecture and design, which were not similar to each other in implementation. The guys tried to make the contest in such a way as to cover everything. This may be causing some confusion in the text. If you have any questions, feel free to contact the jury, they will provide you with answers.

    Voting issues

    Alexandr Vat believes that the main problem with voting is that jury members can see previous votes. This can affect the objectivity of the assessment. For this reason, Alexander favors blind voting, when the marks are not visible until the end of the contest.

    Vladislav believes that this is one of the possible approaches. It is necessary to raise our best juries, to motivate them to bring the highest standards of judging — this is the main task.

    Alexander Vat mentions the ACCS Bitcoin-Ethereum-Bitcoin contest. Vladislav explains that Atomic Swaps and bridges are slightly different technologies, they differ in implementation on both sides of the blockchain. The implementation we had a few months ago for bitcoin swap doesn’t seem so good anymore. For this reason, we rework it. There are a whole set of issues related to Atomic Swaps, including privacy, how it should be implemented, etc. But overall, it is a good product, and I hope that we will provide an updated version in the near future.