Free TON

Free TON Governance (Part II) Contest [DRAFT]

Motivation

We need a system of voting contracts to regulate governance and decision making in Free TON. Those contracts are a principal tool of decentralization. It is supposed to be used in many aspects of the Free TON blockchain to provide mechanisms for community governance.

This is a second stage of the contest which aims to implement a Free TON BFT Governance proposal.

As such it should meet the following requirements:

Transparency — everyone in the community should be able to verify the results of the Contests, review proposal and links to its description and how results are implemented.

Ease of use — every community member should be able to participate even without a deep technical knowledge

Security — the highest level of security should apply

Flexibility — it should be flexible enough to serve many applications requiring Contest mechanism in Free TON, it should be able to manage Contests on different group levels and for different use cases

Composability — it should be possible to use smart contracts in the system with other contracts on Free TON blockchain, thus providing internal methods with a clear interface designed to access contract features.

Formal Verification — all governance contracts dealing with Funds must be formally verified. Therefore only contracts in Solidity and C++ will be accepted.

Type:

Contest

Contest entry period:

February 15 - March 31

Requirements:

  • To develop a BFT Governance smart contract system according to the attached specifications
    Practical Byzantin Governance.pdf (172.7 KB)

  • The solution can propose a modifications and additions to the BFT Governance protocol which should be in line with BFTG principles.

  • To create a technical documentation for the implementation

  • Should include DeBots for all system user interfaces

  • Should include auto-tests designed as a smart contract or a script to test scenarios.

  • A solution should have a Free Software license (https://www.gnu.org/licenses/license-list.html ).

  • A system should be deployed and tested on the DevNet and Jury should be able to access it for testing.

Evaluation criteria and winning conditions:

  • A solution should be implemented in accordance with its documentation
  • A solution should pass attached tests
  • If some scenarios from requirements are not covered by a test, then jurors can develop their own tests, but it should reduce the score of such a submission.
  • Solution should be scalable to thousands of participants

Voting:

  • Only qualified jurors, able to understand, rub and evaluate smart contract on Free TON should judge. Jurors whose team(s) intend to participate in this contest by providing submissions lose their right to vote in this contest.
  • Jury from other sub-governance groups could be added to this contest to provide additional technical expertise.
  • Each juror will vote by rating each submission on a scale of 1 to 10 or can choose to reject it if it does not meet requirements, or they can choose to abstain from voting if they feel unqualified to judge.
  • Jurors will provide feedback on your submissions
  • Duplicate, sub par, incomplete or inappropriate submissions will be rejected.

Reward:

1st prize…………………………………………… 300,000 Tons

2nd prize…………………………………………… 150,000 Tons

3rd prize…………………………………………… 75,000 Tons

4th place …………………………………………. 50,000 Tons

5th place …………………………………………. 25,000 Tons

Total prizes: 600,000

All rewards should be vested over a period of 1 year under the terms of reasonably supporting and enhancing it based on issues submitted by the community to the solution repository during that time.

Note: If the number of winning submissions is less than the number of rewards available, any remaining rewards are not subject to distribution and are considered void.

Jury rewards:

An amount equal to 7% of the sum total of all total tokens actually awarded will be distributed equally between all jurors who vote and provide feedback. Both voting and feedback are mandatory in order to collect the reward.

Contributor rewards:

As part of the support for administrative work being performed by various sub governance members the DGO will reward contributors to the creations, organisation, follow up and other activities around the execution of its contests.

An amount equal to 1% of the sum total of all total tokens actually awarded will be distributed equally between all contributors:

Mitja Goroshevsky
Nikita Denisov
Andrey Lyashin
[PLEASE ADD]

Please add people who have contributed to this Contest in the comments

Procedural remarks:

● Participants must upload their work correctly so it can be viewed and accessible in the formats described. If work is inaccessible or does not fit the criteria described, the submission may be rejected by jurors.

● Participants must submit their work before the closing of the filing of applications. If not submitted on time, the submission will not count.

8 Likes

May be that makes sense to mention, that this paper is also in a draft phase and the final version may change significantly?

Summarizing my thoughts expressed in the DGO group on this topic, I lack an in-depth analysis of the scalability of the contest and the tools to avoid possible overloading of the jury staff when / if the public response for a concrete contest is huge due to the ever-growing community and potential number of participants. How, for example, can one judge check several thousand submissions within a reasonable time frame? I know that in the current environment this problem seems unrealistic, but what if…?

I’m also convinced that vesting (lock / payout in instalments) of winners rewards should become an integral part of DGO smart contract collection. I remember that @Mitja suggested putting this task into a separate competition. Just take a note of this.

Well… This is a tricky part for anyone with modesty. I think you are the best candidate to decide here.
From my side I can suggest people (by their Telegram IDs), who took part in the group discussions or calls on regular basis, even if their ideas won’t find place in the final draft: @anesthesia_v, @Laugan, @isheldon, @lmperfectk, @noam_y… Not all of them - suggest more or disagree…

Will ideas or parts of entries from the competition be included? :point_down:

I would like to think that the work was not in vain.

Good. i hope this Contest will increase DeBots adoption!

I fully support launching this Contest. My only comment is to clarify the seemingly interchangeable use of:

Jury
Juror
Jurors
Jury Member
Judge
Juries

which may appear confusing for those who are just joining Free TON.

Latest draft for the contest purpose

Practical Byzantin Governance(draft3).pdf (232.7 KB)