Ultron Foundation Multisig

Smart Contract Audit Report

Audit Summary

Ultron Foundation Multisig Audit Report Ultron Foundation is building a treasury where registered voters can propose and vote on transfers of funds between accounts, as well as minting of the new ERC20 token wULX.

For this audit, we reviewed Ultron Foundation's DAOwULX, DAOTreasury, Treasury, wULX and Multisig contracts at commit 3ebe23d21f9e8524b9ac37c0a6765259e568fad2 on the team's private GitHub repository.

We previously reviewed the project team's Chainbridge DAO here.

Audit Findings

Please ensure trust in the team prior to investing as they have substantial control in the ecosystem.
Date: June 4th, 2022.

Finding #1 - DAOTreasury, DAOwULX, wULX, Treasury - Low

Description: These contracts allow anyone to set the address of the Treasury, wULX, DAOwULX, and DAOTreasury contracts respectively, once, to be used within the contract implementation.
Risk/Impact: Allowing anyone to set contracts to be used within this implementation potentially allows for unintended contracts to be utilized by treasury multisig wallets.
Recommendation: The team should restrict the ability to set thse contracts to only trusted addresses.

Finding #2 - wULX, Treasury - Informational

Description: The internal _transfer() function used in wULX and the withdrawalNative() function used in Treasury, transfer ULX from the contract using the transfer() function instead of the call() function.
Risk/Impact: The transfer() function uses a hardcoded gas amount of 2300, meaning transactions could run out of gas as the team receives ETH.
Recommendation: Use .call.value{...} ("") instead as it does not have a gas limitation.

Contracts Overview

  • As the contracts are implemented with Solidity v0.8.0, they are safe from any possible overflows/underflows.
Multisig Contract:
  • This contract allows for registered voters to vote to insert or remove voters.
  • Upon deployment, the deployer is inserted into the list of voters as the first voter.
  • Voters can propose a new Vote Request to either remove an existing voter, or include a new voter to the list of voters; upon proposal of the new request, a confirming vote is cast for the newly created request on behalf of the sender.
  • Each voter has a unique id they receive when they are added to the list of voters and receive the status of an active voter; the zero address can never be added as a voter.
  • When a voter is voted to be removed from the list of voters, they are no longer considered an active voter; any pending votes they have cast will no longer be considered.
  • A vote is concluded only if there are more than 50% of the active voter count affirmative votes for the proposal. Once this is concluded, this Voter Request can no longer be voted on.
DAOTreasury Contract:
  • This contract extends the functionality of Multisig by allowing for voters to vote on the transfers of either ERC20 tokens or ULX for predetermined addresses and amounts.
  • Upon construction, the deployer is added as the first active voter in this contract.
  • Anyone can set the token address for the Treasury once.
  • Voters can propose a transfer of either a specified ERC20 Token or ULX by specifing the amount to transfer and the recipient; upon proposal of the new request, a confirming vote is cast for the newly created request on behalf of the sender.
  • A transfer proposal is considered passed if there are more than 50% of the active voter count of affirmative votes for the proposal.
  • Only the Treasury contract address can confirm a transfer token request for either ERC20 or ULX. Following the confirmation of the transfer, there can no longer be votes cast on the request.
DAOwULX Contract:
  • This contract extends the functionality of Multisig by allowing for voters to vote on the minting of the wULX token.
  • Upon construction, the deployer is added as the first active voter in this contract.
  • Anyone can set the token address for wULX token address once.
  • Voters can propose to either include, or remove a minter from the list of minters; upon proposal of the new request, a confirming vote is cast for the newly created request on behalf of the sender.
  • A minter proposal is considered passed if there are more than 50% of the active voter count of affirmative votes for the proposal.
  • Only the wULX contract can confirm a minter request. Following the confirmation of the minter, there can no longer be votes cast on the request.
wULX Contract:
  • This contract contrains the ERC20 implementation of wULX token.
  • Anyone can set the address of the DAOwULX contract address once.
  • Anyone can trigger the conclusion of an existing Minter Request proposal by specifying the id of the request; if the vote passes, the associated address of the Minter Request vote is set to either be included or removed from the list of Minters for this token, as determined by the DAOwULX contract address.
  • Following the completion of the Minter Request, the Minter Request is confirmed by this contract to the DAOwULX contract, and voting is locked for this proposal.
  • Accounts that are not minters that send ULX to this contract receive the amount of wULX equal to the value of ULX sent on the call.
  • When an account with Minter status mints wULX tokens, they specify a receiving account and an amount for them to receive, at no cost to the minter.
  • When an account with Minter status burns wULX tokens, they specify an account to burn from and the amount to burn.
  • Users can transfer an amount of wULX to this contract to get a refund in ULX equal to the amount of wULX sent; following the refund, the amount wULX transferred is burned.
Treasury Contract:
  • This contract manages the withdrawal of ERC20 Tokens or ULX.
  • Anyone can set the address of the DAOTreasury once.
  • Anyone can trigger the conclusion of an existing ERC20 or ULX token proposal by specifying the id of the request; if the vote passes, the transfer of the specified amount of token is transferred to the recipient.
  • Following the completion of an ERC20 or ULX token transfer, the request is confirmed by this contract to the DAOTreasury contract, and locked from any further interaction.

Audit Results

Vulnerability CategoryNotesResult
Arbitrary Jump/Storage WriteN/APASS
Centralization of Control
  • The deployer of DAOTreasury and DAOwULX is the first registered voter for these contracts.
  • Any blockchain address with the minter status can mint any amount of wULX at no cost.
  • Any blockchain address with the minter status can burn any amount of wULX from any address.
WARNING
Compiler IssuesN/APASS
Delegate Call to Untrusted ContractN/APASS
Dependence on Predictable VariablesN/APASS
Ether/Token TheftN/APASS
Flash LoansN/APASS
Front RunningN/APASS
Improper EventsN/APASS
Improper Authorization SchemeN/APASS
Integer Over/UnderflowN/APASS
Logical IssuesN/APASS
Oracle IssuesN/APASS
Outdated Compiler VersionN/APASS
Race ConditionsN/APASS
ReentrancyN/APASS
Signature IssuesN/APASS
Unbounded LoopsN/APASS
Unused CodeN/APASS
Overall Contract Safety PASS

Multisig Contract

Smart Contract Audit - Inheritance

Smart Contract Audit - Graph


 ($) = payable function
 # = non-constant function

 Int = Internal
 Ext = External
 Pub = Public

 +  Multisig 
    - [Pub]  #
    - [Pub] getVoterById
    - [Pub] getVoterStatusByAddress
       - modifiers: notNullAddress
    - [Pub] getActiveVotersCount
    - [Int] getVotersCounter
    - [Int] insertVoter #
       - modifiers: notNullAddress
    - [Int] removeVoter #
       - modifiers: onlyVoter
    - [Ext] newVoteForVoterRequest #
       - modifiers: onlyVoter,voterRequestExists,notExecuted
    - [Ext] newVoterRequest #
       - modifiers: notNullAddress,onlyVoter
    - [Ext] votersRequestConclusion #
       - modifiers: notExecuted

DAOTreasury Contract

Smart Contract Audit - Inheritance

Smart Contract Audit - Graph


 ($) = payable function
 # = non-constant function

 Int = Internal
 Ext = External
 Pub = Public

 +  Multisig 
    - [Pub]  #
    - [Pub] getVoterById
    - [Pub] getVoterStatusByAddress
       - modifiers: notNullAddress
    - [Pub] getActiveVotersCount
    - [Int] getVotersCounter
    - [Int] insertVoter #
       - modifiers: notNullAddress
    - [Int] removeVoter #
       - modifiers: onlyVoter
    - [Ext] newVoteForVoterRequest #
       - modifiers: onlyVoter,voterRequestExists,notExecuted
    - [Ext] newVoterRequest #
       - modifiers: notNullAddress,onlyVoter
    - [Ext] votersRequestConclusion #
       - modifiers: notExecuted

 +  DAOTreasury (Multisig)
    - [Ext] setTreasuryContractInitial #
    - [Ext] isTransferTokensAvailable
    - [Ext] confirmTransferTokensRequest #
       - modifiers: onlyTreasury
    - [Ext] newVoteForTransferTokensRequest #
       - modifiers: onlyVoter
    - [Ext] newTransferTokensRequest #
       - modifiers: onlyVoter
    - [Ext] isTransferNativeAvailable
    - [Ext] confirmTransferNativeRequest #
       - modifiers: onlyTreasury
    - [Ext] newVoteForTransferNativeRequest #
       - modifiers: onlyVoter
    - [Ext] newTransferNativeRequest #
       - modifiers: onlyVoter

DAOwULX Contract

Smart Contract Audit - Inheritance

Smart Contract Audit - Graph


 ($) = payable function
 # = non-constant function

 Int = Internal
 Ext = External
 Pub = Public

  +  Multisig 
    - [Pub]  #
    - [Pub] getVoterById
    - [Pub] getVoterStatusByAddress
       - modifiers: notNullAddress
    - [Pub] getActiveVotersCount
    - [Int] getVotersCounter
    - [Int] insertVoter #
       - modifiers: notNullAddress
    - [Int] removeVoter #
       - modifiers: onlyVoter
    - [Ext] newVoteForVoterRequest #
       - modifiers: onlyVoter,voterRequestExists,notExecuted
    - [Ext] newVoterRequest #
       - modifiers: notNullAddress,onlyVoter
    - [Ext] votersRequestConclusion #
       - modifiers: notExecuted

 +  DAOwULX (Multisig)
    - [Ext] setwulxContractInitial #
    - [Ext] isMinterRequestAvailable
    - [Ext] confirmMinterRequest #
       - modifiers: onlywULX
    - [Ext] newVoteForMinterRequest #
       - modifiers: onlyVoter
    - [Ext] newMinterRequest #
       - modifiers: onlyVoter
	   

wULX Contract

Smart Contract Audit - Inheritance

Smart Contract Audit - Graph


 ($) = payable function
 # = non-constant function

 Int = Internal
 Ext = External
 Pub = Public

   + [Int] IERC20 
    - [Ext] totalSupply
    - [Ext] balanceOf
    - [Ext] transfer #
    - [Ext] allowance
    - [Ext] approve #
    - [Ext] transferFrom #

 + [Int] IERC20Metadata (IERC20)
    - [Ext] name
    - [Ext] symbol
    - [Ext] decimals

 +  Context 
    - [Int] _msgSender
    - [Int] _msgData

 + [Int] IDAOwULX 
    - [Ext] isMinterRequestAvailable
    - [Ext] confirmMinterRequest #

 +  wULX (Context, IERC20, IERC20Metadata)
    - [Pub]  ($)
    - [Ext] name
    - [Ext] symbol
    - [Ext] decimals
    - [Ext] totalSupply
    - [Ext] balanceOf
    - [Int] containsMinter
    - [Ext] getContractDAO
    - [Ext] setDAOContractInitial #
    - [Ext] transfer #
    - [Pub] allowance
    - [Ext] approve #
    - [Ext] transferFrom #
    - [Ext] setMinter #
    - [Pub] increaseAllowance #
    - [Pub] decreaseAllowance #
    - [Ext]  ($)
    - [Int] _transfer #
    - [Int] _mint #
    - [Ext] mint #
    - [Ext] burn #
    - [Int] _burn #
    - [Int] _approve #
    - [Int] _spendAllowance #
	   

Treasury Contract

Smart Contract Audit - Inheritance

Smart Contract Audit - Graph


 ($) = payable function
 # = non-constant function

 Int = Internal
 Ext = External
 Pub = Public

   + [Int] IERC20 
    - [Ext] totalSupply
    - [Ext] balanceOf
    - [Ext] transfer #
    - [Ext] allowance
    - [Ext] approve #
    - [Ext] transferFrom #

 + [Int] IERC20Metadata (IERC20)
    - [Ext] name
    - [Ext] symbol
    - [Ext] decimals

 +  Context 
    - [Int] _msgSender
    - [Int] _msgData

 + [Int] IDAOwULX 
    - [Ext] isMinterRequestAvailable
    - [Ext] confirmMinterRequest #

 +  wULX (Context, IERC20, IERC20Metadata)
    - [Pub]  ($)
    - [Ext] name
    - [Ext] symbol
    - [Ext] decimals
    - [Ext] totalSupply
    - [Ext] balanceOf
    - [Int] containsMinter
    - [Ext] getContractDAO
    - [Ext] setDAOContractInitial #
    - [Ext] transfer #
    - [Pub] allowance
    - [Ext] approve #
    - [Ext] transferFrom #
    - [Ext] setMinter #
    - [Pub] increaseAllowance #
    - [Pub] decreaseAllowance #
    - [Ext]  ($)
    - [Int] _transfer #
    - [Int] _mint #
    - [Ext] mint #
    - [Ext] burn #
    - [Int] _burn #
    - [Int] _approve #
    - [Int] _spendAllowance #
	   

About Solidity Finance

Solidity Finance was founded in 2020 and quickly grew to have one of the most experienced and well-equipped smart contract auditing teams in the industry. Our team has conducted 1000+ solidity smart contract audits covering all major project types and protocols, securing a total of over $10 billion U.S. dollars in on-chain value.
Our firm is well-reputed in the community and is trusted as a top smart contract auditing company for the review of solidity code, no matter how complex. Our team of experienced solidity smart contract auditors performs audits for tokens, NFTs, crowdsales, marketplaces, gambling games, financial protocols, and more!

Contact us today to get a free quote for a smart contract audit of your project!

What is a Solidity Audit?

Typically, a smart contract audit is a comprehensive review process designed to discover logical errors, security vulnerabilities, and optimization opportunities within code. A Solidity Audit takes this a step further by verifying economic logic to ensure the stability of smart contracts and highlighting privileged functionality to create a report that is easy to understand for developers and community members alike.

How Do I Interpret the Findings?

Each of our Findings will be labeled with a Severity level. We always recommend the team resolve High, Medium, and Low severity findings prior to deploying the code to the mainnet. Here is a breakdown on what each Severity level means for the project:

  • High severity indicates that the issue puts a large number of users' funds at risk and has a high probability of exploitation, or the smart contract contains serious logical issues which can prevent the code from operating as intended.
  • Medium severity issues are those which place at least some users' funds at risk and has a medium to high probability of exploitation.
  • Low severity issues have a relatively minor risk association; these issues have a low probability of occurring or may have a minimal impact.
  • Informational issues pose no immediate risk, but inform the project team of opportunities for gas optimizations and following smart contract security best practices.