<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

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

Initial Token Distribution

In the contract A53.sol, the role `owner` has authority over the functions shown in the diagram below. 
- `renounceOwnership()`
- `transferOwnership(address newOwner)`
- `grantVestingTokens(address beneficiary, uint256 totalAmount, uint256 vestingAmount, uint32 startDay, uint32 duration, uint32 cliffDuration, uint32 interval, bool isRevocable)`
- `revokeGrant(address grantHolder)`
- `mint(uint256 amount)`

Any compromise to the `owner` account may allow a hacker to take advantage of this authority and take ownership of the whole contract.

Centralization Related Risks

Mathematical operations in the aforementioned function perform divisions before multiplications. Performing multiplication before division can sometimes avoid loss of precision.

Division Before Multiplication

Lack of check available balance for the `burn` function.

Lack of check available balance

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

Detects expressions that are tautologies or contradictions.

```solidity
      require(
          (interval >= 1) 
          && (cliffDuration >= 0)
          && (duration >= (interval + cliffDuration)) 
          && (duration <= TEN_YEARS_DAYS),
          "invalid vesting schedule"
      );
```

`cliffDuration` is a `uint32`, so `cliffDuration >= 0` will be always true.

Tautology or contradiction

In the source file whose shasum256 is f0a5e0dd19bdfd1ecb94cf0159f2856c2393aa16275c104f808218eb87c5bd27, the multi-sign transaction could transfer tokens from any user by specifying arbitrary `_from` address in the `submitMulSigTx` function. Is that designed as expected?


The `_from` address that to transfer token

In the source file whose shasum256 is f0a5e0dd19bdfd1ecb94cf0159f2856c2393aa16275c104f808218eb87c5bd27, a owner could work around the check on `numSignatures` as shown in the below example:
Assuming that there are 3 owners: Alice, Bob and Carol.
- Alice submits a transaction A to mint tokens to Alice.
- Alice signs the transaction.
- Alice submits and signs a new transaction B to transfer the ownership to the new owner Dick.
- Bob or Carol signs the transaction B and Dick becomes the new owner.
- Dick signs the transaction A and Alice gets the tokens.

There is a possible that Alice and Dick may be the same person and Bob and Carol may do not have knowledge about it and the transaction A.

A way to work around the check on `numSignatures`

The balance of a user contains the not-vested amount, however, the amount of token able to transfer is the balance deducted from the not-vested amount. It may cause some disturbance to a user who fails to transfer all the balance if the user has no knowledge of the not-vested amount.

The amount of token a user able to transfer

Missing input validation in the `getMulSigTxByIndex()` function for variable `_txIndex`. the `_txIndex` parameter may out of bound.

Leaderboards

Due Diligence Tools

Resources

KYC Status