Contest Proposal: DeNS Smart Contract Code Audit
The contestants shall provide the informal audit of the central DeNS smart contracts (D4Auct, D4Base, D4Cert, D4MFT128, D4Root, D4User), hereinafter referred to as “smart contracts”, where the detailed description of the “Code audit” is described below. All debot contracts are excluded from the present contest.
Ideally speaking, all smart contracts issued by the Free TON ecosystem must pass the formal verification process. However, as the formal verification is an extremely time-consuming process, in some cases the business cannot wait for such a long time. Additionally, each bug found during the formal verification requires a major rework of the whole underlying stuff already completed.
To address both above-mentioned issues, we suggest undertaking the Code audit before proceeding to formal verification. Being capable to find most bugs, the completion of this kind of activity allows us to:
- Release a smart contract with a high (but not the highest) level of reliability (this should be undertaken exclusively in a case of a strong business need)
- Dramatically decrease the likelihood of finding a bug during the formal verification (taking into account that each bug found at the formal verification stage brings major overhead for the proving system)
The contest should be compliant to the Generic Contest Rules.
The source code is available at GitHub - Skydev0h/FTC-DeNS: FreeTON Contest - Decentralized Name Service at branch main with hash code equal to 9af9b7dbed2a8944ada39d47058df988d45960d7.
Contestants shall submit a document in PDF format that covers:
● All the errors found
● All the warnings found
Errors and warnings should be submitted to the developers as early as possible, during the
contest, so that the code can be fixed immediately.
The document should also contain a high-level description of the system, and any information
showing that the contest had a good understanding of the infrastructure and of the code.
15 Dec 2021 - 24 Dec 2021
The total contest budget is 180 kTON, whereby 160kTON are allocated to the contestant awards and 20 kTON are allocated to the jury reward.
The contestant awards are distributed as follows:
- Place 1 - 80 kTON
- Place 2 - 60 kTON
- Place 3 - 40 kTON
The Jury shall be formed from acknowledged experts in the fields of security, smart contract audit, and formal verification fields, whereby:
- Jurors whose team(s) intend to provide submissions in this contest shall lose their right to vote in this contest
- Each juror shall vote by rating each submission on a scale of 0 to 10 (0 equalling rejection of the proposal); a juror may abstain from voting if they do not see themselves sufficiently qualified to judge such proposal
- A juror that has voted on a submission shall provide detailed feedback on it
- The main goal of the jury is to check how the provided audit is useful in terms of decreasing the bug risk for the contract being audited
- All the requirements mentioned above are considered as mandatory otherwise some points have to be taken from the corresponding application
- The usage of industry-adopted 3rd party tools should bring additional points in case the motivation of their usage has been clearly demonstrated
- Any team that managed to find a non-minor bug must be placed higher than a team that failed to do it
- Any bugs related to the kind of the exceptions as well those related to the logging or retrieving the state are considered as minor and should not be taken into account for the ranking
The total budget for jury rewards is 20 kTON.
This amount shall be distributed between jurors who have voted and provided feedback on submissions.
The proportion of the total budget assigned to a juror shall be defined according to the extent of this juror’s participation in the contest, i.e. the count of votes cast by this juror divided by the total votes cast count for this contest.