The Binance Coin (BNB) token, initially issued as an exchange token by Binance, is the native asset of the BNB Beacon Chain and the BNB Smart Chain. BNB was migrated to BNB Beacon Chain in 2019 and became the utility token and native main asset of the Beacon Chain under the BEP-2 token standard. In 2020, BNB was migrated to the BNB Smart Chain and became the utility token and native main asset of the BNB Smart Chain under the BEP-20 token standard, which shares similarities to the ERC-20 standard for fungible tokens.
Low | Medium | High | Critical | Total | |
---|---|---|---|---|---|
Not fixed | 9 | - | 1 | - | 10 |
Fixed | - | - | - | - | 0 |
Total | 9 | 0 | 1 | 0 | 10 |
not_fixed/high
In the contract `BNB`, the role `owner` has authority over the function. Any compromise to the `owner` account may allow a hacker to take advantage of this authority and withdraw all BNB stored in the contract. It is worth mentioning that no function to update the owner's address was found to be implemented.
not_fixed/low
Usage of `throw` should be replaced with `revert()`.
not_fixed/low
The `BNB` contract has some references to `ETH` instead of `BNB` even though it is deployed on the Binance Smart Chain (BSC).
not_fixed/low
Functions that update state variables should emit relevant events as notifications.
not_fixed/low
The linked statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.
not_fixed/low
A user-defined component is shadowing a built-in symbol. ```solidity=31 function assert(bool assertion) internal { ``` - Function `assert` is shadowing a built-in symbol.
not_fixed/low
Solidity frequently releases new compiler versions. Using an old version prevents access to new Solidity security features. We also recommend avoiding complex `pragma` statements. The pragma statement in use allows old versions and it is not locked: ```solidity=1 pragma solidity ^0.4.8; ```
not_fixed/low
```solidity=89 returns (bool success) { ``` - The function `approve` implicitly returns and never writes the return variable `success`. --- ```solidity=97 function transferFrom(address _from, address _to, uint256 _value) returns (bool success) { ``` - The function `transferFrom` implicitly returns and never writes the return variable `success`. --- ```solidity=110 function burn(uint256 _value) returns (bool success) { ``` - The function `burn` implicitly returns and never writes the return variable `success`. --- ```solidity=119 function freeze(uint256 _value) returns (bool success) { ``` - The function `freeze` implicitly returns and never writes the return variable `success`. --- ```solidity=128 function unfreeze(uint256 _value) returns (bool success) { ``` - The function `unfreeze` implicitly returns and never writes the return variable `success`.
not_fixed/low
It is not recommended to use Solidity's `transfer()` and `send()` functions for transferring ETH, since some contracts may not be able to receive the funds. Those functions forward only a fixed amount of gas (2300 specifically) and the receiving contracts may run out of gas before finishing the transfer. Also, EVM instructions' gas costs may increase in the future. Thus, some contracts that can receive now may stop working in the future due to the gas limitation. ```solidity=140 owner.transfer(amount); ``` - `withdrawEther()` uses `transfer()`.
not_fixed/low
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.
# | Chain | Address | Scanner |
---|---|---|---|
1 | Ethereum | 0xb8c77482e45f1f44de1745f52c74426c631bdd52 | Check on Etherscan |