Read the findings of the 2022 Web3 Security Report

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

Initial Token Distribution

In the contract `EspToken`, the role `owner` has authority over the following functions:
- `excludeFromFee()`
- `includeInFee()`
- `setFees()`

Any compromise to the `owner` account may allow a hacker to take advantage of this authority and arbitrarily change the tax fee and include/exclude addresses in/from fees. 

Centralization Related Risks

`ESP` token charges a 5% fee for each sell transaction, and the fee is transferred to "game pool" address. Since the `_tTotal` is a constant, if the tokens in game pool are not redistributed to the users in some way, then what will happen in the end is all of the token would be added to game pool. A user could not benifit from the token. 

Doubtful Tokenomics

The contract has payable function `receive()`, but does not have a function to withdraw the fund.

File: projects/ExplorationShip/contracts/ESPToken.sol (Line 146, Contract `EspToken`)
```solidity=146
    receive() external payable {}
```



BNB Locked In Contract

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

Variables `_tTotal`, `_name`, `_symbol`, `_decimals` can be declared with `Constant`. A big advantage of constant variables is that reading them is significantly cheaper than reading from regular state variables since will not be stored in storage. 

Variable Declare as Constant

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

Redundant Statements

The previous owner is possible to gain ownership of the contract again by function `unlock()`. This can be achieved by performing the following operations:
1. Owner `A` calls `lock()` to lock the contract. The variable `_previousOwner` is set to the owner `A`.
2. Owner `A` calls `unlock()` to unlock the contract.
3. Owner `A` calls `transferOwnership()` to transfer ownership to owner `B`. Note that the current owner is `B` now.
4. Owner `A` calls `unlock()` to regain ownership.

The problem is that the `_previousOwner` has not been cleared after `unlock()`.

Previous Owner Possible to Regain Ownership By Function `unlock()` 

ExplorationShip

token-lib

SafeMath.sol

IPancakeswapV2Factory.sol

IPancakeswapV2Router02.sol

ExplorationShip

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

8

0

4

1

3