<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectLogo /><space /><projectName>{{ projectName }}</projectName>

Bug Bounty rewards are grouped by severity and the impact of the vulnerability. Examples and descriptions of the type of vulnerabilities that correspond to each severity level can be found below. The payout amount has a 5 tier structure with separate scalesfor website/apps and smart contracts.

Description of vulnerability and your proof of concept or validation steps

Short description of the vulnerability and the affected asset.

Vulnerability Title

`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

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, modifiers
- `UPPER_CASE`: Should be applied to `constant` variables
- `CapWords`: Should be applied to contract names, struct names, event names, and enums


Declaration Naming Convention

Multiple Solidity versions are used in the codebase.

Versions used: `^0.8.4`, `^0.8.0`

Different Solidity Versions

Comments Should Be in English

The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.

Variables That Could Be Declared as Immutable

`tx.origin` based protection can be abused by a malicious contract if a legitimate user interacts with the malicious contract.

According to the solidity documentation:

tx.origin: sender of the transaction (full call chain)

msg.sender: sender of the message (current call)

refer to : https://docs.soliditylang.org/en/v0.6.12/units-and-global-variables.html?highlight=tx.origin#block-and-transaction-properties

For a contract, the `tx.origin` is not transparent.
In a simple call chain A->B->C->D, inside D msg.sender will be C, and tx.origin will be A.
If the origin is really desired in D, then each of the functions in the contracts B, C, D could take an extra parameter to propagate the origin: A would pass its address (this) to B, B would pass the value to C, and C would pass it to D.
`tx.origin` based protection can be abused by a malicious contract if a legitimate user interacts with the malicious contract. Contracts that use the `tx.origin` to authorize users are vulnerable to phishing attacks. Hence it's not recommended to use tx.origin for authorization in solidity documentation.
refer to:
https://docs.soliditylang.org/en/v0.7.0/security-considerations.html#tx-origin

Dangerous Usage of `tx.origin`

In the contract `PLTToken` 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/109cf16589054f37a328b95530aca59d/diagrams/centralization_PLTToken__owner.svg)

Centralization Risks in PLTToken.sol

All of the 500000000 * (10**18) PLT tokens are sent to the contract deployer when deploying the contract. This could be a centralization risk as the deployer can distribute PLT tokens without obtaining the consensus of the community.

Initial Token Distribution

The return value of the transfer()/transferFrom() call is not checked.
```solidity
        ERC20(_tokenAddr).transfer(
            _to,
            ERC20(_tokenAddr).balanceOf(address(this))
        );
```



Unchecked ERC-20 `transfer()`/`transferFrom()` Call

Before `_listingFinished`, the `fee` is reduced from 100% to 0, hence the `fee` is almost 0 when `_listingDuration` is about to reach. However, once after `_listingFinished` became true, the fee would immediately be increased to `_getTransferFee(sender_, recipient_, amount_)`, as a result, users may choose to call `transferfrom()` at the end of `_listingDuration` to avoid charging fees.

The gap of the price

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

Missing Emit Events

The state variables `buyFee_`, `sellFee_` and `normalFee_` do not have reasonable upper boundaries. when they are equal to `DEMI`, the fee would be 100%, which is an unreasonable number.

Leaderboards

Due Diligence Tools

Resources