<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectButton />

<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectLogo /><space /><projectName>{{ projectName }}</projectName>

Bug Bounty rewards are grouped by severity and the impact of the vulnerability. Examples and descriptions of the type of vulnerabilities that correspond to each severity level can be found below. The payout amount has a 5 tier structure with separate scalesfor website/apps and smart contracts.

Description of vulnerability and your proof of concept or validation steps

Name

Please input a title

Short description of the vulnerability and the affected asset.

The core team is situated in country(ies) that received low aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests an increased difficulty and complexity in preventing and mitigating fraud.

The core team is situated in country(ies) that received medium aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests a medium level of geographic accountability, thus reducing and mitigating the risk of fraud.

The core team is situated in country(ies) that received the best aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests the highest level of geographic accountability, thus maximizing the risk reduction and mitigation.

Vulnerability Title

Uniswap

MESSIER

In the `signOnProposal()` function, users can only sign a proposal once due to the `notSigner(proposalIndex)` modifier, which checks whether `_storeSigner[msg.sender][_proposalIndex] == false`. Therefore, the `_storeSigner[msg.sender][_proposalIndex] = true` code should be used for each signing process. However, the contract uses `_storeSigner[msg.sender][signersNum] = true;`, which allows a user to sign a proposal multiple times.

A user could sign a proposal for multiple times

In the contract `Dao` the role `ORACLE` in the address [0xe0cf9c69894e2cca7221a5d1db2f867ece64b08c](https://etherscan.io/address/0xe0cf9c69894e2cca7221a5d1db2f867ece64b08c) has authority over the functions below.
- function `CloseProposal`: to change a proposal's state to `FAILED`.
- function `OracleNext`: to validate the quantity of affirmative and negative votes, as well as the number of singers, associated with a proposal before transitioning to the voting phases. Upon the successful completion of these evaluations, the state of the proposal would be modified to initiate the voting stages.
- function `FullCycleToExecution`: to execute a cycle, calculate and process the rewards.

In the contract `Dao` the role `ORACLE` in the commit [be0fb877ce73207ea4906a438b4390429ef5c953](https://github.com/MessierM87/VIRGO_SolidityContracts/tree/be0fb877ce73207ea4906a438b4390429ef5c953/contracts) has authority over the functions below.
- function `OracleNext`: to execute a proposal if the proposal's state is `ready`.
- function `FullCycleToExecution`: to execute a cycle, calculate and process the rewards.
- function `changeState`: to change the state for a proposal regarding the current state and votes.

Any compromise to the `ORACLE` account may allow the hacker to take advantage of this authority.

In the contract `Dao` the role `_owner` has authority over the functions shown in the diagram below.
Any compromise to the `_owner` account may allow the hacker to take advantage of this authority, and set the `_SupernovaBridge` and `_supernova`.
![](https://accelerator-tasks-prod.s3.amazonaws.com/4fb3912d16c54542bb881998b2376e0d/diagrams/centralization_Dao-Dao-_owner.svg)

In the contract `Dao` the role `Halo` has authority over the functions below.
- function `VoteOnProposal()`: to vote for a proposal.

Any compromise to the `Halo` account may allow the hacker to take advantage of this authority.

In the contract `Dao` the role `Powehi` has authority over the functions below.
- function `createCashOutProposal()`: to create a new cash-out proposal.
- function `createDoubleClassicProposal()`: to create a new double down or classical proposal.
- function `createStructureProposal()`: to create a new structural proposal.
- function `signOnProposal()`: to sign a proposal.

Any compromise to the `Powehi` account may allow the hacker to take advantage of this authority.

Centralization Related Risks

In the contract `Dao` the role `ORACLE` has authority over the functions below.
- function `ProposalCheckOut`: to execute a proposal according to the `ProposalType`.

Any compromise to the `ORACLE` account may allow the hacker to take advantage of this authority.


Centralization Related Risks in `ProposalCheckOut` function

The following code snippets in the `ProposalCheckOut()` function is incorrect:
```solidity
            if (queue_Ids[_Index] == _idQ) {
                queue_Ids[_Index] = queue_Ids[_Index];
                queue_Ids.pop();
```
, for the `queue_Ids[_Index] = queue_Ids[_Index];` is redundant, it should be `queue_Ids[_Index] = queue_Ids[queue_Ids.length - 1];` to implement the design.

Logical issue when processing the `queue_Ids` in `ProposalCheckOut()`

According to the logic of the function `ProposalNext()`, the state check in `ProposalCheckOut()`, which is `if(proposal.activeState ==State.QUEUED)`, should be modified as `if(proposal.activeState ==State.RUNNING)`, or the `ProposalNext()` would be reverted.

Wrong state check

There is no `receive()` or `fallback()` function in the Dao.sol, so this contract cannot receive ETH.

Missing Receive Function

The `CloseProposal()` function cannot be called because a vote can only be in the `State.CREATED` or `State.EXECUTED` state according to the code. Additionally, changing the state to `State.FAILED` has no effect as there is no state check on `VoteOnProposal()`, meaning that the voting process cannot be stopped.

The `CloseProposal()` will not work

The `oracle` role has the ability to directly execute a proposal by calling `OracleNext()` regardless of the result of the voting process, which has the potential to render the entire voting system invalid. 

Logical issue on the voting system

The logic in the `changeState` function is incomplete and incorrect. Specifically, the `VoteOnProposal` function can only be invoked in the `QUEUED` state, but there is no mechanism to transition to or from that state:

1. The `CREATED` state can only be changed to `FAILED`.
2. There is currently no mechanism in place to transition from the `QUEUED` state to the `VOTING` state.
3. It is not possible to change the state to any value other than `CREATED` or `VOTING` once the proposal has entered either of these states.

```solidity = 703
    function changeState(State _state,uint _proposalIndex) public OnlyOracle returns(bool){
        if(proposals[_proposalIndex].activeState == State.CREATED){
            if(_state == State.FAILED){
                proposals[_proposalIndex].activeState = _state;
            }else{
                revert("You can not change whatever you want");
            }
                   
        }else if(proposals[_proposalIndex].activeState == State.VOTING){
             (uint YES,uint NO,State s) = CheckOutVote(proposalIndex);
            if(NO>YES){
                 proposals[_proposalIndex].activeState =State.FAILED;
            }else{
                 proposals[_proposalIndex].activeState =State.READY;
            }

        }
```

Logical issue in function `changeState()`

In the function `CheckOutVote()`, the voting result is only based on the number of YES and NO votes without considering the total amount of votes, namely the quorum. As a result, the vote could be passed with only one YES vote.

Lack of Quorum Restriction

A sandwich attack may happen when an attacker observes a transaction swapping tokens or adding liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (executing before the target) a transaction to purchase one of the assets and make profits by back running (executing after the target) a transaction to sell the asset.

The following function is called without setting restrictions on slippage or minimum output amount, so transactions triggering the function are vulnerable to sandwich attacks, especially when the input amount is large:

- `IUniswapV2Router(UNISWAP_V2_ROUTER).swapExactTokensForETHSupportingFeeOnTransferTokens()` in `swapTokensForEth()`

Potential Sandwich Attacks

The `Initializable` contract is inherited but not imported.

`Initializable` is Not Imported

```solidity=330
        uint8 signersNum = uint8(proposal.signers.length);
```
- The type conversion `uint8(proposal.signers.length)` from larger type uint256 to smaller type uint8 may truncate data.


---
```solidity=517
        uint8 signersNum = uint8(proposal.signers.length);
```
- The type conversion `uint8(proposal.signers.length)` from larger type uint256 to smaller type uint8 may truncate data.



Unsafe Integer Cast

Addresses should be checked before assignment or external call to make sure they are not zero addresses.

```solidity=160
        ORACLE = _oracle;
```
- `_oracle` is not zero-checked before being used.


---
```solidity=161
        _M87 = _m87;
```
- `_m87` is not zero-checked before being used.


---
```solidity=188
        _supernova = _fb;
```
- `_fb` is not zero-checked before being used.

Missing Zero Address Validation

The return value of the transfer()/transferFrom() call is not checked.

```solidity=764
            IERC20Upgradeable(_token).transfer(
                address(_supernova),
                getfromtoken
            );
```


---
```solidity=803
        IERC20Upgradeable(_token).transfer(address(0xdead), getfromtoken);
```

Unchecked ERC-20 `transfer()`/`transferFrom()` Call

If the proposal has a time limit, the contract should verify that the current time is within the voting period before calling `VoteOnProposal()`. 

Lack of check on `proposal.date`

The `execute_Cycle()` and `execute_oneProposal()` functions exhibit significant interactions with the `_SupernovaBridge` contract, which falls outside the scope of this audit. Therefore, we would like the team to provide further elaboration on the design of these functions.

The design of `execute_oneProposal()` and `execute_Cycle()`

Typo

The `Bridge` modifier verifies whether the `_hsh` parameter is equal to the `_Hash` value. However, since the `_hsh` is always passed in as the `_Hash` parameter and is not set by the function caller, the modifier becomes redundant.

Redundant `Bridge` modifier

The function `swapTokenForToken` is private but never used in the contract, hence it is redundant.

Unused private function

The contract cited has an unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to ambiguity when debugging, as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

Unlocked Compiler Version


```solidity=390
        returns (bool)
```
- The function `ProposalCheckOut` implicitly returns a default value.


---
```solidity=446
        returns (bool)
```
- The function `sendToExecution` implicitly returns a default value.


---
```solidity=505
        returns (bool)
```
- The function `ProposalNext` implicitly returns a default value.


---
```solidity=713
    ) internal Bridge(_hsh) returns (bool) {
```
- The function `execute_oneProposal` implicitly returns a default value.


---
```solidity=791
    ) internal Bridge(_hsh) returns (bool) {
```
- The function `execute_Cycle` implicitly returns a default value.



Unused Return Variable

Literals with many digits are difficult to read and review.

```solidity=164
        CLASSIC_DEF = 8700000000000000000; //wei 8.7
```


---
```solidity=165
        DOUBLE_DEF = 17400000000000000000; //wei 17.4
```


---
```solidity=166
        CLASSIC_MIN = 870000000000000000; //wei 0.87
```


---
```solidity=167
        DOUBLE_MIN = 8700000000000000000; //wei 8.7
```


---
```solidity=168
        CLASSIC_MAX = 87000000000000000000; //wei 8.7
```


---
```solidity=169
        DOUBLE_MAX = 26100000000000000000; //wei 26.1
```


---
```solidity=170
        FULLCYCLE_MAX = 87000000000000000000; //wei 87  ETH
```



Too Many Digits

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Missing Emit Events

The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.

Missing Error Messages

In consideration of the functionality of the `changeState()` function and its capacity to modify a proposal's state at will, it appears unnecessary to use the `CloseProposal()` function to change the proposal state to `FAILED`.

Additionally, the `failedChecker` modifier has also been considered redundant since every function that utilizes this modifier already incorporates an `atState` check.

Redundant code

The private function `ProposalCheckOut()`, which verifies and executes the result of a proposal, is redundant as it is not utilized anywhere in the contract.

Redundant `ProposalCheckOut()`

The `CLASSIC_MAX` and `CLASSIC_MIN` is not used anywhere in the contract, hence they are redundant.

Redundant `CLASSIC_MAX` and `CLASSIC_MIN`

Messier - Audit

Dao.sol

CertiK Skynet

Virgo is a trustless decentralized autonomous organization (DAO) governed by M87 stakers that runs solely on immutable smart contracts. Smart contracts facilitate all internal functions relating to treasury funds being spent, tokens being purchased, and rewards being distributed. The design of Virgo ensures it is completely trustless, since there are no middlemen who ever have access to any of its funds at any point of any process.

Leaderboards

Due Diligence Tools

Resources

KYC Status

Bug Bounty Program

Total Holders & Daily New Token Holders