Read the findings of the 2022 Web3 Security Report

In the contract `IOUToken`, the role `_owner` has the authority over the functions shown in the diagram below.

Any compromise to the privileged account which has access to `_owner` may allow the hacker to take advantage of this.

![](https://accelerator-tasks-prod.s3.amazonaws.com/3deea0aec5244d4e85e520b9a4f4f919/IOUToken-_owner.svg)

Centralization Risk: Privileged Role ` _owner` in Contract`IOUToken`

In the contract `IOUToken`, the roles `_minters` has the authority over the following function to mint IOU tokens:
```solidity=1489
    function mint(address _to, uint256 _amount) public onlyMinter {
        _mint(_to, _amount);
        _moveDelegates(address(0), _delegates[_to], _amount);
    }
```
And also, the role `_owner` can add accounts to `_minters` through function `addMinter()`.

Any compromise to the `owner` and `minters` may allow the hacker to take advantage of this and damage the tokenomics.

In addition, The function `mint()` contradicts the whitepaper. The function shows that IOU Token is inflationary, whereas the whitepaper says the total supply of IOU Token is a certain number - 100 billion.

Centralization Risk: Privileged Roles `_minters`

In the contract `IOUToken`, the roles `_operators` has the authority over the following functions:
- `setIOUNFTMarket()`
- `setTreasureAddress()`
- `setTimelockAddress()`
- `addToWhiteList()`
- `removeFromWhiteList()`
- `updateTransferTaxRate()`
- `updateBurnRate()`
- `setBNBToLiquidateTaxes()`
- `setBuybackUpperLimit()`
- `updateMARKETNUMERATOR()`
- `updateTreasuryNUMERATOR()`
- `updateMaxTransferAmountRate()`
- `updateMinAmountToLiquify()`
- `setExcludedFromAntiWhale()`
- `updateSwapAndLiquifyEnabled()`
- `disperseToken()`
- `disperseTokenSimple()`
- `rescueTokens()`

And also, the role `_owner` can add accounts to `operators` through function `addOperators()`.

Any compromise to the `_owner` and `_operators` accounts may allow the hacker to take advantage of this and damage the tokenomics.

Centralization Risk: Privileged Roles `_operators`

```solidity=1614
    function addToLiquidity(uint256 _amount, uint256 bnbAmount) internal {
        _approve(address(this), address(uniswapRouter), _amount);
        
        uniswapRouter.addLiquidityETH{value: bnbAmount}(
            address(this),
            _amount,
            0, // slippage is unavoidable
            0, // slippage is unavoidable
            owner(),
            block.timestamp
        );
    }
```
The function `addLiquidity()` calls the function `uniswapRouter.addLiquidityETH()` with the `to` address specified as `owner()` for acquiring the generated LP tokens from the `IOU-BNB` pool. As a result, over time the owner will accumulate a significant portion of LP tokens. Since the owner is an EOA (Externally Owned Account), mishandling of its private key has devastating consequences to the project as a whole.

Centralization Risk: LP Token Receiver

```solidity=1428
    // The operator can only update the transfer tax rate
    address private _operator;
```
The comment says the role `_operator` can update variable `transferTaxRate`. In fact, the role `_operator` has no privilege to the contract.

Inconsistency Between Comment and Code

```solidity=1396
    // Transfer tax rate in basis points. (default 0.3%)
    uint16 public transferTaxRate = 25;
    // Burn rate % of transfer tax. (default 20% x 0.3% = 0.06% of total amount).
    uint16 public burnRate = 20;
```
```solidity=1536
    // default tax is 0.3% of every transfer
```
```solidity=1542
    // default 99.7% of transfer sent to recipient
```
Comments at line 1396 and line 1536 say the tax rate should be 0.3%, whereas the rate in the code is 25 basis points (0.25%).

0.25% should be the intended design based on the whitepaper.

Inconsistency in Variable `transferTaxRate`

```solidity=1546
    if((sender != owner() && recipient != address(this)) || (sender != address(this) && recipient != owner())){
```
The condition would always be true unless both the sender and the recipient are `owner()` or both are `address(this)`.

Redundant Condition

```solidity=1603
    uniswapRouter.swapExactTokensForETHSupportingFeeOnTransferTokens(
        tokenAmount,
        0,
        path,
        address(this),
        block.timestamp
    );
```
```solidity=1617
    uniswapRouter.addLiquidityETH{value: bnbAmount}(
        address(this),
        _amount,
        0, // slippage is unavoidable
        0, // slippage is unavoidable
        owner(),
        block.timestamp
    );
```
```solidity=1632
    uniswapRouter.swapExactETHForTokensSupportingFeeOnTransferTokens{value: amount}(
        0,
        path,
        BURN_ADDRESS,
        block.timestamp.add(300)
    );
```
A sandwich attack might 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 (before the transaction being attacked) a transaction to purchase one of the assets and make profits by backrunning (after the transaction being attacked) a transaction to sell the asset.

The functions above are called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large.

Potential Sandwich Attacks

```solidity=1589
    swapBNBForTokensBurn(remaining.div(100));
```
Variable `remaining` is the amount of BNB left in the contract for burning. However, only 1% of `remaining` would be burned when function `swapAndLiquify()` is called.

Inadequat BNB Burning

```solidity
    function updateBurnRate(uint16 _burnRate) public onlyOperator {
        require(_burnRate <= 100, "IOU::updateBurnRate: Burn rate must not exceed the maximum rate.");
        emit BurnRateUpdated(msg.sender, burnRate, _burnRate);
        burnRate = _burnRate;
    }

    function updateMARKETNUMERATOR(uint16 _market) public onlyOperator {
        require(_market <= 100, "IOU::updateMarketNumerator: Market rate must not exceed the maximum rate.");
        emit MarketRateUpdated(msg.sender, NFTMARKET_NUMERATOR, _market);
        NFTMARKET_NUMERATOR = _market;
    }

    function updateTreasuryNUMERATOR(uint16 _treasury) public onlyOperator {
        require(_treasury <= 100, "IOU::updateTreasuryNUMERATOR: Manage rate must not exceed the maximum rate.");
        emit TreasuryRateUpdated(msg.sender, TREASURY_NUMERATOR, _treasury);
        TREASURY_NUMERATOR = _treasury;
    }
```
Function `_transfer()` in contract `IOUToken` would revert if `burnRate` + `NFTMARKET_NUMERATOR` + `TREASURY_NUMERATOR` > 100. 

Potential Risk of Fee-Rate Setting

```solidity=1494
    function setIOUNFTMarket(address _newIOUNFTMarket) public onlyOperator {
        IOUNFTMarket = _newIOUNFTMarket;
    }

    function setTreasureAddress(address _newTreasuryAddress) public onlyOperator {
        treasuryAddress = _newTreasuryAddress;
    }

    function setTimelockAddress(address _newTimelockWallet) public onlyOperator {
        timelockAddress = _newTimelockWallet;
    }
```
The given inputs are missing the checks for the non-zero addresses in the functions above.

Missing Input Validation

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

Missing Emit Events

```solidity=1537
    uint256 taxAmount = amount.mul(transferTaxRate).div(10000);
    uint256 burnAmount = taxAmount.mul(burnRate).div(DENOMINATOR);
    uint256 ioumarket = taxAmount.mul(NFTMARKET_NUMERATOR).div(DENOMINATOR);
    uint256 manage = taxAmount.mul(TREASURY_NUMERATOR).div(DENOMINATOR);

    // default 99.7% of transfer sent to recipient
    uint256 sendAmount = amount.sub(taxAmount);
    require(amount == sendAmount + taxAmount, "IOU::transfer: Tax value invalid");
```
`sendAmount = amount.sub(taxAmount)`, so the condition `amount == sendAmount + taxAmount` at line 1544 is always true.

Redundant Require Check

```solidity=1856
    function rescueTokens(address tokenAddress) external onlyOperator {
        IBEP20 token = IBEP20(tokenAddress);
        uint256 tokenBalance = token.balanceOf(address(this));
        require(tokenBalance > 0, "No tokens in our balance");
        token.transfer(msg.sender, tokenBalance);
    }
```
The function above can be used by `_operators` to withdraw IOU tokens from this contract.

Centralization Risk on Function `rescueTokens()`

```solidity=1026
    function _transfer(
        address sender,
        address recipient,
        uint256 amount
    ) internal virtual {
        require(sender != address(0), "BEP20: transfer from the zero address");
        require(recipient != address(0), "BEP20: transfer to the zero address");

        _balances[sender] = _balances[sender].sub(amount, "BEP20: transfer amount exceeds balance");
        _balances[recipient] = _balances[recipient].add(amount);
        emit Transfer(sender, recipient, amount);
    }
```
When a delegator calls function `delegate()` to delegate to a delegatee, the latter holds votes that are equal to the delegator's balance.

However, when the delegator's balance changes through function `transfer()` or `transferFrom()` (both trigger `_transfer()`), the votes of the delegatee are NOT updated.

IOU City

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

15

0

15

0

0