Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
BNB Token security audit report

BNB Token security audit report


This is the report from a security audit performed on BNB Token by gorbunovperm.

Audit of Top 200 CoinMarketCap tokens.

In scope

  1. bnb.sol


In total, 4 issues were reported including:

  • 0 high severity issue.

  • 0 medium severity issues.

  • 4 low severity issues.

  • 0 minor observations.

Security issues

1. Known vulnerabilities of ERC-20 token

Severity: low


  • It is possible to double withdrawal attack. More details here

  • Lack of transaction handling mechanism issue. WARNING! This is a very common issue and it already caused millions of dollars losses for lots of token users! More details here


Add into a function transfer(address _to, ... ) following code:

require( _to != address(this) );

2. ERC20 Compliance — event missing

Severity: low

Code snippet

  1. initial supply
  2. Approval event
  3. burn function and Transfer event


  1. According to ERC20 standard when coins are minted a Transfer event should be emitted.

  2. There is no Approval event call at approve function. And EIP20 says:

MUST trigger on any successful call to approve(address _spender, uint256 _value).

  1. The burn function also should emit the Transfer event.

3. ERC20 Compliance — zero-value transfers rejecting

Severity: low

Code snippet


EIP20 says that:

Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event. But in this contract, function transfer has a condition:

if (_value <= 0) throw;

4. ERC20 Compliance — approve issues

Severity: low

Code snippet


  1. There is no way to reset approved value to 0, because approve function contains:
if (_value <= 0) throw; 
  1. Also it breaks the EIP20 security recommendation:

To prevent attack vectors like the one described here and discussed here, clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to 0 before setting it to another value for the same spender. THOUGH The contract itself shouldn't enforce it, to allow backwards compatibility with contracts deployed before


There are some vulnerabilities were discovered in this contract.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment