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

Literals with many digits are difficult to read and review.

Too Many Digits

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

Initial Token Distribution

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

Mutability Specifiers Missing

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

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

![](https://accelerator-tasks-prod.s3.amazonaws.com/7a68589b698c4afd8068571c088b5e40/diagrams/centralization-Peach-_owner.svg)

In the contract `Peach` the role `staker` has authority over the functions shown in the diagram below.

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

![](https://accelerator-tasks-prod.s3.amazonaws.com/7a68589b698c4afd8068571c088b5e40/diagrams/centralization-Peach-staker.svg)

Centralization Risk in Peach.sol

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

Missing Emit Events

`public` functions that are never called by the contract could be declared as `external`. `external` functions are more efficient than `public` functions.

Improper Usage of `public` and `external` Type

Addresses should be checked before assignment or external calls to make sure they are not zero addresses.

```solidity=30
authSigner = _authSigner;
```

```solidity=43
authSigner = _authSigner;
```



Missing Zero Address Validation

In the following scenario, one day's reward will be lost.

- User A holds an NFT with `tokenId = 1234` and pledges it into the `Peach` contract first time. The `stake()` function is called along with `ts` argument is 1646810910(a timestamp at 2022-03-09). After that, `stakedTime[1234]` equals 1646810910.

- When the `block.timestamp` equals 1647113310(3.5 days after staking), user A claims the rewards earned through pledging NFT with `tokenId = 1234`. The mathematical result at L111 ignores the decimal part because of the properties of the division operation. Finally, user A will get 3 days' rewards. After that, the `stakedTime[1234]` will be assigned 1647113310(3.5 days after staking).

- When the `block.timestamp` equals 1647545310(5 days after staking), user A claims the rewards earned through pledging NFT with `tokenId = 1234`. Because of ignoring the decimal part at L111, user A will get 1 day's reward.

- After 5 days of staking, user A should get 5 days' rewards but only gets `3 + 1 = 4` days' rewards.

Incorrect Rewards Calculation

The linked statements are used to mint `PEACH` token rewards to the stakers. There is no limitation of the `PEACH` token total supply because the `super._mint()` function is directly called. In this case, the issued `PEACH` token will exceed 250000000 ether.

Monkey Kingdom $PEACH

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

3

1

6