Read the findings of the 2022 Web3 Security Report

In the contract `BattleFish` the role `_multiSig` has authority over the functions shown in the diagram below.

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

![](https://accelerator-tasks-prod.s3.amazonaws.com/f55b19f7a5dd4ff7ac0857c0902c352c/diagrams/centralization_BattleFish__multiSig.svg)

In the contract `BattleFish` the role `_stakingContract` has authority over the functions shown in the diagram below.

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

![](https://accelerator-tasks-prod.s3.amazonaws.com/f55b19f7a5dd4ff7ac0857c0902c352c/diagrams/centralization_BattleFish__stakingContract.svg)

Centralization Risks in BattleFish.sol

Contracts that authorize users using the `tx.origin` variable are typically vulnerable to phishing attacks which can trick users into performing authenticated actions on the vulnerable contract.

There are multiple reasons why using `tx.origin` is not safe from a security perspective. Refer to :

* [Solidity Documentation on `tx.origin`](https://docs.soliditylang.org/en/latest/security-considerations.html#tx-origin)
* <https://github.com/ethereum/solidity/issues/683>

File: BattleFish.sol (Line 449, Function `BattleFish._transfer`)
```solidity
  require(!_oneTx[tx.origin], "$BATTLE: transaction count limit");
```

Usage of `tx.origin`

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

Missing Emit Events

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 different compiler versions. 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

One or more declarations do not conform to the [Solidity style guide](https://solidity.readthedocs.io/en/v0.7.3/style-guide.html#naming-conventions) with regards to its naming convention.

Particularly:
- `camelCase`: Should be applied to function names, argument names, local and state variable names, and modifiers.
- `UPPER_CASE`: Should be applied to `constant` variables.
- `CapWords`: Should be applied to contract names, struct names, event names, and enums.

File: BattleFish.sol (Line 330, Contract `BattleFish`)
```solidity
  string private constant _name = "Battle.Fish";
```
- Constant variable `_name` is not in `UPPER_CASE`.


---
File: BattleFish.sol (Line 331, Contract `BattleFish`)
```solidity
  string private constant _symbol = "$BATTLE";
```
- Constant variable `_symbol` is not in `UPPER_CASE`.


---
File: BattleFish.sol (Line 332, Contract `BattleFish`)
```solidity
  uint8 private constant _decimals = 9;
```
- Constant variable `_decimals` is not in `UPPER_CASE`.


---
File: BattleFish.sol (Line 344, Contract `BattleFish`)
```solidity
  address private constant _uniRouter = 0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D;
```
- Constant variable `_uniRouter` is not in `UPPER_CASE`.


---
File: BattleFish.sol (Line 345, Contract `BattleFish`)
```solidity
  IUniswapV2Router02 private UniV2Router;
```
- Variable `UniV2Router` is not in `camelCase`.

Declaration Naming Convention

Multiple Solidity versions are used in the codebase.

Versions used: `>=0.6.2`, `^0.8.0`


File: BattleFish.sol (Line 125)
```solidity
pragma solidity >=0.6.2;
```

File: BattleFish.sol (Line 293)
```solidity
pragma solidity ^0.8.0;
```



Different Solidity Versions

Is the code on line 447 of the function `_transfer()` used to limit the number of purchases a buyer can make?
``` solidity=447
if (block.timestamp < _timeTxCountLimit) {
  require(tx.gasprice <= _gasLimit || sender == _lp, "$BATTLE: excessive gas");
  require(!_oneTx[tx.origin], "$BATTLE: transaction count limit");
  _buyCounter[tx.origin] += taxedAmount;
  _oneTx[tx.origin] = true;
}
```

In the `_transfer()` function, what is the code on line 465 used for? Is it true that every time the current token is sold, a portion of the fee is converted to `WETH` and sent to the `vault` address?

``` solidity=462
if (_balances[address(this)] > 100 * 10**9 && !_swapping) {
  uint256 _swapAmount = _balances[address(this)];
  if (_swapAmount > amount * 40 / 100) _swapAmount = amount * 40 / 100;
  _tokensToETH(_swapAmount);
}
```

Finance Model

Battle Fish

Battle.Fish

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

7

0

6

0

1