Read the findings of the 2022 Web3 Security Report

The linked statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.

In function `_transfer` in contract `ShibrobiToken`, the *if* clause from line 675 to line 682 is redundant, as `_taxAmt` and `_reflectAmt` are already set to the same value previously. 
```solidity=675
            if (
                to == uniswapV2Pair &&
                from != address(uniswapV2Router) &&
                !_isExcludedFromFee[from]
            ) {
                _taxAmt = 9;
                _reflectAmt = 3;
            }
```



Redundant Statements

On line 655 and 656 in function `_transfer()`, the code requires that both the sender and receiver cannot be bot; whereas the comment below states that the contract will allow bots to buy tokens as receivers. 

 ```solidity=655
             require(!bots[from] && !bots[to], "No bots.");
            // We allow bots to buy as much as they like, since they'll just lose it to tax.
 ```

Mismatch between Comment and Code

The contract is serving as the underlying entity to interact with third party `Uniswap` protocols. 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.

Third Party Dependencies

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 following functions 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.

- Function `_sell()` in contract `ProxyERC20`
- Function `swapTokensForEth()` in contract `ShibrobiToken`



Potential Sandwich Attacks

In the contract `ShibrobiToken`, the role `owner` has authority over the following functions:
- `setMaxTxAmount()`
- `setMaxWalletAmount()`
- `openTrading()`
- `addBot()`
- `delBot()`
- `changeWallet1()`
- `changeWallet2()`
- `changeWallet3()`
- `excludeFromFee()`
- `includeInFee()`
- `excludeFromReward()`
- `includeInReward()`
- `swapAndLiquifyEnabled()`
- `manualSwap()`
- `manualSend()`

Any compromise to the `owner` account may allow a hacker to take advantage of this authority and arbitrarily change fee addresses, set/remove any address as bot,  include/exclude any address in/from fees and rewards, and swap and transfer the Shibrobi token in the contract. 

In addition, contract `ShibrobiToken` inherits from abstract contract `ProxyERC20`, where the hard coded `_controller` address has the authority over the following functions:
- `proxiedApprove()`
- `proxiedTransfer()`
- `proxiedSell()`
- `proxiedSellAndSend()`
- `proxiedWETHWithdraw()`

Any compromise to the `_controller` account may allow a hacker to sell and transfer the tokens in the contract to any address. 


Centralization Related Risks


The following functions are declared as `public` and are not invoked in any of the contracts contained within the project's scope. The functions that are never called internally within the contract should have external visibility. 

- `isExcludedFromFee()`
- `excludeFromReward()`
- `name()`
- `symbol()`
- `decimals()`
- `totalSupply()`
- `swapAndLiquifyEnabled()`
- `setMaxTxAmount()`
- `setMaxWalletAmount()`
- `addBot()`
- `delBot()`
- `isExcludedFromReward()`


Function Visibility Optimization

The function that affects the status of sensitive variables should be able to emit events as notifications to users.
- `setMaxTxAmount()`
- `setMaxWalletAmount()`

Missing Emit Events

State variables that never change should be declared as `constant` to save gas.

- `_swapTokensAtAmount`
- `swapAmountPerTax`



State Variable Should Be Declared Constant

The following variables are never used in the codebase.

1. Variable `_previousOwner` in `Ownable`.
2. Variable `airdropKeys` in `ShibrobiToken`.
3. Variable `airdrop` in `ShibrobiToken`.
4. Variable `cooldownEnabled` in `ShibrobiToken`.
5. Variable `pc` in `ShibrobiToken`.
6. Variable `totalReflectTax` in `ShibrobiToken`.
7. Variable `totalTax` in `ShibrobiToken`.


Unused State Variables

In function `_transferStandard()`, `_transferToExcluded()`, `_transferFromExcluded()` and `_transferBothExcluded()`, the following code is added, which seems to put penalty on bot behavior within the first 3 blocks after `tradeOpen()` is called. 

```solidity
...
        if(openBlock.add(_bl) >= block.number && sender == uniswapV2Pair) {
            // One token - add insult to injury.
            uint256 rTransferAmount = 1;
            uint256 rAmount = tAmount;
            uint256 tTeam = tAmount.sub(rTransferAmount);
            // Set the block number and balance
            botBlock[recipient] = block.number;
            botBalance[recipient] = _rOwned[recipient].add(tAmount);
            // Handle the transfers
            _rOwned[sender] = _rOwned[sender].sub(rAmount);
            _rOwned[recipient] = _rOwned[recipient].add(rTransferAmount);
            _takeTaxes(tTeam);
            emit Transfer(sender, recipient, rTransferAmount);

        } else {
...
```

The calculation here seems to be problematic, with `tAmount` subtracted from `rOwned[sender]`, and `rTransfer` directly set to 1 (possibly to represent exactly 1 token). In the typical design of Safemoon-like deflationary token, the actual token balance is represented by `tOwned[]`, where `rOwned[]` is the reflected amount, not calculated directly with the actual transfer amount. 


Potentially Problematic Calculation with `rOwned` and `tAmount`

ShibRobi

ShibRobi

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

10

0

10

0

0