<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

The contract has an 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 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.
Examples:
- `pragma solidity ^0.5.0;` `Crowdsale.sol#1`
- `pragma solidity ^0.5.5;` `CybershinuToken.sol#2`

Unlocked Compiler Version & Version Inconsistency

In Ethereum, `send/transfer/call` can be used for ETH transferring. In the worst case, the fallback function can only rely on 2300 gas being available (for example when `send` or `transfer` is used), leaving little room to perform other operations except basic logging. 
Therefore, the callback function of the current contract is not suitable for doing much. It could be failed for not enough gas.

Potential fallback Function Failure

`public` functions that are never called by the contract could be declared `external`. When the inputs are arrays, `external` functions are more efficient than `public` functions.

Function Visibility Optimization

`initialSupply` tokens were sent to the `msg.sender` when deploying the contract. 
This could be a centralization risk as the deployer can distribute tokens without obtaining the consensus of the community.

Initial Token Distribution

In the contract `__unstable__TokenVault`, the role `_primary` has authority over the following functions:
- transfers contract to a new primary through `transferPrimary()`
- transfers tokens to anyone through `transfer()`

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

Leaderboards

Due Diligence Tools

Resources

KYC Status

Bug Bounty Program