Skip to main content

๐Ÿ“ Smart Contract Guidelines

When creating a new smart contract project, use the guidelines below to ensure your project meets our basic standards of quality.

Security โ€‹

Re-entrancyโ€‹

Any external or public functions need to be analyzed to determine whether the contract can be attacked if a user re-enters that function or another.

Safe ERC20 Usageโ€‹

ERC20 token interactions should always use SafeERC20 safeApprove and safeTransferFrom in the OpenZeppelin library.

Math Overflow and Underflow โ€‹

Any math operations need to be checked for overflow and underflow conditions, using SafeMath or similar.

Trusted External Calls โ€‹

The contract should minimize trust in external calls.

Conventions โ€‹

Typed Argumentsโ€‹

All arguments, whether to an event or function, must be typed when possible. address types should be avoided in favor of contract or interface types

Logs Emitted โ€‹

Events must be emitted for any significant state change or event.

Grammar โ€‹

Names and documentation must be spelled correctly with no grammatical errors.

Documentation โ€‹

ReadMeโ€‹

A complete readme must be included with the project. It needs:

  • a complete description
  • usage
  • setup instructions
  • all test commands
  • deployment instructions and information
  • information on any additional scripts

Natspec โ€‹

Contracts must have (at minimum):

  • @title: short title. shouldn't repeat the description
  • @notice: descriptive enough so that the reader understands the intent of the contract.

Functions must have (at minimum):

  • @notice: explain what the function does
  • @param: explain each parameter
  • @return: explain the return param(s)

Events must have (at minimum):

  • @notice: describe when the event is emitted
  • @param: describe each of the args

Testing โ€‹

Code Coverageโ€‹

  • Coverage must exceed 95%
  • A coverage tag must be included in the README

Unit Tests โ€‹

  • There must be a test suite for each contract
  • Functions should be tested in isolation as much as possible
  • Unit tests must run locally; i.e. they do not connect to a remote node.

Fork Test โ€‹

  • A fork test script tests the contracts in the real world

Optimizations โ€‹

  • All external / public functions should return a value when possible (to save gas)
  • Structs must be tightly packed
  • Values that don't change should be constants