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

<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

Name

Please input a title

Short description of the vulnerability and the affected asset.

The core team is situated in country(ies) that received low aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests an increased difficulty and complexity in preventing and mitigating fraud.

The core team is situated in country(ies) that received medium aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests a medium level of geographic accountability, thus reducing and mitigating the risk of fraud.

The core team is situated in country(ies) that received the best aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests the highest level of geographic accountability, thus maximizing the risk reduction and mitigation.

Vulnerability Title

transfer

transferFrom

totalSupply

balanceOf

allowance

approve

ERC20

TTMToken

In the contract `Ownable` 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 and transfer the ownership to an address that only they have access to or renounce the ownership.

![](https://accelerator-tasks-prod.s3.amazonaws.com/320cac307b6040d6b71c9c28819027bd/diagrams/centralization_TTMToken-Ownable-_owner.svg)

In the contract `TTMToken` 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 and do the following:
- set addresses as pairs causing them to be charged fee on buy and sell;
- remove a pair so that there is no fee when buying or selling using that pair;
- change the `feeTo` address to one they control to collect the fees for themselves;
  
![](https://accelerator-tasks-prod.s3.amazonaws.com/320cac307b6040d6b71c9c28819027bd/diagrams/centralization_TTMToken-TTMToken-_owner.svg)

Centralization Risks

All `TTM` tokens are sent to the contract deployer when deploying the contract. This is a potential centralization risk as the deployer can distribute `TTM` tokens without the consensus of the community.

Initial Token Distribution

When buying or selling the fees are transferred first to the `feeTo` address, then the `amount` minus the fees is sent to the `pair`. It is possible for the `feeTo` address to sell 1% more tokens than its current balance. While they are entitled to the 1% fee, this allows them to sell more than their balance at a given time.

`feeTo` Address Can Sell More Tokens Than They Own

Addresses are not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. For example, transferring tokens to a zero address can result in a permanent loss of those tokens.

```solidity=777
        feeTo = feeTo_;
```
- `feeTo_` is not zero-checked before being used.



Missing Zero Address Validation

The contract has a `receive()` function or payable functions, making it able to receive native tokens such as Ethers. However, it does not have a function to withdraw the funds, which can lead to permanently locked tokens within the contract.

```solidity=781
    receive() external payable {}
```



Locked Blockchain Native Tokens

State variables that never change should be declared as `constant` to save gas. The following variables are never changed and can be declared constant:

- RATE_DENOMINATOR;
- buyFeeRate;
- sellFeeRate;

State Variable Should Be Declared Constant

Currently the `buyFeeRate` and `sellFeeRate` are the same value. If this will always be the case, a single `rate` can be used allowing for the fee logic to be simplified by charging the fee if it is a buy or sell. This will reduce the contract deployment size by removing a storage variable and reduce gas costs when buying or selling as the `feeRate` does not need to be chosen.

Can Use Single Rate

When overriding the `_transfer()` function, in any case `super._transfer()` will be called. Thus it will check that the `from` and `to` address are not the zero address twice.

Redundant Checks

If the `feeRate` will be constant and less than the `RATE_DENOMINATOR`, as in the case with this implementation. Then
```solidity
fees = amount.mul(feeRate).div(RATE_DENOMINATOR) < amount
```
So that the fees are always less than the amount. Thus `amount - fees` cannot underflow and the `SafeMath` function `sub()` does not need to be used.

----

Similarly, `RATE_DENOMINATOR` should always be nonzero and in the current implementation is set to 10000. Thus when dividing by the `RATE_DENOMINATOR` the `SafeMath` function `div()` does not have to be used.

Unnecessary Use Of SafeMath

In the function `setFeeTo()`, the event `SetFeeTo` is emitted with the storage variable `feeTo` as opposed to the input `feeTo_`. As the storage variable is set to the input, the input can be used instead and saves 18 gas on each successful function call.

Event Can Use Input `feeTo_` To Save Gas

Solidity frequently releases new compiler versions with improved security features and bug fixes. Using an outdated version prevents access to these enhancements and may leave the smart contract vulnerable to known issues.

```solidity=752
pragma solidity >=0.6.0 <0.8.0;
```



Solidity Version Not Recommended

Some events are never emitted, which can lead to confusion and code maintainability issues.

```solidity=771
    event SetFee(uint256 buyFeeRate, uint256 sellFeeRate);
```
- `SetFee` is declared in `TTMToken` but never emitted.



Unused Event

Literals with many digits are difficult to read and review. When minting the initial supply `10000000000` is used.

```solidity=778
        _mint(msg.sender, 10000000000 * 10 ** 18);
```



Too Many Digits

TTMToken.sol

1Airdrop's goal is to provide a platform that helps investors find the most promising cryptocurrency airdrop projects while promoting the healthy development of the blockchain ecosystem.

Leaderboards

Due Diligence Tools

Resources

KYC Status

Bug Bounty Program