Read the findings of the 2022 Web3 Security Report

In the contract `BondDepository`, many input variables in the functions `initializeBondTerms()`, `setAdjustment()` and `setTotalDebt()` do not have reasonable boundaries, so these functions can change the term parameters arbitrarily after deploying. Also in the function `setBondTerms()`, the `term.fee` can be set to 100% so that the users can not get any `IND` tokens back from depositing. What's more, if the `rewardVestingTerm` is set to 0 in the function `setBondTerms()`, the users will not get any rewards.

In the contract `Staking`, the input variables of function `setWarmup()` need reasonable boundaries. Without the limitation, the contract owner can lock the users' `sIND` in the `warmupContract` address for a very long period or even forever.

The parameters in the function `initialize()` of the contract `INDPreSale` also need reasonable boundaries.

Lack of reasonable boundary

The main function of `InfinityDAO` protocol is providing a reserve currency protocol with two main functionalities: staking and bonding. Bonding is used to acquire the reserve assets by selling `IND`. And staking is used to lock `IND` and receive an equal amount of `sIND` and vice versa. In addition, the contract `DepositHelper` allows users to directly deposit `USDT` tokens which will be swapped to the `IND-USDT` LP tokens and deposited into the bonding contract.

And then, there are some questions:

  1. The bond price for selling the `IND` by bonding is `1 + controlVariable * debtRatio`. `controlVariable` is a centrally set variable. `debtRatio` is `currentDebt() / IERC20(IND).totalSupply()` where `currentDebt` can be increased by depositing and decreased by time passing. As a result, the bond price is a little complex and not predicable. The only thing is certain is that the bond price is larger than 1.
  2. The `principle value`, bond price and other swap ratio do not consider the outside token prices. Thus, the bond and other token price may be decoupled from market prices. Malicious users can leverage this for arbitrage.
  3. The staking reward is the `IND` token and the minted rewards do not have reserve token backed. Also, in the contract `Treasury`, the debtor role can borrow the reserved principle token holding `sIND` without paying any token assets and the borrowing time does not have a limitation. As a result, the reserved principle token may be not sufficient for stabilizing the `IND` price.
  4. The staking mechanism is based on the `rebase()` functionality. The rebase can only be triggered by new staking of the `IND` tokens. The rebase amount also has a positive relation with the staking amount. This means that the `_totalSupply` of `sIND` will increase an amount in proportion to the users' staking amount. This will affect the price of `sIND` if it can be trade outside the protocol.
  5. The contract `INDPreSale` is selling an unknown token `alphaIND` for arbitrary price. Also, in the contract `INDMigration`, the users can swap `alphaIND` token for `IND` token with the ratio of 1:1. This may disrupting the token prices in the current protocol.
  6. In the contract `INDPreSale`, the pre-sale can be started with different settings (price, time, etc.) many times.
    
We would like to confirm with the client if the current implementation aligns with the original project design.

Financial models

In the contract `BondDepository`, the role `owner` has the authority over the following function:

- function `renounceManagement()`: set the `_owner` of current contract to `address(0)`,
- function `pushManagement()/pullManagement()`: transfer the `_owner` role to any arbitrary addresses,
- function `initializeBondTerms()`: set a new bond terms to sell `IND` tokens and initialize all the important variables,
- function `setBondTerms()`: change the important term parameters like period length, `maxPayout`, fee amount, `maxDebt` and `rewardVestingTerm`,
- function `setAdjustment()`: set control variable adjustment to change the value of `controlVariable` and bond price consequently,
- function `setStaking()`: change the `staking/stakingHelper` address and the `useHelper` flag,
- function `setSupper()`: change the `supper` address(Invite contract address).

Any compromise to the `owner` account may allow the hacker to take advantage of this authority and users' assets may suffer loss.

Centralization risk in BondDepository.sol

In the function `deposit()` in contract `BondDepository`, the require statement in L842 checks `totalDebt <= terms.maxDebt` to ensure that the depositing does not exceed `terms.maxDebt`. After the depositing, the new deposit value will be added to `totalDebt` in L873. Thus, the current depositing may still result that `totalDebt` exceeds `terms.maxDebt` and only the next depositing will be blocked.

Logic issue in function `deposit()`

The function `_bondPrice()` update the bond price with the `terms.controlVariable` set by the contract owner. It will check whether the `price_` is less than `terms.minimumPrice` and make sure the new price is greater than `terms.minimumPrice`. However, when the `price_` is greater than or equal to `terms.minimumPrice` at the beginning, the value of `terms.minPrice` is set to 0 making the latter minumum price checking invalid.

```solidity=1060
    function _bondPrice() internal returns ( uint price_ ) {
        price_ = terms.controlVariable.mul( debtRatio() ).add( 1000000000 ).div( 1e7 );
        if ( price_ < terms.minimumPrice ) {
            price_ = terms.minimumPrice;        
        } else if ( terms.minimumPrice != 0 ) {
            terms.minimumPrice = 0;
        }
    }
```

Logic issue in function `_bondPrice()`

In the function `deposit()`, the return value of `IBondCalculator(bondCalculator).getLPValue(principle,_amount)` is passed into the function `setBuyBond()` as a parameter. However, in the contract `Calculator`, the function `getLPValue()` will treat the `principle` token as the trading pair address. In other word, the principle token must be the LP token, otherwise, the call of  `getLPValue()` will fail.

From the contract `DepositHelper`, we can tell that the LP token is the only token passed into the `BondDepository.deposit()`. However, the contract `Treasury` allows depositing not only the LP token but also the reserve token. 

`setBuyBond()` only allows LP depositing

Flash loans are a way to borrow large amounts of money for a certain fee. The requirement is that the loans need to be returned within the same transaction in a block. If not, the transaction will be reverted. 

An attacker can use the borrowed money as the initial funds for an exploit to enlarge the profit and/or manipulate the token price in the decentralized exchanges. 

We find that the contract `Calculator` relies on price calculations that are based on-chain, meaning that they would be susceptible to flash-loan attacks by manipulating the price of given pairs to the attacker's benefit. 

Potential flashloan attack

In the contract `DepositHelper`, the role `owner` has the authority over the following function:

- function `renounceManagement()`: set the `_owner` of current contract to `address(0)`,
- function `pushManagement()/pullManagement()`: transfer the `_owner` role to any arbitrary addresses,
- function `setBondAddress()`: change the `deposit` address.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and users' assets may suffer loss.

Centralization Risks in DepositHelper.sol

Although the function `depositHelper()` allows any token type to be passed as the input parameter `_tokenAddress`, only the `LPAddress` and `USDT` tokens are valid depositing token. Even if the passed-in `_tokenAddress` is other token type, the contract still transfer `USDT` from the `msg.sender`.

Depositing token type

In BondDepository.sol contract:
```solidity
    function ( 
        uint _amount, 
        uint _maxPrice,
        address _depositor
    ) external returns ( uint ) {
        require( _depositor != address(0), "Invalid address" );

        decayDebt();
  ......
  
    uint value = ITreasury( treasury ).valueOf( principle, _amount );
    uint payout = payoutFor( value ); // payout to bonder is computed
  
  ......
    adjust(); //**COMMENT from CertiK: This function is used to modify the value of variable terms.controlVariable according to the value of adjustment.add. When adjustment.add is TRUE, terms.controlVariable increases each time, otherwise terms.controlVariable decreases each time.**
```
```solidity
    function decayDebt() internal {
        totalDebt = totalDebt.sub( debtDecay() );
        lastDecay = block.number;
    }
    
    function payoutFor( uint _value ) public view returns ( uint ) {
        return FixedPoint.fraction( _value, bondPrice() ).decode112with18().div( 1e16 );
    }

    function bondPrice() public view returns ( uint price_ ) {        
        price_ = terms.controlVariable.mul( debtRatio() ).add( 1000000000 ).div( 1e7 );
        if ( price_ < terms.minimumPrice ) {
            price_ = terms.minimumPrice;
        }
    }

    function debtRatio() public view returns ( uint debtRatio_ ) {   
        uint supply = IERC20( IND ).totalSupply();
        debtRatio_ = FixedPoint.fraction( 
            currentDebt().mul( 1e9 ), 
            supply
        ).decode112with18().div( 1e18 );
    }

    function currentDebt() public view returns ( uint ) {
        return totalDebt.sub( debtDecay() );
    }

    function debtDecay() public view returns ( uint decay_ ) {
        uint blocksSinceLast = block.number.sub( lastDecay );
        decay_ = totalDebt.mul( blocksSinceLast ).div( terms.vestingTerm );
        if ( decay_ > totalDebt ) {
            decay_ = totalDebt;
        }
    }
```

In the Treasury.sol contract:
```solidity
    function valueOf( address _token, uint _amount ) public view returns ( uint value_ ) {
        if ( isReserveToken[ _token ] ) {
            // convert amount to match IND decimals
            value_ = _amount.mul( 10 ** IERC20( IND ).decimals() ).div( 10 ** IERC20( _token ).decimals() );
        } else if ( isLiquidityToken[ _token ] ) {
            value_ = IBondCalculator( bondCalculator[ _token ] ).valuation( _token, _amount );
        }
    }
```

Referring to the above code and taking `ReserveToken` as an example, the bond price can be expressed as the following formulas:

$$
\begin{align}

bondAmount &= \frac{Value}{bondPrice \times 10^{16}} && \tag 1\\ 

bondPrice &= controlVariable \times \frac{totalDebt'}{totalSupply \times 10^9} + 100 && \tag 2\\ 

totalDebt' &= totalDebt \times \left( 1 - \frac{\Delta block}{vestingTerm} \right) && \tag 3\\ 

where \ \  & \Delta block \leq vestingTerm && \notag\

\end{align}
$$

- $Value :$ the amount of reserve tokens paid by users
- $controlVariable :$ `terms.controlVariable` whose rise and fall is controlled by function `adjust()`
- $\Delta block :$ the current `block.number` minus the `block.number` at the last call
- $vestingTerm :$ the total number of blocks for bond issuance set by the `owner`
- $totalDebt :$ record the total issuance of bonds
- $totalDebt' :$ record the latest total issuance of bonds
- $totalSupple :$ record the total issuance of `LMDA` token

At the same time, referring to the following function `adjust()`, we can see that the change direction of the coefficient `controlVariable` in the bond price is determined by the variable `adjustment.add`:

- `controlVariable` keeps increasing when `adjustment.add` is `TRUE`
- `controlVariable` keeps decreasing when `adjustment.add` is `FALSE`

```solidity
function adjust() internal {
    uint blockCanAdjust = adjustment.lastBlock.add( adjustment.buffer );
    if( adjustment.rate != 0 && block.number >= blockCanAdjust ) {
        uint initial = terms.controlVariable;
        if ( adjustment.add ) {
            terms.controlVariable = terms.controlVariable.add( adjustment.rate );
            if ( terms.controlVariable >= adjustment.target ) {
                adjustment.rate = 0;
            }
        } else {
            terms.controlVariable = terms.controlVariable.sub( adjustment.rate );
            if ( terms.controlVariable <= adjustment.target ) {
                adjustment.rate = 0;
            }
        }
        adjustment.lastBlock = block.number;
        emit ControlVariableAdjustment( initial, terms.controlVariable, adjustment.rate, adjustment.add );
    }
}
```

Also, the contract `INDPreSale` is selling an unknown token `alphaIND` for arbitrary price. Also, in the contract `INDMigration`, the users can swap `alphaIND` token for `IND` token with the ratio of 1:1. This may disrupting the token prices in the current protocol.

Potential Bond Price Rigging

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects.

### External call(s)
File: BondDepository.sol (Line 864, Function `BondDepository.deposit`)
```solidity
        IERC20( principle ).safeTransferFrom( msg.sender, address(this), _amount );
```

File: BondDepository.sol (Line 865, Function `BondDepository.deposit`)
```solidity
        IERC20( principle ).approve( address( treasury ), _amount );
```

File: BondDepository.sol (Line 866, Function `BondDepository.deposit`)
```solidity
        ITreasury( treasury ).deposit( _amount, principle, profit );
```

File: BondDepository.sol (Line 869, Function `BondDepository.deposit`)
```solidity
            IERC20( IND ).safeTransfer( DAO, fee );
```

### State variables written after the call(s)
File: BondDepository.sol (Line 873, Function `BondDepository.deposit`)
```solidity
        totalDebt = totalDebt.add( value );
```


---
### External call(s)
File: BondDepository.sol (Line 864, Function `BondDepository.deposit`)
```solidity
        IERC20( principle ).safeTransferFrom( msg.sender, address(this), _amount );
```

File: BondDepository.sol (Line 865, Function `BondDepository.deposit`)
```solidity
        IERC20( principle ).approve( address( treasury ), _amount );
```

File: BondDepository.sol (Line 866, Function `BondDepository.deposit`)
```solidity
        ITreasury( treasury ).deposit( _amount, principle, profit );
```

File: BondDepository.sol (Line 869, Function `BondDepository.deposit`)
```solidity
            IERC20( IND ).safeTransfer( DAO, fee );
```

File: BondDepository.sol (Line 883, Function `BondDepository.deposit`)
```solidity
        setBuyBond(_depositor,payout,IBondCalculator(bondCalculator).getLPValue(principle,_amount));
```
* This function call executes the following external call(s).
* In `BondDepository.setBuyBond`,
    * `(_superiorAddress,_userAmount,_rewardAmount) = Invite(supper).buyBond(_userAddress,_bondAmount,_UAmount)`

### State variables written after the call(s)
File: BondDepository.sol (Line 887, Function `BondDepository.deposit`)
```solidity
        emit BondPriceChanged( bondPriceInUSD(), _bondPrice(), debtRatio() );
```
* This function call executes the following assignment(s).
* In `BondDepository._bondPrice`,
    * `terms.minimumPrice = 0`

File: BondDepository.sol (Line 889, Function `BondDepository.deposit`)
```solidity
        adjust(); // control variable is adjusted
```
* This function call executes the following assignment(s).
* In `BondDepository.adjust`,
    * `terms.controlVariable = terms.controlVariable.add(adjustment.rate)`
* In `BondDepository.adjust`,
    * `terms.controlVariable = terms.controlVariable.sub(adjustment.rate)`


---
### External call(s)
File: INDMigration.sol (Line 387, Function `INDMigration.migrate`)
```solidity
        alphaIND.transferFrom(msg.sender, address(this), amount);
```

### State variables written after the call(s)
File: INDMigration.sol (Line 388, Function `INDMigration.migrate`)
```solidity
        senderInfo[msg.sender] = senderInfo[msg.sender].add(amount);
```


---
### External call(s)
File: Staking.sol (Line 673, Function `Staking.rebase`)
```solidity
            IsIND( sIND ).rebase( epoch.distribute, epoch.number );
```

### State variables written after the call(s)
File: Staking.sol (Line 675, Function `Staking.rebase`)
```solidity
            epoch.endBlock = epoch.endBlock.add( epoch.length );
```

File: Staking.sol (Line 676, Function `Staking.rebase`)
```solidity
            epoch.number++;
```


---
### External call(s)
File: Staking.sol (Line 673, Function `Staking.rebase`)
```solidity
            IsIND( sIND ).rebase( epoch.distribute, epoch.number );
```

File: Staking.sol (Line 679, Function `Staking.rebase`)
```solidity
                IDistributor( distributor ).distribute();
```

### State variables written after the call(s)
File: Staking.sol (Line 686, Function `Staking.rebase`)
```solidity
                epoch.distribute = 0;
```

File: Staking.sol (Line 688, Function `Staking.rebase`)
```solidity
                epoch.distribute = balance.sub( staked );
```


---
### External call(s)
File: StakingDistributor.sol (Line 389-392, Function `Distributor.distribute`)
```solidity
                    ITreasury( treasury ).mintRewards( // mint and send from treasury
                        info[ i ].recipient,
                        nextRewardAt( info[ i ].rate )
                    );
```

### State variables written after the call(s)
File: StakingDistributor.sol (Line 393, Function `Distributor.distribute`)
```solidity
                    adjust( i ); // check for adjustment
```
* This function call executes the following assignment(s).
* In `Distributor.adjust`,
    * `info[_index].rate = info[_index].rate.add(adjustment.rate)`
* In `Distributor.adjust`,
    * `info[_index].rate = info[_index].rate.sub(adjustment.rate)`



Potential Reentrancy Attack

The contract `BondDepository` and `sIND` are serving as the underlying entity to interact with third party `Invite` contract. And the contract address can be changed by the function `setSupper()`. The `_superiorAddress` address, `_userAmount` and `_rewardAmount` are completely determined by this `Invite` contract, which will affect the reward amount of the user and the address `_superiorAddress`.

The scope of the audit treats 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc.

Unknown implementation of `Invite`

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user deposits 100 deflationary `principle` tokens (with a 10% transaction fee) into the contract `BondDepository`, only 90 tokens actually arrived in the contract. However, the user can still withdraw the `IND` tokens equivalent to 100 `principle` tokens from the contract, which causes the contract to lose 10 `principle` tokens in such a transaction. 

The contracts `DepositHelper`, `INDMigration` and `INDPreSale` also has the same problem since the `USDT`, `LPAddress` and `alphaIND` tokens are unknown. Also, the `IND` token itself is a deflationary token.

Incompatibility with deflationary tokens

The function `redeem()` and `redeemReward()` in the contract `BondDepository`, the function `redeemAll()` in the contract `RedeemHelper` do not check the whether `msg.sender` equals to the `_depositor`/`_recipient` to avoid any other users performing a call on this function. So a malicious user can call it for the `_depositor` with an arbitrary `_stake` value which may be against the depositors' intention.

Lack of `msg.sender` validation

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

File: BondDepository.sol (Line 719, Function `BondDepository.constructor`)
```solidity
        bondCalculator = _bondCalculator;
```
- `_bondCalculator` is not zero-checked before being used.


---
File: BondDepository.sol (Line 822, Function `BondDepository.setSupper`)
```solidity
        supper = _supper;
```
- `_supper` is not zero-checked before being used.


---
File: DepositHelper.sol (Line 288, Function `DepositHelper.constructor`)
```solidity
        deposit = _deposit;
```
- `_deposit` is not zero-checked before being used.


---
File: DepositHelper.sol (Line 289, Function `DepositHelper.constructor`)
```solidity
        IND = _IND;
```
- `_IND` is not zero-checked before being used.


---
File: DepositHelper.sol (Line 290, Function `DepositHelper.constructor`)
```solidity
        USDT = _USDT;
```
- `_USDT` is not zero-checked before being used.


---
File: DepositHelper.sol (Line 293, Function `DepositHelper.constructor`)
```solidity
        LPAddress = _LPAddress;
```
- `_LPAddress` is not zero-checked before being used.


---
File: DepositHelper.sol (Line 393, Function `DepositHelper.setBondAddress`)
```solidity
        deposit = _deposit;
```
- `_deposit` is not zero-checked before being used.


---
File: Staking.sol (Line 729, Function `Staking.setContract`)
```solidity
            distributor = _address;
```

File: Staking.sol (Line 732, Function `Staking.setContract`)
```solidity
            warmupContract = _address;
```

File: Staking.sol (Line 735, Function `Staking.setContract`)
```solidity
            locker = _address;
```
- `_address` is not zero-checked before being used.


---
File: TokenERC20.sol (Line 856, Function `VaultOwned.setVault`)
```solidity
    _vault = vault_;
```
- `vault_` is not zero-checked before being used.


---
File: TokenERC20.sol (Line 887, Function `IND.setFeeAddress`)
```solidity
        feeAddress = _feeAddress;
```
- `_feeAddress` is not zero-checked before being used.


---
File: TokenERC20.sol (Line 891, Function `IND.setPair`)
```solidity
        pair = _pair;
```
- `_pair` is not zero-checked before being used.


---
File: sTokenERC20.sol (Line 1179, Function `sIND.setInvite`)
```solidity
        Invite = _Invite;
```
- `_Invite` is not zero-checked before being used.



Missing Zero Address Validation

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

File: BondDepository.sol (Line 978, Function `BondDepository.stakeOrSend`)
```solidity
            IERC20( IND ).transfer( _recipient, _amount ); // send payout
```


---
File: INDMigration.sol (Line 387, Function `INDMigration.migrate`)
```solidity
        alphaIND.transferFrom(msg.sender, address(this), amount);
```


---
File: INDMigration.sol (Line 389, Function `INDMigration.migrate`)
```solidity
        IND.transfer(msg.sender, amount);
```


---
File: INDMigration.sol (Line 396, Function `INDMigration.withdraw`)
```solidity
        IERC20(_Token).transfer(msg.sender, amount);
```


---
File: StakingHelper.sol (Line 95, Function `StakingHelper.stake`)
```solidity
        IERC20( IND ).transferFrom( msg.sender, address(this), _amount );
```


---
File: StakingWarmup.sol (Line 91, Function `StakingWarmup.retrieve`)
```solidity
        IERC20( sIND ).transfer( _staker, _amount );
```


---
File: Treasury.sol (Line 359, Function `Treasury.incurDebt`)
```solidity
        IERC20( _token ).transfer( msg.sender, _amount );
```



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

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

`public` functions that are never called by the contract could be declared as `external`. `external` functions are more efficient than `public` functions.

Improper Usage of `public` and `external` Type

In the contract `INDMigration`, 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 users' assets may suffer loss.
![](https://accelerator-tasks-prod.s3.amazonaws.com/d0703fdbe62145ef845668f3d59f6005/diagrams/centralization_INDMigration__owner.svg)

Centralization Risks in INDMigration.sol

In the contract `INDPreSale`, the role `owner` has the authority over the following function:

- function `renounceOwnership()`: set the `_owner` of current contract to `address(0)`,
- function `transferOwnership()`: transfer the `_owner` role to any arbitrary addresses,
- function `whiteListBuyers()`: set the `buyers` to be whitelisted,
- function `initialize()`: set up sale configurations like `salePrice`, `startTimestamp`, `endTimestamp` and token addresses,
- function `setStart()`: start/stop the pre-sale,
- function `withdraw()`: transfer any assets in the current contract to any the owner account.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and users' assets may suffer loss.

Centralization Risks in INDPreSale.sol

In the contract `RedeemHelper`, the role `owner` has the authority over the following function:

- function `renounceManagement()`: set the `_owner` of current contract to `address(0)`,
- function `pushManagement()/pullManagement()`: transfer the `_owner` role to any arbitrary addresses,
- function `addBondContract()/removeBondContract()`: add/remove the addresses in `bonds`.

Any compromise to the `owner` account may allow the hacker to take advantage of this and users' assets may suffer loss.

Centralization Risks in RedeemHelper.sol

In the contract `Distributor`, the role `_policy` has the authority over the following function:

- function `renouncePolicy()`: set the `_policy` of current contract to `address(0)`,
- function `pushPolicy()/pullPolicy()`: transfer the `_policy` role to any arbitrary addresses,
- function `addRecipient()/removeRecipient()`: add/remove the address `_recipient` into/from the array `info[]` to include/exclude the address to/from reward distribution,
- function `setAdjustment()`: change the reward rate of a give `_recipient`.

Any compromise to the `_policy` account may allow the hacker to take advantage of this authority and users' assets may suffer loss.

Centralization Risks in StakingDistributor.sol

In the contract `Staking`, the role `_owner` has the authority over the following function:

- function `renounceManagement()`: set the `_owner` of current contract to `address(0)`,
- function `pushManagement()/pullManagement()`: transfer the `_owner` role to any arbitrary addresses,
- function `setContract()`: change the important addresses like `distributor`, `warmupContract`, `locker`,
- function `setWarmup()`: change the value of `warmupPeriod` which is the locking period length.

Also the role `locker` has the authority over the following function:

- function `giveLockBonus()/returnLockBonus()`: borrow and return `sIND` tokens from/to the current contract.

Any compromise to the `owner` and `locker` accounts may allow the hacker to take advantage of this and users' assets may suffer loss.

Centralization Risks in Staking.sol

In the contract `StakingWarmup`, the role `staking` has the authority over the following function:

- function `retrieve()`: transfer arbitrary amount `_sIND` tokens to any arbitrary addresses.

Any compromise to the `staking` account may allow the hacker to take advantage of this and users' assets may suffer loss.

Centralization Risks in StakingWarmup.sol

In the contract `sIND`, the role `_owner` has the authority over the following function:

- function `renounceManagement()`: set the `_owner` of current contract to `address(0)`,
- function `pushManagement()/pullManagement()`: transfer the `_owner` role to any arbitrary addresses,
- function `setIndex()`: change the current rebase index,
- function `setInvite()` change the `Invite` address.

Also the role `stakingContract` has the authority over the following function:

- function `rebase()`: increase the `sIND` totalSupply.

Also the role `initializer` (contract deployer) has the authority over the following function:

- function `initialize()`: change the `stakingContract` address and reset the value of `_gonBalances[stakingContract]` to mint all the initial token supply to the `stakingContract` address.

Any compromise to the `owner`, `stakingContract` and `initializer` accounts may allow the hacker to take advantage of this and users' assets may suffer loss.

Centralization Risks in sTokenERC20.sol

In the function `rebase()` in contract `sIND`, the actual `rebaseAmount` is `profit_.mul(_totalSupply).div(previousCirculating)` if `previousCirculating > 0`. However, in L1181 the `amountRebased` is recorded as `profit_`.

```solidity=1079
        ... else if ( circulatingSupply_ > 0 ){
            rebaseAmount = profit_.mul( _totalSupply ).div( circulatingSupply_ );
        } ...
```

Incorrect recording of `amountRebased`

In the contract `IND`, the role `owner` has the authority over the following function:

- function `renounceOwnership()`: set the `owner` of current contract to `address(0)`,
- function `transferOwnership()`: transfer the `owner` role to any arbitrary addresses,
- function `setVault()`: change the `_vault` role to an arbitrary address which can mint the `IND` token,
- function `setFeeAddress()`: change the `feeAddress` address which will receive the transaction fee.

Also the role `_vault` has the authority over the following function:

- function `mint()`: mint an arbitrary amount `IND` tokens to any arbitrary addresses.

Any compromise to the `owner`  and `_vault` accounts may allow the hacker to take advantage of this and users' assets may suffer loss.

Centralization Risks in TokenERC20.sol

In the contract `IND`, the state variable `feeAddress` is initialized as `0x5Cc30C39f2817c266908c6456295383d4714D8b4` by default in the `constructor()` and the ownership of it is uncertain.

Unknown externally owned account(EOA)

The linked variables could be declared as `constant` since these state variables are never modified.

Variables That Could Be Declared as `constant`

In the contract `Treasury`, the role `owner` has the authority over the following function:

- function `renounceManagement()`: set the `_owner` of current contract to `address(0)`,
- function `pushManagement()/pullManagement()`: transfer the `_owner` role to any arbitrary addresses,
- function `auditReserves()`: calculate the total value of all the bond `Reserve/Liquidity` tokens,
- function `queue()/toggle()`: change the important addresses like `reserveDepositors`, `reserveSpenders`, `reserveTokens`, `reserveManagers`, `liquidityDepositors`, `liquidityTokens`, `liquidityManagers`, `debtors`, `rewardManagers` and `sIND`.

The role `ReserveDepositor/LiquidityDepositor` has the authority over the following function:

- function `deposit()`: deposit the `Reserve/Liquidity` tokens for the `IND` token,

The role `ReserveManager/LiquidityManager` has the authority over the following function:

- function `manage()`: transfer any amount of the `Reserve/Liquidity` to the `msg.sender`.

The role `ReserveSpender` has the authority over the following function:

- function `withdraw()`: burn the `IND` token and get the `principle` token.

The role `Debtor` has the authority over the following function:

- function `incurDebt()`: borrow the `principle` token when holding the `sIND` token,
- function `repayDebtWithReserve()`: repay the borrowed `principle` token with the `principle` token,
- function `repayDebtWithSax()`: repay the borrowed `principle` token with the `sIND` token.

The role `RewardManager` has the authority over the following function:

- function `mintRewards()`: mint arbitrary amount of the reward `IND` token to any arbitrary addresses.

Any compromise to the privilege accounts may allow the hacker to take advantage of this and users' assets may suffer loss.

Centralization Risks in Treasury.sol

In the function `mintRewards()` in contract `Treasury`, the addresses contained in the `RewardManager` list can mint arbitrary amount of the reward `IND` token to any arbitrary addresses, which will cause many problem like sharp drop of the `IND` price. Since only the contract `Distributor` is calling the function `mintRewards()`, this function is better to be restricted so that only the contract `Distributor` can call it.

Also, since only the address which has the `_vault` role in the `IND` contract can mint `IND`, the `_minter` need to be set to the contract `Treasury`, otherwise the function `mintRewards()` will fail.

Reward manager

In the contract `Treasury`, the functions `deposit()` and `withdraw()` are the opposite operations. The functions `deposit()` deposit the `ReserveToken/LiquidityToken` token for the `IND` token. The function `withdraw()` burns the `IND` token and get the `ReserveToken/LiquidityToken` token. However, the role which can perform these operations are different: the function `deposit()` requires the `ReserveDepositor/LiquidityDepositor` role; the function `withdraw()` requires the `ReserveSpender` role. All the roles are granted by the contract owner. Thus, carelessly granting will result that some users have the deposit privilege but can not perform withdraw. Then theses user's assets will suffer loss. 

Role management

By calling the function `incurDebt()` of contract `Treasury`, the users can borrow the `ReserveToken` token when they own `sIND`. The maximum borrow amount is equivalent to the users' `sIND` balances. This may cause problem because the `sIND` can still be transferred to anybody else. For example, user A has 100 `sIND`, so he borrows 100 `ReserveToken`. Then A transfers these `sIND` to B, then B can also borrow 100 `ReserveToken` and so on and so forth. The assets in the current contract may suffer a loss. 

We would like to confirm with the client if the current implementation aligns with the original project design.

Logic issue in function `incurDebt()`

```solidity=320
    function withdraw( uint _amount, address _token ) external {
        require( isReserveToken[ _token ], "Not accepted" ); // Only reserves can be used for redemptions
        require( isReserveSpender[ msg.sender ] == true, "Not approved" );

        uint value = valueOf( _token, _amount );
        IINDERC20( IND ).burnFrom( msg.sender, value );

        totalReserves = totalReserves.sub( value );
        emit ReservesUpdated( totalReserves );

        IERC20( _token ).safeTransfer( msg.sender, _amount );

        emit Withdrawal( _token, _amount, value );
    }
```

The users in the list `isReserveSpender` can redeem the reserve assets by the function `Treasury.withdraw()`, and the list `ReserveSpender` is set by the `owner`. The value of burned `IND` token does not take the market price from a Price Oracle. This means the caller may get more value of the Reserve asset than he burned.

Privileged Users Withdraw Reserve Asset

In the `deposit()` function of contract `Treasury`, both the reserve and liquidity token can be deposit. But in L324 of function `withdraw()`, there is a require statement only allowing withdrawing reserve tokens. No withdrawal method is provided in this contract to withdraw the liquidity token.

InfinityDAO

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

36

0

36

0

0