Audit Standards for Social Smart Contracts

Overview

Ensuring the security of smart contracts is key to ensuring the security of user-owned assets. As asset security is the biggest consideration for most DeFi-related platforms and applications, security audits on smart contracts mainly take place within this field. As smart contract technology continues to improve, however, the use cases for smart contract audits are gradually expanding to other areas, including social platforms.

The use of smart contracts allows for new frontiers of social interaction to develop. It also allows for new methods of ensuring safety and trust to be innovated, something of vital importance to social platforms that rely on the trust they build among users to succeed. Clover's new set of auditing standards is specifically designed for the implementation of smart contracts within the social sphere. These standards aim to ensure that smart contracts deployed on our protocols guarantee both asset security and social trust among users.Specifically, the introduction of these auditing standards provides for:

• Comprehensive Audits: We ensure that the audit covers the entire process from the source code to the final audit report, checking that the audit does not omit any vital information.

• Establishment of Social Trust Mechanisms: Special considerations are taken during the audit process to ensure the security of social interactions, providing users with a more secure, transparent, and trustworthy social environment in which to interact.

• Security in User Interactions: Social functions implemented through these smart contracts are not only secure but also promote healthy socializing between users.

This provides users with an interactive social platform that uses secure smart contracts to establish trust within a social organization or social scenario. With this usage, smart contract technology will be more widely accepted and adopted by social applications and platforms, giving users an ever-richer social experience.

Basic Concepts

• Contract Initiator: The individual or organization that develops a smart contract.

• Auditor: The individual or organization that provides contract auditing services.

• On-chain Contracts: Smart contracts that are deployed to the blockchain.

• Applications: The parties providing services that allow for contract interactions.

The Audit Process

After a smart contract is published, the auditable information must be disclosed to all parties so that each party can inform themselves of any potential risks and provide any necessary safety assurances.

• Before the contract initiator formally submits a contract for auditing, they may communicate with the auditor offline to ensure the audit is conducted efficiently.

• The contract initiator must first deploy the contract and then submit the source code of the deployed contract to the auditor for review.

• After the audit has been completed, the auditor can update the audit status through the audit information interface to alert the contract initiator to the results or feedback of the audit.

• The contract initiator can then decide whether they would like to publish the contract to users.

• The hosting application can read the auditable information and the audit status that is attached to the contract and disclose the information it contains to the users.

Auditing Standards

It is important to provide users with a safe and reliable contract environment within their specific social scenarios. Unlike traditional DeFi applications whose targets are native Web3 users, social scenarios are designed to be spread outside of this environment, and these social contracts may reach those who have little knowledge of basic Web3 principles, leading to two possible situations:

• Users may lack awareness of basic security practices, and this naïveté may lead to unnecessary asset losses.

• Users unfamiliar with Web3 concepts may be overly cautious and refuse to participate in that social scenario, shrinking the potential userbase.

Providing users with detailed and reliable audit information is essential to eliminating these unnecessary risks.

Content of the Audit

Auditing smart contracts should not be limited to reviewing financial security within traditional Web3 DeFi applications. Expanding this practice to more diverse and comprehensive domains like social interactions safeguards social organizations and provides needed transparency and efficiency. The following points detail how this works within social scenarios:

• Contract Security: Similar to DeFi security reviews, social smart contract audits also need to emphasize asset security. This includes the use of encryption measures, testing for smart contract vulnerabilities, preventing other security vulnerabilities, and protecting user asset rights from being infringed.

• Accordance Between Contract Content and Execution: The audit must compare the intended use of the contract as declared by the contract initiator with the actual execution of that contract. This process requires a careful review of a contract's logic to ensure its behavior is consistent with the initiator's statement and that nothing was concealed or meant to mislead.

• Identity Verification of the Contract Initiator: Within a social scenario, those who initiate an interaction or a contract first are often at an advantage. Verifying the identity of the initiator is critical to reducing fraud and protecting the interests of all participating parties.

• Identity Verification of Other Affiliated Parties: In any social interaction, the verification of all participating parties' information is equally important in reducing fraud and protecting the interests of all participating parties.

• Identity Verification of the Beneficiary: Ensuring the identity and authenticity of the beneficiary is also important in protecting the interests of participating parties. A strict review of the beneficiary's identity is required during the audit process to avoid losses caused by malicious information.

Through meticulous audits, the Clover protocols aim to build a robust environment for social interaction that is safe and credible, with the knowledge that a healthy social ecosystem will boost user participation.

Audit Status

• The contract security level determines whether there are exploitable security vulnerabilities in the contract. This standard of evaluation has five levels of risk:

Security Level	Description
Critical	Impacts the safe functioning of a contract
Major	Logical errors that can lead to a loss of user funds or contract control
Medium	Affects performance or reliability
Minor	Inefficient code that does not put security at risk
Informational	Related to style or industry best practices

• The consistency designation rates the contract's code on its consistency with the information given by the initiator. This can return 4 states:

Consistency Designation	Description
Unclear	If the description is vague or lacks detail, it is impossible to determine if the implementation matches the intended functionality.
Ambiguous	The description is clear to some extent but leaves room for multiple interpretations that can lead to different implementations.
Inconsistent	There is a discrepancy between what is described and what is implemented, meaning the actual behavior does not match the described expected behavior.
Consistent	This indicates that the description and the implementation are aligned, and the actual behavior of the contract matches the described functionality.

• Verification Status of the Initiator and Affiliated Party Information:

Verification Status of Initiator	Description
Unverified	This indicates that the information has not undergone any verification process. It suggests uncertainty regarding the authenticity of the information provided by the initiator.
Verified	This indicates that the information has been checked and has been confirmed to be accurate. Verification processes have been applied to ensure the initiator's or affiliated party's identity matches the provided details.
Invalid	This indicates that the information has undergone the verification process but has been found to be incorrect, fabricated, or does not meet the required standards. It suggests that the information provided does not accurately represent the initiator's or affiliated party's identity.
Expired	Verified information may have a validity period. "Expired" means that the information was once verified, but the verification is no longer valid due to expiration or changes to the verification criteria.

• Verification of Beneficiary Information: The auditor needs to confirm that the beneficiary is consistent with the contract claimant. This can return 3 states:

Verification Status of Beneficiary	Description
Unverified	The auditor cannot confirm the accuracy of the beneficiary information. This state suggests that there is insufficient evidence or data to ascertain the accuracy of the stated beneficiary.
MutableVerified	The beneficiary information has been verified, but the contract initiator retains the ability to alter it. This indicates a level of control by the contract initiator over the beneficiary details even after initial verification.
ImmutableVerified	The beneficiary information is confirmed, and once the contract is deployed, the initiator cannot modify it. This state suggests a permanent, immutable record of beneficiary information post deployment.

Application Disclosure Obligations

Applications that publish contracts or allow contract interactions are obliged to disclose auditable information to users and provide users with an easy way to read specific audit reports.

The following are the standards for information disclosure:

Interface Display Status	Display Convention	Description
Low or No Risk	Green	Security Level: Informational or Minor Consistency Designation: Consistent Verification Status of Initiator: Verified Verification Status of Beneficiary: ImmutableVerified
Medium Risk	A neon orange that reminds users of danger	Security Level: Informational or Minor Consistency Designation: Consistent Verification Status of Initiator: Verified Verification Status of Beneficiary: MutableVerified
High Risk	A bright red that tells users to avoid interaction	Statuses not adjudged to be no, low, or medium risk

• A link to the audit results must be included.

Descriptions of the Interface

To support the audit process, the smart contract must implement methods by which auditable information can be obtained and updated:

Method	Description
title()	Contract Name
description()	Description that explains the logic and intent of the contract, which allows the auditor to determine its consistency with the actual execution. It needs to include the beneficiary, beneficiary logic, etc.
codeInfo()	Returns information about the source code submitted for audit, including the hash and version.
updateAuditInfo()	A method by which auditors may update audit information.
auditInfo()	Returned Audit Information: Audit Status Security Level Consistency Designation Verification Status of the Initiator Verification Status of Affiliated Parties Verification Status of the Beneficiary Hash of Audited Code Audit Time Auditor Signature Auditor Name Address of Audit Report

The following is the interface file written in Solidity:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

interface IContractAudit {
    // Structure to hold code information
    struct CodeInfo {
        string codeHash;
        string codeVersion;
    }

    // Structure to hold audit information
    struct AuditInfo {
        string securityStatus;
        string consistencyStatus;
        string initiatorStatus;
        string affiliatedStatus;
        string beneficiaryStatus;
        string auditorSignature;
        string auditReporterLink;
        address auditor;
        uint256 auditTimestamp;
        string auditCodeHash;
    }

    /**
     * @dev Returns the title of the contract.
     */
    function title() external view returns (string memory);

    /**
     * @dev Returns a brief description of the contract, including its business logic, goals, beneficiaries, and profit logic.
     */
    function description() external view returns (string memory);

    /**
     * @dev Returns code information including the source code hash and version.
     */
    function codeInfo() external view returns (CodeInfo memory);

    /**
     * @dev Allows the auditor to update audit information. This function should have restrictions to be called only by auditors.
     */
    function updateAuditInfo(AuditInfo calldata auditInfo) external;

    /**
     * @dev Retrieves the audit information including security level, consistency designation, beneficiary status, auditor's signature, auditor's address, audit timestamp, and audit code hash.
     */
    function auditInfo() external view returns (AuditInfo memory);
}