Fairmint Continuous Securities Offering

1 Summary

• Project Name: C-Org Audit
• Client Name: Fairmint
• Client Contacts: Thibauld Favre, Nick Cuso
• Lead Auditor: John Mardlin
• Co-auditors: Daniel Luca, Neil McLaren, Alexander Wade

1.1 Scope

• Repository: https://github.com/Fairmint/c-org
• Git commit hashes:
  • Initial review: 14f4e3e02b1d756d4d3caad34fbed07a9c0f09a1
  • Mitigations review: 060ea3f55aa10012831c9a0c63c61d5dd9ebf3a3
• Documentation:
  1. https://github.com/Fairmint/c-org/wiki
  2. https://github.com/c-org/whitepaper

The audit team evaluated the system’s security, resilience, and looked for unexpected behaviors relative to its specification. The audit activities can be grouped into the following three broad categories:

1. Security: Identifying security related issues within the contract.
2. Architecture: Evaluating the system architecture through the lens of established smart contract best practices.
3. Code quality: A full review of the contract source code. The primary areas of focus include:
   • Correctness
   • Readability
   • Scalability
   • Code complexity
   • Quality of test coverage

2 Timeline

Our review was split into two phases as outlined below:

2.1 Initial review

The initial review period took place from August 26, 2019 to September 9th, 2019.

During the initial review period the following Vyper files were covered:

During this period, we focused on identifying a wide range of known smart contract vulnerabilities. In addition we sought to verify that:

• The large number mathematics in BigDiv were within the acceptable error range
• The mathematics of the bonding curve model were sound
• Funds controlled by the DecentralizedAutonomousTrust, in the form of ETH, ERC20, or ERC777 could not be withdrawn by unauthorized parties.

2.2 Mitigations review

Following the initial review, as well as our subsequent security review of the Vyper compiler itself, the Fairmint team elected to rewrite the contracts in Solidity. We then performed a one-week review of the updated code from November 25th to November 29th.

During this phase we focused on verifying the following aspects of the codebase:

• the mathematics of BigDiv.sol and Sqrt.sol
• the SafeMath library was used in any situation where arithmetic operations posed a risk of overflow or underflow.

Given the very thorough test suite, and that the Solidity was a direct port from the audited Vyper implementation with very minimal modifications (mostly reduced complexity), we placed less emphasis on identifying logic errors or failure to correctly implement the specification.

3 Recommendations

During the course of our review, we made the following recommendations:

3.1 Avoid Vyper [Done]

The system was originally written in Vyper, which its own developers refer to as an “experimental language”, still in beta, and undergoing active development. During the audit process, the audit team identified and reported several bugs in the compiler. Another issue was reported by the client. Our subsequent review of the compiler itself recommended major architectural changes.

We ultimately recommended porting the code to Solidity.

3.2 Remove ERC-777 [Done]

Support 3 currency types as investment (ERC-20, ERC-777, and ETH), and 2 currency types as a security token (ERC-20, ERC-777) introduces a significant number of branches in the code and potential for logical bugs.

We recommended removing ERC-777 if not deemed absolutely necessary.

3.3 Don’t repeat yourself [Done]

_toDecimalWithPlaces (in the Vyper implementation) is tricky to reason about in the context it which it is called, which is always as part of the same series of operations designed to calculate an integer square root. It may make sense to rename it as integerSquareRoot and move some of the surrounding code into the function.

3.4 Fixes [Done]

Address issues we’ve listed with a severity of Medium or greater. For Minor issues, consider which can be addressed with minimal effort and new code.

3.5 Prepare for future compatibility with GAS repricing EIPs [Done]

Future upgrades to the opcode prices in the EVM may cause some contracts to fail. We are now recommending using raw_call.

3.6 Thoroughly document and comment BigDiv [Done]

BigDiv is a large and complex contract. Future developers and reviewers would benefit from having it much more thoroughly commented.

3.7 Review the Code Quality suggestions [Done]

Section 6 of this report compiles suggestions which do not pose a direct threat to security, but would otherwise improve the quality of the code. Those suggestions should be considered.

3.8 Considerations for Upgradability

When deployed with proxies as planned, the contract logic could theoretically be re-written to confiscate currency and tokens arbitrarily.

When deployed without proxies, the Ethereum accounts DAC.control and ERC1404.owner both have the ability to lock (but not confiscate) user funds indefinitely.

We recommend having a documented and well tested process for upgrading the contract logic by changing the configuration of each proxy. The testing should include checks that the contract’s storage layout is backwards compatible with previous versions.

4 Security Specification

This section describes, from a security perspective, the expected behavior of the system under audit. It is not a substitute for documentation. The purpose of this section is to identify specific security properties that were validated by the audit team.

4.1 Actors

The relevant actors are as follows:

• Beneficiary / C-Org: Deploys and initializes the DAT, FAIR, and BigDiv contracts. If the beneficiary address buys into the DAT via buy, all funds sent are directed to the DAT’s buyback reserve. The beneficiary is expected to direct some portion of revenue through the DAT contract, in order to reward FAIR holders.
• DAT Controller: This is initially the C-Org itself, but is updateable (by the C-Org) to any nonzero address. The control address can, at any time, change several properties in both the DAT and FAIR contracts (see details in Trust Model).
• Investor: The investor buys into the DAT through its buy function. In return, they receive FAIR tokens. A portion of their purchase goes to the DAT’s buyback reserve.
• Customer: Customers can pay the C-Org via the DAT’s pay function. A portion of payment is sent to the buyback reserve, and the rest is sent to the beneficiary address.

4.2 Trust Model

In any smart contract system, it’s important to identify what trust is expected/required between various actors. For this audit, we established the following trust model:

• The beneficiary is represented by a single address. If this address is a multisig, it is expected that this multisig correctly handles interactions with the DAT contract system. If this address is an EOA, it is expected that the account’s private key is not compromised.
• The beneficiary is expected not to use a different address to buy FAIR from the DAT.
• The control address can change several properties at any time:
  • The ERC1404 address, which may hold important transfer restrictions, is expected to implement restrictions in line with investor expectations.
  • The beneficiary address, which represents the entire C-Org on-chain, is expected to effectively represent the organization.
  • The control address, which can change these properties, is expected to be used in a manner according to investor expectations.
  • The fee collection address, which receives fees from investment into the DAT, is expected not to revert. If the fee collection address reverts when it receives Ether, investors will be unable to buy into the DAT.
  • The fee basis points are expected to remain consistent with investor expectation, given that a fee basis equal to 10000 will result in the entire buyback reserve being sent to the fee collection address on DAT buy-in.
  • The minimum investment amount is expected to remain consistent with investor expectations.
  • The time until the DAT can be closed (openUntilAtLeast) is expected to remain consistent with investor expectations.

5 Verification of Custom Properties

5.1 Custom properties

The following properties were specifically verified using automated techniques.

5.2 Verification Methods

• Sqrt.sol: In order to verify the math in Sqrt.sol, we created two custom checks using Solidity’s assert() function. Using the MythX security analysis engine, we then verified that the code could not be executed in such as away as to invalidate the assert statements.
• BigDiv.sol: In order to verify the math in BigDiv.sol, we used a method closer to ‘brute force verification’.
  1. We defined a large array of input numbers, including potentially interesting values.
  2. We then ran a test for all possible combinations of numbers. The test compared the value returned by the BigDiv methods with the value as calculated with decimal math using bigNumber.js. The test passes if the two values are within 0.000001%.
  3. This method was subsequently expanded to include even more input numbers, giving us high confidence in the correctness

6 Issues

Each issue has an assigned severity:

• Minor issues are subjective in nature. They are typically suggestions around best practices or readability. Code maintainers should use their own judgment as to whether to address such issues.
• Medium issues are objective in nature but are not security vulnerabilities. These should be addressed unless there is a clear reason not to.
• Major issues are security vulnerabilities that may not be directly exploitable or may require certain conditions in order to be exploited. All major issues should be addressed.
• Critical issues are directly exploitable security vulnerabilities that need to be fixed.

tokenValue: uint256 = self.estimateBuyValue(_currencyValue)

if(self.isCurrencyERC777):
  self.currency.operatorSend(_from, self, _quantityToInvest, "", "")

self.fair.mint(msg.sender, _to, tokenValue, "", "")

a='340282366920938463463374607431768211455'
b='340282366920938463463374607431768211457'
BigDiv.bigDiv2x1(a, b, '1', false) -- ???

a='340282366920938463463374607431768211456'
BigDiv.bigDiv2x1(a, a, a, false) -- overflows, despite result being ~sqrt(MAX_INT)

if(factor == 0):
  factor = 1

# Math: Truncates last 18 digits from tokenValue here
tokenValue /= DIGITS_UINT

# Math: Truncates another 8 digits from tokenValue (losing 26 digits in total)
# This will cause small values to round to 0 tokens for the payment (the payment is still accepted)
# Math: Max supported tokenValue is 1.7e+56. If supply is at the hard-cap tokenValue would be 1e38, leaving room
# for a _currencyValue up to 1.7e33 (or 1.7e15 after decimals)
decimalValue: decimal = self._toDecimalWithPlaces(tokenValue)

decimalValue = sqrt(decimalValue)

# Unshift results
# Math: decimalValue has a max value of 2^127 - 1 which after sqrt can always be multiplied
# here without overflow
decimalValue *= DIGITS_DECIMAL

tokenValue = convert(decimalValue, uint256)

@public
@constant
def simpleDiv(
  _numA: uint256,
  _numB: uint256,
  _den: uint256
) -> uint256:
  return _numA * _numB / _den

a='1'
b='99993402823669209384634633746074317682114579999'
BigDiv.bigDiv2x1(a, b, '8', false) -- succeeds, approximate answer
simpleDiv(a, b, '8')               -- succeeds, exact answer

if(MAX_UINT256 / _numA > _numB):
    # No rounding required. Return exact result
    return _numA * _numB / _den

@public
def transferFrom(
  _from: address,
  _to: address,
  _value: uint256
) -> bool:
  """
  @notice Transfers `_value` amount of tokens from address `_from` to address `_to` if authorized.
  """
  self.allowances[_from][msg.sender] -= _value
  self._send(msg.sender, _from, _to, _value, False, "", "")
  log.Approval(_from, msg.sender, self.allowances[_from][msg.sender])
  return True

log.Approval(_from, msg.sender, self.allowances[_from][msg.sender])

elif(self.state == STATE_RUN):
  if(_to != self.beneficiary):
    self._distributeInvestment(_currencyValue)

self.fair.mint(msg.sender, _to, tokenValue, "", "")

if(self.state == STATE_RUN):
  if(_to == self.beneficiary):
    self._applyBurnThreshold() # must mint before this call

7 Code quality recommendations

This sections compiles suggestions which do not pose a direct threat to security, but would otherwise improve the quality of the code.

7.1 DecentralizedAutonomousTrust.sol

The method _authorizeTransfer could be rewritten as a modifier, if desired.

7.2 Whitelist.sol

The argument _isSell is not used in the method authorizeTransfer().

7.3 Sqrt.sol

SafeMath.sol is imported to Sqrt.sol, but is not used.

8 Gas efficiency optimization recommendations

8.1 DecentralizedAutonomousTrust.sol

The BigDiv.sol and Sqrt.sol contracts are deployed separately and their methods are accessed as external calls. This is more expensive than accessing the functions as libraries. Ie. library BigDiv and using BigDiv for uint.

Appendix 1 - Disclosure

ConsenSys Diligence (“CD”) typically receives compensation from one or more clients (the “Clients”) for performing the analysis contained in these reports (the “Reports”). The Reports may be distributed through other means, including via ConsenSys publications and other distributions.

The Reports are not an endorsement or indictment of any particular project or team, and the Reports do not guarantee the security of any particular project. This Report does not consider, and should not be interpreted as considering or having any bearing on, the potential economics of a token, token sale or any other product, service or other asset. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty. No Report provides any warranty or representation to any Third-Party in any respect, including regarding the bugfree nature of code, the business model or proprietors of any such business model, and the legal compliance of any such business. No third party should rely on the Reports in any way, including for the purpose of making any decisions to buy or sell any token, product, service or other asset. Specifically, for the avoidance of doubt, this Report does not constitute investment advice, is not intended to be relied upon as investment advice, is not an endorsement of this project or team, and it is not a guarantee as to the absolute security of the project. CD owes no duty to any Third-Party by virtue of publishing these Reports.

PURPOSE OF REPORTS The Reports and the analysis described therein are created solely for Clients and published with their consent. The scope of our review is limited to a review of Solidity code and only the Solidity code we note as being within the scope of our review within this report. The Solidity language itself remains under development and is subject to unknown risks and flaws. The review does not extend to the compiler layer, or any other areas beyond Solidity that could present security risks. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty.

CD makes the Reports available to parties other than the Clients (i.e., “third parties”) – on its website. CD hopes that by making these analyses publicly available, it can help the blockchain ecosystem develop technical best practices in this rapidly evolving area of innovation.

LINKS TO OTHER WEB SITES FROM THIS WEB SITE You may, through hypertext or other computer links, gain access to web sites operated by persons other than ConsenSys and CD. Such hyperlinks are provided for your reference and convenience only, and are the exclusive responsibility of such web sites’ owners. You agree that ConsenSys and CD are not responsible for the content or operation of such Web sites, and that ConsenSys and CD shall have no liability to you or any other person or entity for the use of third party Web sites. Except as described below, a hyperlink from this web Site to another web site does not imply or mean that ConsenSys and CD endorses the content on that Web site or the operator or operations of that site. You are solely responsible for determining the extent to which you may use any content at any other web sites to which you link from the Reports. ConsenSys and CD assumes no responsibility for the use of third party software on the Web Site and shall have no liability whatsoever to any person or entity for the accuracy or completeness of any outcome generated by such software.

TIMELINESS OF CONTENT The content contained in the Reports is current as of the date appearing on the Report and is subject to change without notice. Unless indicated otherwise, by ConsenSys and CD.