Contest Proposal: GrandBazaar Auctions Smart Contract Code Audit
The contestants shall provide the informal audit of the central Grand Bazaar smart contracts (Offer and Auction), 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)
Before entering the informal audit process, each smart contract must comply with the following rules:
- The smart contract must be compilable with the latest version of tondev tool
- All smart contracts must be submitted with detailed documentation
- The smart contract’s developers must set up a Telegram group for discussions as well as a slot for one-hour voice meetings at least once a week
- All the smart contracts being audited must be covered by unit and integration tests
- All the tests must pass
The source code is available at GitHub - grandbazar-io/True-NFT at branch master with hash code equal to b887198ded91f930f6e16191a0be2bf3764f01ae.
Contestants shall submit a document in PDF format that covers:
● All the errors found
● All the warnings found
● All the “bad code” (long functions, violation of abstraction levels, poor readability etc.)
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.
11 Oct 2021 - 18 Oct 2021
The total contest budget is 22 kTON, whereby 18kTON are allocated to the contestant awards and 5% are allocated to the jury reward.
The contestant awards are distributed as follows:
- Place 1 - 10 kTON
- Place 2 - 6 kTON
- Place 3 - 3 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 3 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.
- Only one submission per contestant shall be accepted. Multiple submissions, including but not limited to updated versions of the initial submission, are not allowed.
- Submissions shall be made within the time frame defined above in the Contest Dates section. Late submissions shall be rejected by the Jury.
- All submissions shall contain the contestant’s contact information (preferably a Telegram ID) to ensure that the jury can match the submission to the specific contestant. If such contact information is missing, the submission shall be rejected.
- If the submission contains links to external material (reports on further work by the contestant), this material shall have the contestant’s contact details (preferably a Telegram ID), to ensure that the jury can match the material to the specific contestant. If such contact information is missing, the submission shall be rejected.
Anyone can participate, but Free TON cannot distribute tokens to US citizens or US entities.