In the contract `Ownable.sol` the role `owner` has authority over the functions:
- renounceOwnership()
- transferOwnership()

In the contract `Hound.sol` the role `owner` has authority over the functions:
- excludeFromFees()
- excludeMultipleAccountsFromFees()
- setMarketingWallet()
- setFoundationWallet()
- setSwapTokensAtAmount()
- setLiquidityFee()
- setMarketingFee()
- setFoundationFee()
- setDeadFee()
- setLpRewardFee()
- setMinPeriod()
- resetLPRewardLastSendTime()
- updateDistributorGas()

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

Centralization Related Risks

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

When `marketingWalletAddress` and `foundationWalletAddress` are put into the `_isExcludedFromFees` list, they haven't been assigned any values. Therefore, only zero address is put into the `_isExcludedFromFees` list in L748~749.

Empty Value

The given input is missing the check for the non-zero address.

Missing Input Validation

All of the tokens are sent to the contract deployer when deploying the contract. This could be a centralization risk as the deployer can distribute tokens without obtaining the consensus of the community.

Initial Token Distribution

Different kinds of fees should be less than a reasonable upper limit.

Missing Upper Limit

The contract has 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 an 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

The linked variables are assigned only once, either during their contract-level declaration or during the `constructor`'s execution.

Mutability Specifiers Missing

In the `process()` function, there may be insufficient gas during the last dividend distribution process, causing the function to roll back.

Insufficient Gas

When token holders want to transfer all their tokens, they may be forced to keep one percent of the balance.

Holders Can Not Transfer All Balance

In the function `process()`, the value of `nowbanance.mul(IERC20(uniswapV2Pair).balanceOf(shareholders[currentIndex]))` is divided by `IERC20(uniswapV2Pair).totalSupply()` which may be zero if all liquidity holders had removed all their liquidity.

```solidity=944
    uint256 amount = nowbanance.mul(IERC20(uniswapV2Pair).balanceOf(shareholders[currentIndex])).div(IERC20(uniswapV2Pair).totalSupply());
```

Divide by Zero

Since there are some liquidity will be automatically added to `address(0)` during `swapAndLiquify`, so the total supply of `uniswapV2Pair` contains the part of `address(0)`. This means that there is a portion of the `nowbanance` that no one will receive. Have you considered this?

Unclaimed Dividends

If `amount` equals zero, it may be because `nowbanance` equals 0. In this case, it is unnecessary to increase `currentIndex` since the holder doesn't get rewards.

Unnecessary Increment

The `swapAndLiquify` function converts half of the `contractTokenBalance` Hound tokens to BNB. The other half of Hound tokens and part of the converted BNB are deposited into the Hound-BNB pool on pancakeswap as liquidity. For every `swapAndLiquify` function call, a small amount of BNB leftover in the contract. This is because the price of Hound drops after swapping the first half of Hound tokens into BNBs, and the other half of Hound tokens require less than the converted BNB to be paired with it when adding liquidity. The contract doesn't appear to provide a way to withdraw those BNB, and they will be locked in the contract forever.

Contract Gains Non-withdrawable BNB via the `swapAndLiquify` Function

The function that affects the status of sensitive variables should be able to emit events.

Missing Emit Events

The following functions are declared as `public`, contain array function arguments, 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. 

Function Visibility Optimization

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:

- uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens
- uniswapV2Router.addLiquidityETH
- uniswapV2Router.swapExactTokensForTokensSupportingFeeOnTransferTokens

Potential Sandwich Attacks

The LP reward tokens are sent to those who hold the LP tokens, but the users only can be put into shareholder list in function `_transfer` by `setShare`. If one user holds the LP tokens, and then he transfers his LP to another user, another user still can not get the LP reward token although he holds LP tokens. We wonder if you have considered about this situation.

HUNTER

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

18

0

16

1

1