AragonBlack Fundraising

1 Summary

ConsenSys Diligence conducted a security audit on Aragon Fundraising, previously known as Apiary, an application based on the AragonOS framework to facilitate emergent organizations to conduct (bonding curve) fundraising campaigns and provides accountability throughout the lifecycle of a project.

• Project Name: AragonBlack Fundraising
• Client Name: Aragon Black & The Aragon Association
• Client Contact: Olivier Sarrouy (@osarrouy), Louis Giraux (@LouisGrx)
• Lead Auditor: Martin Ortner (@tintinweb)
• Co-auditors: Sergii Kravchenko
• Date: 25 Nov 2019
• Commit Hash: #5ad1332
• Repository: github/AragonBlack/fundraising

2 Audit Scope

This audit covered the following files:

The audit also includes the interaction with relevant parts of the AragonOS Framework (Kernel, ACL and Core DAO components used, as well as, Aragon Applications Vault, TokenManager, Voting, Finance, Agent).

Besides contracts that mock functionality or are solely used for testing purposes it was agreed that the following components are out of scope:

It was also verified that the logic of the 3rd party components were left unchanged (Reference: BancorFormula.sol, IBancorFormula.sol, SafeMath.sol, Utils.sol). The system uses BancorFormula v0.3 while the newer version BancorFormula v4 is already available.

The system implements a granular role-based permission model. While permissions can be assigned to any entity, the audit assumes the trust model established with the set of permissions described with the provided FundraisingMultisigTemplate.sol.

2.1 Documentation

The following documentation was available to the audit team:

• Introduction: Aragon Fundraising
• Aragon Documentation
• Inline Code Documentation and Comments

The audit team evaluated that the system is secure, resilient, and working according to its specifications. 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

3 System Overview

AragonBlack Fundraising is an Aragon Application that implements a fundraising system capable of accepting multiple ERC20 compliant tokens or ETH as collateral. Individuals can participate in a fundraising campaign by contributing to a presale phase or by trading collateral for bonding token. Owning bonding token (Shareholder Token) gives individuals voting power in the DAO Shareholder Voting Application but DAO Shareholder can only vote on Board member proposals, they cannot create votings themselves. The bonding token market is governed by a BancorFormula based bonding curve market maker. Buy and sell orders have fees attached that are transferred to a beneficiary in the system. Bonding tokens can be sold at any time.

Raised collateral is transferred to the fundraising Reserve where it can later be withdrawn by the Board/Project Team. Withdrawal by Board members/the Project Team is controlled by a Tap contract that limits the number of tokens that can be withdrawn for each whitelisted collateral per time unit. The tap is a control mechanism and incentive for the project team to continuously delivery project milestones in return for funding. The monthly tap amount the Project Team can withdraw is controlled by the Shareholders via the monthly tap increase rate.

The fundraising application is built from five individual Aragon Applications that are described in more detail in the next sections.

• AragonFundraisingController
• Presale
• BatchedBancorMarketMaker and BancorFormula
• Tap
• Reserve

The system requires and interacts with the following Aragon default applications: Voting, Finance, TokenManage, Vault, Agent.

3.1 Detailed Design

This section describes the top-level contracts, their inheritance structure, actors, permissions and contract interactions.

Inheritance Structure

Call Graph

Components

The following graphic depicts the main contracts and their interfaces, actors and high-level interactions with the fundraising application. Aragon default Applications like Vault, Agent, and TokenManager have been left out for simplification. Actors were based on the FundraisingMultisigTemplate which operates in a company-board like DAO scenario with Board members (every member has the same voting power; tokens are not transferable) and Shareholders (voting power per account not limited; token transferable). Most of the contracts state-changing functionality is authenticated. However, contributing, buying or selling collaterals and token in the system is unrestricted. Anyone can participate in the fundraising without and there is no functionality to whitelist approved accounts. The main point of interaction is the AragonFundraisingController which serves as a stable API to the system. Potential investors interact with this contract to deposit collateral in return for stake in the DAO as a Shareholder (NewTokenHolder). All decisions are steered by the Board and Board members can reach consensus to appoint other users as new Board members. Most of the decisions and especially the critical ones (Kernel, ACL, …) require approval by Shareholders. Shareholders cannot create votes themselves and require at least one Board member to create a vote. This also means that if the Board turns rogue, Shareholders need at least one honest Board member to propose countermeasures they can vote on. Some components specify a beneficiary that receives token from the presale, fees from token exchange in the market maker and tapped funds from the fundraising campaigns vault. The beneficiary can be the DAO Board members Vault (as specified in the FundraisingMultisigTemplate). Shareholders do not have access to this vault. Fundraising collaterals are stored in a Reserve, which is a default Aragon Agent application (Agent is a Vault). Market making is done via the BancorFormula in BatchedBancorMarketMaker.

Please refer to section 5 - Security Specification for a security-centric view on the system.

AragonFundraisingController

The external interface of the application and the main entry point for interaction with the system. The contract provides a stable API to the fundraising application and allows individuals to contribute to fundraising campaigns (presale, token market). It allows Board members and Stakeholder to change parameters or perform actions and interacts with the four main back-end components: Presale, BatchedBancorMarketMaker, Tap, Reserve.

Presale

Allows the Project Team/Board to start the Fundraising Campaign with a time-limited token presale that sells token at a fixed rate with configurable token vesting for contributors. The presale can only be started once.

BatchedBancorMarketMaker

Implements the Shareholder token market logic based on the 3rd party BancorFormula and the fee economics. It is an AragonApp that is acting as the market making contract for token transfers and facilitates the buying and selling of bonding tokens investors receive for their investments. The contract interfaces with the BancorFormula and is critical to the system. It also collects fees and transfers the invested token or ETH to the pool or fee recipient.

BancorFormula

BancorFormula.sol is the implementation of the Bancor bonding curve formula.

Tap

Limits the amount of collaterals the Board can withdraw from the Reserve.

Reserve (Agent)

Sometimes referred to as Pool, is an Aragon Agent application that acts as a value store for raised collateral and can be used to interact with other entities. The Agent application inherits the Aragon Vault application and was recently updated with SAFE_EXECUTE and the possibility to add/remove tokens that are protected by this method. SAFE_EXECUTE allows to call other contracts on behalf of the reserve and ensures that protected token balances cannot change during safe_execute calls. Neither Board nor Shareholders have direct access to the funds stored in the Reserve.

Actors

There are three main groups of actors in the AragonBlack Fundraising system:

• FundraisingMultisigTemplate - A DAO deployer can interact with the template to deploy a new fundraising DAO. The template initially has permissions to configure the DAO but transfers all ownership in the final step of the deployment. The template contract should not remain in control of the DAO after its deployment. Initial configuration of the template contract must be verified before interacting with it.
• The DAO deployer - A user that interacts with the template contract to deploy a new DAO. This user should not directly remain in control of any of the deployed DAO components.
• Board members - Also known as the fundraising Project Managers. The board controls the DAO but can only propose changes to the Stakeholders. Stakeholders have to approve the changes. The board may have its Vault that is managed by a Finance application. Funds can only be withdrawn from this Vault via Board vote. Board members can also tap into the fundraising campaigns Reserve but this access and the allowed withdrawal amount for collateral is restricted by the fundraising Tap contract.
• Beneficiary - Usually a Vault managed by the Board. Receives initial tokens from the presale, trading fees from the MarketMaker and funds withdrawn from the reserve.
• Shareholders - Are the investors in the fundraising DAO. They are a control instance that approves changes or actions proposed by Board members.
• Any Ethereum Account - With the current permission setup deployed with the provided DAO template anyone can participate in the token presale to receive vested tokens or buy tokens from the bonding curve based batched market maker. Buying tokens gives voting power in the DAO and turns the Account into a Shareholder. However, the permissions can also be assigned to a KYC provider that whitelists investors in the future.

Security focussed information about actors in this system can be found in section 5 - Security Specification/Actors.

3.2 FundraisingMultisigTemplate

The fundraising DAO template is based on the Company-Board default DAO-Template. We have also audited this default DAO-Template as part of the Aragon DAO-Templates Audit, please refer to this report for general security information. A security analysis of the template is provided as part of section 5 - Security Specification.

The template is well structured and aligned with the coding style of the Aragon default DAO-Templates. Wherever possible it makes use of functionality provided by the Aragon BaseTemplate which is part of the Aragon default DAO-Templates repository. New fundraising enabled DAOs can be deployed in four steps:

1. prepareInstance

• creates a new DAO
• creates the BOARD token
• installs Board apps (TokenManager, Voting, Vault (beneficiary), Finance)
• mints one BOARD token per member for the initial group of board members
• cache the DAO and apps for the multi-step deployment approach

2. installShareApps

• creates the SHARE token
• installs Share apps (TokenManager, Voting)
• sets up board permissions (TokenManager, Voting, Vault, Finance)
• caches newly installed apps
• installFundraisingApps
  • installs fundraising applications (Presale, MarketMaker, Tap, Controller)
  • sets up share permissions (TokenManager, Voting)
  • sets up fundraising permissions (Reserve, Presale, MarketMaker, Tap, Controller)
• finalizeInstance
  • sets up initial collaterals (DAI as protected and tapped token, ANT as protected collateral but not as a tapped token, ETH is not whitelisted by default)
  • sets up EvmScriptRegistryPermission
  • transfers root permissions from template to Voting_Share
  • registers application id
  • clears the cache

The DAOFactory, ENS Registry, MiniMeTokenFactory, aragonID, and the DAI and ANT token contract addresses are specified when deploying the template contract. Users should make sure the initial configuration of the template is safe (no malicious factory or collateral token contracts) when using a 3rd party template contract to deploy a new DAO.

A visual representation of the permission setup deployed with the DAO can be found in section 5 - Security Specification.

Inheritance Structure

Call Graph

4 Key Observations/Recommendations

• The Aragon Applications and the Template are well structured, following Aragon design specifications and coding style. This greatly improves code readability, maintainability, security and is effectively reducing effort to review the application and template. The template relies on functionality to set up a new DAO provided with the DAO-Templates repository instead of inventing new mechanisms. Both the template and the application code itself are good examples of a coding style that supports maintainability and security.

• The project team provided system documentation and auditable specification documents. It is typically suggested to make documentation available that clearly outlines at least the following information:

  • Application Name, Version and Outline - is available
  • Roles & Capabilities ideally grouped into logical actors (e.g. Investors, Project Managers, …) - is available
  • Set-Up and initialization details - is available
  • Caveats & Limitations - can be improved
  • Security Considerations, Common Pitfalls or Secure Setup information - can be improved
  • A description of an example Application Lifecycle - can be improved
  • A reference to an example kit to deploy the Aragon Black Fundraising application with a DAO - template is available

• Scripts to bootstrap the repository and compile & run test suites are provided with the project.

• Security best practices are followed where they make sense.

• Common design patterns are used where required instead of inventing new interfaces and designs.

• 3rd party modules (BancorFormula and its components) have not been logically modified.

• Arithmetic operations are performed using SafeMath in most cases where it makes sense.

• Staticcalls are enforced for ERC20.balance calls.

• Smart contracts are following the Unix design philosophy as recommended by Aragon. Contracts are split into logical building-blocks.

• Inline documentation for contracts and exposed methods are available and outline the functionality and expected input parameters.

• The application relies on AragonOS framework functionality and is following the Aragon application development guide.

• Exposed functionality is protected with the AragonOS framework ACL system creating a fine-grained role system that can be customized by DAO’s.

• Critical functionality of MarketMaker and Presale is protected from reentrancy.

• The application is set to compile with an outdated solidity version lacking the latest security improvements. The solidity version cannot easily be changed as it is dictated by the underlying AragonOS framework.

• The AragonFundraisingController’s purpose is to forward and keep in sync other contracts. This forces it to be in sync with all of the other contracts it interacts with, effectively writing a lot of boilerplate to serve as the interface for the whole application. This is a problem because if some functionality is added or removed in any of the market maker, reserve or tap contracts, the controller needs to be updated. Another different way is to remove the controller altogether and have the web interface call the right contract for each functionality. For the methods that keep the collateral tokens (addCollateralToken) and the beneficiary (updateBeneficiary) in sync, a different contract can be used as a ledger having the collateral token list and the beneficiary available (or even split in 2 contracts: one ledger for collateral tokens and the other for the beneficiary); each of the contracts (market maker, reserve and tap) will be able to retrieve the list of collateral tokens or the beneficiary. Managing the collateral tokens or the beneficiary will be done directly in these contracts.

• The authentication system could be changed from auth() to authP() allowing to set rules on the method parameters. Please note that this might increase complexity and must be complemented with unit-tests accordingly.

• The price of the Shareholder tokens gets lower with every second because of the Tap withdrawal allowance increasing with the same rate, which decreases the pool balance that is used for the Share token price calculation.

• The project does not yield any security-relevant compiler warnings in scope for this audit.

• The test-suite passes without failing test-cases.

• Test coverage is not complete and failed to generate coverage statistics for the Presale contract. The GitHub/AragonBlack: CI Integration does not collect coverage statistics for Presale. Any contract system that is used on the Mainnet should have as a minimum requirement a 100% test coverage. In particular, it’s useful to include negative test cases ensuring that undesirable changes are detected early and kept in-line with the specification. Security-focused test cases verifying that permissions are set-up according to the security-specification and trust-model should be consistently implemented. Methods that require special permissions must be tightly covered. None of the contracts that comprise the contract system should be exempt from testing/coverage. For details see section Test Coverage Measurement.

5 Security Specification

This section describes the behavior of the system under audit from a security perspective. It is best combined with the overview given in section 3 - Components. Please note that this document is not a substitute for documentation. The purpose of this section is to identify specific security properties that were validated by the audit team. Furthermore, the information contained in this section can be used for internal security activities and we recommend documenting and building-upon the trust model that has been established.

5.1 Actors

The relevant actors are as follows:

• FundraisingMultisigTemplate
• The DAO deployer
• Board members
• Beneficiary
• Shareholders
• Any Ethereum Account

5.2 Components

• Voting Board - Any Board member can create votings on the Shareholder voting application. Board consensus but no Shareholder approval is required to open the presale or spend funds from the Board Vault.
• Voting Shareholder - Critical permissions are assigned to the Shareholder voting application. An entity that controls the Shareholder voting application (e.g. whales with enough stake to control the vote quorum/support) and colludes with one Board member may be able to configure critical parameters of the fundraising application (whitelisted tokens, tap amount, tap increase rate, granting and revoking permissions, managing applications for the DAO). The Shareholders cannot initiate a votings themselves.
• DAO Kernel - Board members rely on Shareholder approval to manage the DAO applications and permissions.
• FundraisingController - Main point of interaction that owns critical roles with the fundraising applications components.
• Reserve - Fundraising value store (ETH and whitelisted collateral tokens).
• Tap - Controls funds stored in Reserve.
• Presale - Initial value store for contributions in the presale phase. Value gets transferred to beneficiary/reserve when presale goal is reached and presale is closed. Mints Shareholder token.
• MarketMaker and BancorFormula - Define exchange rates, prices, and fees. Mints Shareholder token.
• Beneficiary - Board/Project Team value store. Usually, an Aragon Vault application but can be any account.

5.3 Trust Model

The trust model and security observations aim to bring transparency about security-relevant characteristics of the system, help to understand trust assumptions and describe potential high-level threats to the system. The goal is to spark security discussions, document them as part of a continuous process and use them as input for internal SDL security practices.

It is based on the permission setup provided with the FundraisingMultisigTemplate. The audit team would like to note that the system can be deployed with various configurations. Other templates (DAO scenarios) than the one audited as part of this work might not enforce secure defaults or a safe permission setup.

Deployment

Before the Fundraising DAO can be used it has to be deployed using a template contract. This template contract can be provided by Aragon or third parties. We would like to emphasize that both the template contract code and its initial configuration as well as its dependencies (especially Factory Contracts) must be verified and should be audited. The template contract nor factory contracts or a third party should remain in control of any of the newly deployed DAOs components.

• The FundraisingMultisigTemplate can be deployed by anyone. The template deployer does not remain in direct control of the template but it can be indirectly controlled via the templates default configuration and factories being used (e.g. DAOFactory, MiniMeFactory, TokenContracts).

• The DAO deployer is an account that interacts with the FundraisingMultisigTemplate to deploy a new DAO. It is initiating the four DAO deployment steps outlined in section 3 - System Overview.

• In the course of the deployment of a DAO, permissions are assigned to the FundraisingMultisigTemplate. For example, _createDAO initially assigns Kernell.APP_MANAGER_ROLE and Acl.CREATE_PERMISSIONS_ROLE to the template. When minting tokens BaseTemplate._mintTokens() temporarily assigns the TokenManager.MINT_ROLE to itself and removes the permission after the tokens have been minted. The FundraisingMultisigTemplate temporarily assigns Controller.ADD_COLLATERAL_TOKEN_ROLE to itself and transfers this permission to Voting_Share after whitelisting DAI and ANT as collateral. When finalizing the new DAO the FundraisingMultisigTemplate transfers Kernell.APP_MANAGER_ROLE and Acl.CREATE_PERMISSIONS_ROLE to Voting_Share effectively revoking its access from the newly deployed DAO.

• The DAO deployer is not granted any permissions during the deployment of the new DAO but it is in control of configuration options and the initial set of Board members. DAO users must verify the configuration settings of the newly deployed DAO before participating in it.

• An initial group of Board members is assigned to the DAO by the DAO deployer.

• The Board Vault is initially set as the Beneficiary for fees, presale tokens and tap withdrawal by the FundraisingMultisigTemplate.

Presale

The fundraising campaign is preceded by a presale phase. With the scenario deployed by the FundraisingMultisigTemplate this step is mandatory and reaching the presale goal ultimately enables investors to buy or sell tokens from the MarketMaker contract. If the presale fails the fundraising DAO can only be abandoned, contributors are requested to withdraw their contributions directly from the presale contract. The presale contract is a value store and keeps funds until the goal is reached. Reaching the goal splits contributions to an amount initially assigned to the beneficiary with the rest being transferred to the fundraising reserve.

The following two images depict the presale stages and the timing configuration including the token vesting.

The presale proceeds in the following stages:

• PENDING - The presale is not yet open. Contributions are not yet accepted.
• FUNDING - The presale is open. Contributions are accepted.
• REFUNDING - The presale duration ended but the goal has not been reached. Contributors can claim a refund.
• GOAL REACHED - The presale duration ended and the goal has been reached. Waiting for someone to close the presale.
• CLOSED - The presale has reached its goal and it has been closed by someone, transferring a number of tokens to the beneficiary (Board Vault) and the rest to the Fundraising reserve. Shareholder tokens are minted and assigned vested to contributors. Trading with the MarketMaker is finally opened.

The following properties have been identified:

• The initial presale configuration is critical, set by the DAO deployer and must be verified by participants before contributing to a presale. For example, the DAO deployer may initially configure the presale to transfer 100% of contributed token to the Beneficiary account instead of providing it as collateral to the reserve. This will give the Board direct control over the funds instead of withdrawals being restricted by the Tap contract.

• The presale phase can be set to open at a specific date or when opening it manually. Reaching the presale goal opens trading with the Fundraising MarketMaker.

• When the presale is in GOAL_REACHED state it can be closed by anyone making sure funds cannot be stuck waiting for an administrator to close it.

• Anyone can contribute to the presale via Controller (CONTRIBUTE_ROLE).

• Refunds must be claimed directly from the presale contract.

• Shareholder tokens are minted when processing the contribution. Tokens are not immediately available to contributors but vesting based on vestingCliffPeriod and vestingCompletePeriod configured for the contract. vestingCliffPeriod can only start after the presale period ends. Since the presale goal can be reached before the end of the presale period tokens will not start vesting immediately after the presale succeeded.

• Depending on the initial configuration of the presale contract, Shareholder tokens may start vesting right after the presale period, even though the presale failed, giving contributors stake in the DAO.

• Investors should claim a refund and abandon the DAO in case the presale fails. Trading with the MarketMaker opens only of it he presale succeeds. Tokens should not vest to an extent that would allow majority voting power in the Shareholder application before investors had enough time to refund their tokens (Board and Shareholder might vote on presale contract update).

• Contract upgraded must be performed via the DAO/AragonApp update mechanisms. Upgrades must be proposed by BOARD and approved by SHARE, therefore, the presale contract cannot be upgraded through the DAO/AragonApp upgrade mechanisms as this requires Shareholder approval and Shareholder tokens are not vested yet.

• Settings cannot be updated after initialization, Beneficiary cannot be updated.

• Unauthenticated functionality is protected by a reentrancy guard.

• There is an incentive to front-run transactions or act based on the fact that a presale appears to be successful soon (e.g. 40% goal is achieved - a Board member then decides to buy majority stake to gain control of the fundraising DAO)

• Board members can participate in the presale.

• Depending on the amount of Shareholder token available, single individuals might become a majority Stakeholder at a fixed rate from the presale as there is no limit for individual buyers. Investors might want to consider that before or even after they invest someone might be able to buy close to all available tokens at minimal risk of losing funds.

Fundraising

Following the successful presale phase, the actual BondingCurveMarketMaker based fundraising starts. It allows new investors to buy Shareholder token and therefore stake in the DAO for whitelisted collateral. The price is regulated by a BancorFormula. Buy or sell orders must be placed and claimed after a batch of orders has been executed. Shareholder token can be sold for collateral at any point in time. They are transferable and there is no limit on how many tokens one account can hold.

• Any Ethereum Account can interact with the AragonFundraisingController to invest in the fundraising campaign ( CREATE_BUY_ORDER, CREATE_SELL_ORDER). Investors get Shareholder tokens in return that give them a stake in the Voting application for Shareholders.

• Investors turn into Shareholders. They can use their stake of Shareholder token to participate in Shareholder Votes.

• Shareholders can transfer their Shareholder token. The amount of tokens per Shareholder is not limited.

• Shareholder tokens are minted/burned and assigned/revoked from Presale (contribute/refund) and the BatchedBancorMarkedMaker (buy/sell).

• Shareholders can not create votes themselves. They rely on at least one Board member to create a vote on the Shareholder voting application.

• The Shareholder voting application owns the management role of all permissions in the system. This means that any permission change requires a Board member to propose this change to Shareholders which in turn have to approve the change by casting their vote. The permission manager for a specific role can revoke or grant permissions to entities in the system.

• The Shareholder voting application owns critical DAO kernel roles like APP_MANAGER_ROLE or CREATE_PERMISSION_ROLE. This means that any assignment of new permissions or DAO application management (e.g. contract upgrades) requires a Board member to propose this change to Shareholders which in turn have to approve the change by casting their vote.

• Quorum and Support settings for the Board and Shareholder voting applications are critical to the security of the system.

• A Board member can also be a Shareholder in the DAO. Members of both user groups might also collude to create votings in the Shareholder voting application that are subsequently passed by majority vote.

• The FundraisingMultisigTemplate specifies the initial list of whitelisted collateral (ANT, DAI). Additional collateral can be added by Board members creating a vote on the Shareholder voting application to approve the addition of a collateral token.

• Actions or changes to the system proposed by Board members might be blocked by passive or inactive Shareholders.

• Adjusting quorum and support to address failing Shareholder participation in votings might not be possible when the majority of Shareholders are passive or inactive.

• Shareholders can execute EVMScript (depending on the executor e.g. call out to other contracts w/o value transfer) on behalf of their TokenManager.

• Board members require Shareholder approval to update the tap amount for specific collateral.

• Board members can propose to call other contracts via Agents.safeExecute() pending Shareholder approval.

• Every Board member can create a new voting on the board voting application.

• Board members can vote on changing their voting applications quorum and support.

• Board members can vote on adding and removing new Board members.

• Board members are bound to a membership token. Every Board member has the same voting power.

• Board members can vote on spending funds from the board vault (beneficiary in the system) via the board finance app.

• Board members can vote on opening the presale. This can even be done before the actual open date that was specified when deploying the DAO was hit.

• Any Ethereum Account can initiate the withdrawal of an amount limited by the Tap contract from the reserve to the beneficiary. In most cases, this will be an account acting in control or favor of Board members.

• Board members can propose an update to fees, the beneficiary account, collateral tokens, tap rate, the token tap to Shareholders for approval.

• Collaterals stored in and taken from the applications reserve are not recorded in a finance application. Only Tap can directly interact with the reserves Vault functionality.

• Board members can execute EVMScript (depending on the executor e.g. call out to other contracts w/o value transfer) on behalf of their TokenManager.

• Board members can withdraw collateral tokens from the Board vault and invest in getting more stake in the Shareholder voting application to change system settings in their favor.

General

• Compromise of individual accounts (Beneficiary, Board members, major Stakeholders) or contracts can put the system at risk.

• The early stages of fundraising may be susceptible to manipulations as it is easier to get majority voting rights.

• Setup and permission of the fundraising application with the DAO is critical. Misconfiguration can easily expose critical functionality to potential attackers.

• The Beneficiary can potentially block presale funds or funds from sell orders if it reverts when receiving ETH or tokens (e.g. fees). This is possible if the collateral is either ETH or an ERC-20 compatible token with callbacks (e.g. ERC-777 or ERC-223).

• MarketMaking - is susceptible to price manipulations (Pump & Dump).

• A general issue with creating votings that perform actions if they pass is that the executed actions need to be reviewed by all the voters to make sure that e.g. a vote asking to execute a benign action actually executes that benign action and not a critical one instead (requires means to review evmscript provided with the vote action).

• Implications of using a democracy based system on the fundraising application should be researched further. E.g. the majority can decide critical aspects of the system: steal collaterals and Board tokens; destroy the system; blocked decisions; parties may abstain from voting or generally not interested in voting.

• Using multiple bonding curves for a single token can be problematic. Currently, the Shareholder token is issued using multiple different bonding curves (one per each collateral token). It is yet to be verified whether this is safe and working correctly. The first assumption is that if someone buys Shareholder tokens for some collateral token (say, DAI), price in DAI will go up. It looks like price in any other collateral (e.g. ETH) will go down (because in other tokens total supply will still grow, but the reserve balance will remain the same) which might be problematic. We suggest to further investigate the potential security implications of that design.

• The idea behind implementing Bonding Curves in a batched way is mostly based on fighting against front-running. While getting rid of front-running in its pure way, the batching algorithm introduces multiple price manipulation techniques that are very similar to front-running and sometimes even more dangerous.

  • If some whale buys a huge amount of tokens, it’s profitable for anyone to buy tokens also in this batch because there is a very high chance that the price will go up after this batch and the next batch will be with a much higher price. Because of doing so, the price will go even higher. It’s bad for the whale because they’ll buy for a slightly higher price than they intended to. The thing is that a whale will not immediately sell the tokens back (because of high costs). But all other traders can sell everything back and make a profit.

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.

if (fee > 0) {
    reserve.transfer(_collateral, beneficiary, fee);
}

function updateFormula(IBancorFormula _formula) external auth(UPDATE_FORMULA_ROLE) {
    require(isContract(_formula), ERROR_CONTRACT_IS_EOA);

    _updateFormula(_formula);
}

function _slippageIsValid(Batch storage _batch, address _collateral) internal view returns (bool) {
    uint256 staticPricePPM = _staticPricePPM(_batch.supply, _batch.balance, _batch.reserveRatio);
    uint256 maximumSlippage = collaterals[_collateral].slippage;

for (uint256 i = 0; i < _toReset.length; i++) {
    require(_tokenIsContractOrETH(_toReset[i]), ERROR_INVALID_TOKENS);
    toReset.push(_toReset[i]);
}

function openTrading() external auth(OPEN_TRADING_ROLE) {
    for (uint256 i = 0; i < toReset.length; i++) {
        tap.resetTappedToken(toReset[i]);
    }

    marketMaker.open();
}

function _maximumWithdrawal(address _token) internal view returns (uint256) {
    uint256 toBeClaimed = controller.collateralsToBeClaimed(_token);
    uint256 floor = floors[_token];
    uint256 minimum = toBeClaimed.add(floor);
    uint256 balance = _token == ETH ? address(reserve).balance : ERC20(_token).staticBalanceOf(reserve);
    uint256 tapped = (_currentBatchId().sub(lastWithdrawals[_token])).mul(rates[_token]);

    if (minimum >= balance) {
        return 0;
    }

    if (balance >= tapped.add(minimum)) {
        return tapped;
    }

    return balance.sub(minimum);
}

function _poolBalanceIsSufficient(address _collateral) internal view returns (bool) {
    return controller.balanceOf(address(reserve), _collateral) >= collateralsToBeClaimed[_collateral];
}

function balanceOf(address _who, address _token) public view isInitialized returns (uint256) {
    uint256 balance = _token == ETH ? _who.balance : ERC20(_token).staticBalanceOf(_who);

    if (_who == address(reserve)) {
        return balance.sub(tap.getMaximumWithdrawal(_token));
    } else {
        return balance;
    }
}

function _tappedAmount(address _token) internal view returns (uint256) {
    uint256 toBeKept = controller.collateralsToBeClaimed(_token).add(floors[_token]);
    uint256 balance = _token == ETH ? address(reserve).balance : ERC20(_token).staticBalanceOf(reserve);
    uint256 flow = (_currentBatchId().sub(lastTappedAmountUpdates[_token])).mul(rates[_token]);
    uint256 tappedAmount = tappedAmounts[_token].add(flow);
    /**
     * whatever happens enough collateral should be
     * kept in the reserve pool to guarantee that
     * its balance is kept above the floor once
     * all pending sell orders are claimed
    */

    /**
     * the reserve's balance is already below the balance to be kept
     * the tapped amount should be reset to zero
    */
    if (balance <= toBeKept) {
        return 0;
    }

    /**
     * the reserve's balance minus the upcoming tap flow would be below the balance to be kept
     * the flow should be reduced to balance - toBeKept
    */
    if (balance <= toBeKept.add(tappedAmount)) {
        return balance.sub(toBeKept);
    }

    /**
     * the reserve's balance minus the upcoming flow is above the balance to be kept
     * the flow can be added to the tapped amount
    */
    return tappedAmount;
}

function contribute(address _contributor, uint256 _value) external payable nonReentrant auth(CONTRIBUTE_ROLE) {
    require(state() == State.Funding, ERROR_INVALID_STATE);

    if (contributionToken == ETH) {
        require(msg.value == _value, ERROR_INVALID_CONTRIBUTE_VALUE);
    } else {
        require(msg.value == 0,      ERROR_INVALID_CONTRIBUTE_VALUE);
    }

require(ERC20(_token).safeTransfer(_to, _amount), ERROR_TOKEN_TRANSFER_REVERTED);

uint256 fee = _value.mul(buyFeePct).div(PCT_BASE);
uint256 value = _value.sub(fee);

// collect fee and collateral
if (fee > 0) {
    _transfer(_buyer, beneficiary, _collateral, fee);
}
_transfer(_buyer, address(reserve), _collateral, value);

/**
 * @notice Update controller to `_controller`
 * @param _controller The address of the new controller contract
*/
function updateController(IAragonFundraisingController _controller) external auth(UPDATE_CONTROLLER_ROLE) {
    require(isContract(_controller), ERROR_CONTRACT_IS_EOA);

    _updateController(_controller);
}

/**
 * @notice Update reserve to `_reserve`
 * @param _reserve The address of the new reserve [pool] contract
*/
function updateReserve(Vault _reserve) external auth(UPDATE_RESERVE_ROLE) {
    require(isContract(_reserve), ERROR_CONTRACT_IS_EOA);

    _updateReserve(_reserve);
}

if (_openDate != 0) {
    _setOpenDate(_openDate);
}

function open() external auth(OPEN_ROLE) {
    require(state() == State.Pending, ERROR_INVALID_STATE);

    _open();
}

function contribute(address _contributor, uint256 _value) external payable nonReentrant auth(CONTRIBUTE_ROLE) {
    require(state() == State.Funding, ERROR_INVALID_STATE);

    if (contributionToken == ETH) {
        require(msg.value == _value, ERROR_INVALID_CONTRIBUTE_VALUE);
    } else {
        require(msg.value == 0,      ERROR_INVALID_CONTRIBUTE_VALUE);
    }

    _contribute(_contributor, _value);
}

,/templates/multisig/contracts/FundraisingMultisigTemplate.sol:485:5: Warning: Function state mutability can be restricted to view
    function _daoCache() internal returns (Kernel dao) {
    ^ (Relevant source part starts here and spans across multiple lines).
,/templates/multisig/contracts/FundraisingMultisigTemplate.sol:491:5: Warning: Function state mutability can be restricted to view
    function _boardAppsCache() internal returns (TokenManager boardTM, Voting boardVoting, Vault vault, Finance finance) {
    ^ (Relevant source part starts here and spans across multiple lines).
,/templates/multisig/contracts/FundraisingMultisigTemplate.sol:500:5: Warning: Function state mutability can be restricted to view
    function _shareAppsCache() internal returns (TokenManager shareTM, Voting shareVoting) {
    ^ (Relevant source part starts here and spans across multiple lines).
,/templates/multisig/contracts/FundraisingMultisigTemplate.sol:507:5: Warning: Function state mutability can be restricted to view
    function _fundraisingAppsCache() internal returns (Agent reserve, Presale presale, MarketMaker marketMaker, Tap tap, Controller controller) {
    ^ (Relevant source part starts here and spans across multiple lines).
,/templates/multisig/contracts/FundraisingMultisigTemplate.sol:541:5: Warning: Function state mutability can be restricted to view
    function _vaultCache() internal returns (Vault vault) {
    ^ (Relevant source part starts here and spans across multiple lines).
,/templates/multisig/contracts/FundraisingMultisigTemplate.sol:547:5: Warning: Function state mutability can be restricted to view
    function _shareTMCache() internal returns (TokenManager shareTM) {
    ^ (Relevant source part starts here and spans across multiple lines).
,/templates/multisig/contracts/FundraisingMultisigTemplate.sol:553:5: Warning: Function state mutability can be restricted to view
    function _reserveCache() internal returns (Agent reserve) {
    ^ (Relevant source part starts here and spans across multiple lines).
,/templates/multisig/contracts/FundraisingMultisigTemplate.sol:559:5: Warning: Function state mutability can be restricted to view
    function _presaleCache() internal returns (Presale presale) {
    ^ (Relevant source part starts here and spans across multiple lines).
,/templates/multisig/contracts/FundraisingMultisigTemplate.sol:565:5: Warning: Function state mutability can be restricted to view
    function _controllerCache() internal returns (Controller controller) {
    ^ (Relevant source part starts here and spans across multiple lines).
,/templates/multisig/contracts/FundraisingMultisigTemplate.sol:577:5: Warning: Function state mutability can be restricted to view
    function _ensureBoardAppsCache() internal {
    ^ (Relevant source part starts here and spans across multiple lines).
,/templates/multisig/contracts/FundraisingMultisigTemplate.sol:588:5: Warning: Function state mutability can be restricted to view
    function _ensureShareAppsCache() internal {
    ^ (Relevant source part starts here and spans across multiple lines).
,/templates/multisig/contracts/FundraisingMultisigTemplate.sol:597:5: Warning: Function state mutability can be restricted to view
    function _ensureFundraisingAppsCache() internal {
    ^ (Relevant source part starts here and spans across multiple lines).

// create and grant ADD_PROTECTED_TOKEN_ROLE to this template
acl.createPermission(this, controller, controller.ADD_COLLATERAL_TOKEN_ROLE(), this);

// create and grant ADD_PROTECTED_TOKEN_ROLE to this template
acl.createPermission(this, controller, controller.ADD_COLLATERAL_TOKEN_ROLE(), this);

// transfer ADD_PROTECTED_TOKEN_ROLE
_transferPermissionFromTemplate(acl, controller, shareVoting, controller.ADD_COLLATERAL_TOKEN_ROLE(), shareVoting);

constructor(
    DAOFactory              _daoFactory,
    ENS                     _ens,
    MiniMeTokenFactory      _miniMeFactory,
    IFIFSResolvingRegistrar _aragonID,
    address                 _dai,
    address                 _ant
)
    BaseTemplate(_daoFactory, _ens, _miniMeFactory, _aragonID)
    public
{
    _ensureAragonIdIsValid(_aragonID);
    _ensureMiniMeFactoryIsValid(_miniMeFactory);
    _ensureTokenIsContractOrETH(_dai);
    _ensureTokenIsContractOrETH(_ant);

    collaterals.push(address(_dai));
    collaterals.push(address(_ant));
}

import "@aragon/os/contracts/lib/token/ERC20.sol";

_ensureTokenIsContractOrETH(_dai);
_ensureTokenIsContractOrETH(_ant);

 function _ensureTokenIsContractOrETH(address _token) internal view returns (bool) {
    require(isContract(_token) || _token == ETH, ERROR_BAD_SETTINGS);
}

7 Tool-Based Analysis

Several tools were used to perform an automated analysis of the reviewed contracts. These issues were reviewed by the audit team, and relevant issues are listed in the Issue Details section.

7.1 MythX

MythX is a security analysis API for Ethereum smart contracts. It performs multiple types of analysis, including fuzzing and symbolic execution, to detect many common vulnerability types. The tool was used for automated vulnerability discovery for all audited contracts and libraries. More details on MythX can be found at mythx.io.

7.2 Ethlint

Ethlint is an open-source project for linting Solidity code. Only security-related issues were reviewed by the audit team.

Below is the raw output of the Ethlint vulnerability scan:

$ solium --version
Solium version 1.2.5

$ solium -d
apps/aragon-fundraising/contracts/AragonFundraisingController.sol
  370:5    error    Only use indent of 4 spaces.    indentation

templates/multisig/contracts/FundraisingMultisigTemplate.sol
  573:5    error    Only use indent of 4 spaces.    indentation

7.3 Surya

Surya is a utility tool for smart contract systems. It provides a number of visual outputs and information about the structure of smart contracts. It also supports querying the function call graph in multiple ways to aid in the manual inspection and control flow analysis of contracts.

Below is a complete list of functions with their visibility and modifiers (please use horizontal scroll to view all columns):

Contracts Description Table

Legend

7.4 Test Coverage Measurement

Testing is implemented using Truffle an all provided test cases pass. However, the Presale contract fails to generate coverage statistics.

MarketMaker

@ablack/fundraising-batched-bancor-market-maker:   161 passing (14m)
@ablack/fundraising-batched-bancor-market-maker: -------------------------------|----------|----------|----------|----------|----------------|
@ablack/fundraising-batched-bancor-market-maker: File                           |  % Stmts | % Branch |  % Funcs |  % Lines |Uncovered Lines |
@ablack/fundraising-batched-bancor-market-maker: -------------------------------|----------|----------|----------|----------|----------------|
@ablack/fundraising-batched-bancor-market-maker:  contracts/                    |    99.54 |    81.36 |      100 |    99.55 |                |
@ablack/fundraising-batched-bancor-market-maker:   BatchedBancorMarketMaker.sol |    99.54 |    81.36 |      100 |    99.55 |            493 |
@ablack/fundraising-batched-bancor-market-maker: -------------------------------|----------|----------|----------|----------|----------------|
@ablack/fundraising-batched-bancor-market-maker: All files                      |    99.54 |    81.36 |      100 |    99.55 |                |
@ablack/fundraising-batched-bancor-market-maker: -------------------------------|----------|----------|----------|----------|----------------|

Controller

@ablack/fundraising-aragon-fundraising:   62 passing (9m)
@ablack/fundraising-aragon-fundraising: ----------------------------------|----------|----------|----------|----------|----------------|
@ablack/fundraising-aragon-fundraising: File                              |  % Stmts | % Branch |  % Funcs |  % Lines |Uncovered Lines |
@ablack/fundraising-aragon-fundraising: ----------------------------------|----------|----------|----------|----------|----------------|
@ablack/fundraising-aragon-fundraising:  contracts/                       |    97.96 |    94.44 |     96.3 |    97.96 |                |
@ablack/fundraising-aragon-fundraising:   AragonFundraisingController.sol |    97.96 |    94.44 |     96.3 |    97.96 |            351 |
@ablack/fundraising-aragon-fundraising: ----------------------------------|----------|----------|----------|----------|----------------|
@ablack/fundraising-aragon-fundraising: All files                         |    97.96 |    94.44 |     96.3 |    97.96 |                |
@ablack/fundraising-aragon-fundraising: ----------------------------------|----------|----------|----------|----------|----------------|

Tap

@ablack/fundraising-tap:   49 passing (3m)
@ablack/fundraising-tap: ------------|----------|----------|----------|----------|----------------|
@ablack/fundraising-tap: File        |  % Stmts | % Branch |  % Funcs |  % Lines |Uncovered Lines |
@ablack/fundraising-tap: ------------|----------|----------|----------|----------|----------------|
@ablack/fundraising-tap:  contracts/ |    99.02 |    94.83 |      100 |    99.06 |                |
@ablack/fundraising-tap:   Tap.sol   |    99.02 |    94.83 |      100 |    99.06 |            313 |
@ablack/fundraising-tap: ------------|----------|----------|----------|----------|----------------|
@ablack/fundraising-tap: All files   |    99.02 |    94.83 |      100 |    99.06 |                |

Presale

lerna ERR! npm run test:coverage exited 1 in '@ablack/fundraising-presale'
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @ablack/[email protected] coverage:presale: `lerna run --scope=@ablack/fundraising-presale --stream test:coverage`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the @ablack/[email protected] coverage:presale script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

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.