Contest Proposal: NFT certificates for the systems of smart contracts that passed formal verification/audit

Ever TON Dev Experience Sub-Governance
#1

Contest Proposal: NFT certificates for the systems of smart contracts that passed formal verification/audit

Short Description

The contestants shall provide the ready for production set of smart contracts and debots that allow to:

  • Generate a new NFT certificate that confirms successful pass of the formal verification/audit for the particular smart contract system
  • Grant ownership to the certain owner upon deployment
  • Demonstrate the ownership of the particular certificate with the data bound to the NFT certificate
  • Tools for listing all the issues certificates as well as for searching a particular one

Motivation

The fact of successfullysuccessful passing the formal verification or, at least, code audit, is a great marketing advantage for the owners of any smart contract system and, evidently, has to be utilized. However, currently the owners are not able to provide any kind of clear evidence of such a pass. It should be changed and ForMet SG is expected to provide some tools for demonstration of a pass to the end-users and partners.

The possible solution is to keep a registry of the smart contract systems that passed the formal verification/audit. However, it’s a centralized solution hardly acceptable in a decentralized ecosystem. The clear modern alternative is to use NFT certificates to be granted to the owners. Such a solution eliminates any kind of further dependency on the ForMet SG that allows to use the issued certificate even in the unlikely case of ceasing the activity of ForMet SG.

Requirements

NFT certificate data

The issued NFT certificate must contain the following data:

  • The legal disclaimer that must be developed by the participant and include, at least, the following:
    • Declaration of “as is” principle - no warranty, no responsibility under any circumstances
    • Brief description of the certificate’s value
    • Declaration that the present certificate is a utility one and can not be used as any kind of security
    • The text of the declaration must be different for each kind of certificate (see below)
  • Kind of certificate. The following kinds of certificates must be supported:
    • Bronze - successfully passed a Code Audit
    • Silver - successfully passed Phase 2 of the formal verification
    • Gold - successfully passed Phase 3 of the formal verification
    • Diamond (optional) - successfully passed Phase 4 of the formal verification
  • Name of the smart contract system
  • Unique symbol of the smart contract symbol
  • Brief description of the smart contract system
  • The original author information (optional)
  • The owner information (must be modifiable by the owner)
  • Location of the source code. The location must be publicly accepted without any restrictions, use git version control system, and be either:
    • A widely recognized storage for git repositories such as GitHub, BitBucket etc.
    • A decentralized storage system
  • Commit hash code
  • Mainnet address of the root contract (if applicable)
  • Hash code of the smart contract system (optional)
  • certificate icon - PNG format, 32x32, different for each kind of certificates

Certificate generation

  • The list of eligible certificate generators (ETG) must be maintained
  • The initial ETGs are defined at the initial contract deployment
  • In future, ETGs can be added or removed upon the decision of more than 67% of the existing ETGs
  • Any ETG can initiate the certificate generation process (using either the corresponding depot or CLI).
  • During the generation the ETG must:
    • Fill all the certificate fields
    • Assign the initial owner (supposedly, the owner of the contract system)
  • The certificate can be issued when at least 50% of ETG signed its issue
  • The payment for the deployment is a burden of the initiator ETG

Usage

  • All the fees related to the ownership and usage have to be maintained by anybody who sends funds to the root contract (presumably, by the owner)
  • The contract system is not supposed to return any change
  • Anybody must be able to retrieve any certificate data
  • Anybody must be able to find a certificate by its name or symbol
  • Nobody can somehow change the data of the certificate
  • Nobody can prevent the certificate to be found using the predefined mechanisms
  • The owner information must be modifiable

SetCode

The following “set code” capabilities must be defined:

  • Any contract of the coding system can be modified
  • To change any code at least 67% of ETG must sign the request
  • Any code changes must not prevent all the issued certificates from any kind of its functionality

Interface contracts

The following interface contracts must be implemented:

  • ETG interface contract
    • Available for ETGs only
    • Actions:
      • Initiate/sign certificate generation
      • Initiate/sign adding or removing ETGs
      • Initiate/sign code altering
    • Views:
      • See pending certificates
  • Public interface contract. Allows to:
    • Modify owner information (for owner only) (may be moved to a separate contract)
    • Get the certificate information
    • Find the certificate by name or symbol
    • Find all the issues certificates

Tests and test deployment

  • The participant must deploy its solution to any test network (dev or fld) and demonstrate passing of all the key scenarios

Contest Terms

All the participants must:

  • Present the source code at the GitHub of smart contacts, debots and supporting textual (as the Legal Disclaimer) and graphical (as the badge icons) resources according to the Requirements.
  • Present the report in PDF format that covers or, preferably, store it on-chain using the developed solution:
    • The brief description of the task
    • The architecture of the solution (including the smart contract ecosystem)
    • The highlights of the solution
    • The instructions to build, test and deploy

Any solution that does not fully conform to the requirements above will get some penalty.

Contest Dates

15 Nov 2021 - 10 Jan 2022

Proposed Prices

The total contest budget is 350 kTON, whereby 305 kTON are allocated to the contestant awards and 45 kTON are allocated to the jury reward.

The contestant awards are distributed as follows:

  • Place 1 - 100 kTON

  • Place 2 - 75 kTON

  • Place 3 - 50 kTON

  • Place 4 - 30 kTON

  • Places 5-10 - 10 kTON

  • All the awards for places 4+ are paid immediately

  • For places 1-3:

    • 55% is paid immediately
    • 15% are paid during the 3 months each month upon completion of the following conditions:
      • The participant fixes all discovered bugs
      • The participant fixes all the the textual and graphical materials provided
      • The participant gives interview to the media suggested by SG
    • If any condition mentioned above is missed the SG reserves a right to cancel the next payment without any further compensation (the refusal to pay must be approved a formal proposal)

The Jury and voting

Jury Rewards

The total budget for jury rewards is 45 kTON.

This amount shall be distributed between jurors who have voted and provided relevant 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.

1 Like