CertiK reviewed BurnedFi on 28 Dec 2023: 12 findings, 0 critical; none marked fixed.
The original report was removed from its address (seen 15 Oct 2026).
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 0 | 0 |
| Medium | 3 | 0 | 0 |
| Low | 9 | 0 | 0 |
If the `msg.value` does not strictly equal to 0.002 or the `burnedfi` has already launched, BNBs sent to the airdrop contract will be locked forever. ```solidity=918 function _drop() internal { address _msgSender = msg.sender; if(msg.value == _value && !_burnedFi.launch() && _msgSender != address(this)){ require(_msgSender == tx.origin, "Only EOA"); if(_countBlock <10){ ++_countBlock; ++totalDroped; ++threshold; if (totalDroped == 1 || totalDroped % 300 == 0) { _deployLiquidity(); } IERC20 token = IERC20(address(_burnedFi)); require(token.balanceOf(address(this)) >= _singleAmount, "Droped out"); token.transfer( _msgSender, _singleAmount); }else if(_block != block.number){ _block = block.number; _countBlock=0; } if(totalDroped>= 150000 ){ _burnedFi.setLaunch(true); uint256 amount = payable(address(this)).balance; payable(address(_burnedFi)).transfer(amount); } } } ``` Here is an example transaction that leads to locked BNBs: https://bscscan.com/tx/0x42894dc3129aa4bc3754d3159656dc976024b8ce893207caefebaf65885bb5b6
The contract's reliance on a single Dex pair for price feeds in the `burnToHolder` function exposes it to flashloan attack risks. An attacker can use a flashloan as the initial funds for an exploit to enlarge the profit or manipulate the `burnfi` token price in decentralized exchanges. ```solidity=1341 deserved = uniswapRouter.getAmountsOut(amount, path)[path.length - 1]; ``` The `burnToHolder()` function relies on price calculations that are based on-chain, meaning they are susceptible to flash-loan attacks by manipulating the price of given pairs to the attacker's benefit. In this case, the attacker could pump the `burnfi` token price to get more `burnbuild` tokens as returns in this function call.
The native token is transferred to the `receiver` (interaction) in line 1313 before the state variables are updated in lines 1315-1316 (effects), which deviates from the checks-effects-interaction pattern. This could lead to potential re-entrancy risks. Sending native tokens will trigger the `receive()` functions in the receiver contract. An attacker can make a recursive call back to the original function. During such a reentrant call, the state variables are not yet updated (the caller still holds `burnfi` token), enabling the attacker to re-enter the original contract and claim rewards multiple times. However, the `to.transfer()` call has a strict gas limit of 2300, which is typically insufficient for any significant computations or state changes in the called contract. This restriction constrains the actions an attacker can perform in the receiver's contract, thereby reducing the potential impact of the reentrancy attack, but the risk still exists. ```solidity=1306 function receiveRewards(address payable to) external { address addr = msg.sender; uint256 balance = balanceOf(addr); uint256 amount = balance.sub(burnAmount[addr]); //.sub(Rewards[addr]); require(amount > 0 ); Rewards[addr] = Rewards[addr].add(amount); historyRewards[addr] = historyRewards[addr].add(amount); to.transfer(amount.mul(10**9)); _transfer(addr, address(this), balance); burnAmount[addr]=0; totalReceive = totalReceive.add(amount); emit ReceiveReward(addr, amount, totalReceive); } ```
The event `OwnershipTransferred` has two parameters that demonstrate the ownership transfer between the `previousOwner` address and `newOwner` address. In the function `Lock()`, the `_owner` is changed to `address(0)` at Line 259, so the emitted `_owner` is the same as `address(0)` in the event which may contradict the purpose of this event.
A sandwich attack might happen when an attacker observes a transaction swapping tokens or adding liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (before the transaction being attacked) a transaction to purchase one of the assets and make profits by backrunning (after the transaction being attacked) a transaction to sell the asset. The following functions are called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large: ```solidity=1101 function swapTokensForEth(uint256 tokenAmount) private { // generate the uniswap pair path of token -> weth address[] memory path = new address[](2); path[0] = address(this); path[1] = uniswapRouter.WETH(); _approve(address(this), address(uniswapRouter), tokenAmount); // make the swap uniswapRouter.swapExactTokensForETHSupportingFeeOnTransferTokens( tokenAmount, 0, // accept any amount of ETH path, address(this), block.timestamp ); } ```
```solidity=925 if (totalDroped == 1 || totalDroped % 300 == 0) { _deployLiquidity(); } ``` Users have to pay for the gas of adding liquidity if the condition `totalDroped % 300 == 0` is met. If the user fails to set enough gas limit for this transaction, calls to the `_drop()` will revert and therefore block the airdrop process. Here is an example of a blocked transaction: https://bscscan.com/tx/0x06343bc779f0ce427f7005ae0d8305d0cbe712eb85db4ba35a4310b810ee4a17
State variables that never change should be declared as `constant` to save gas. ```solidity=981 uint256 public burnFee = 1; ``` - `burnFee` should be declared `constant`.
The `burnedFi` contract is serving as the underlying entity to interact with third party Automated Market Maker protocols PancakeSwap. The scope of the audit treats 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc.
The `SafeMath` library is used unnecessarily. With Solidity compiler versions 0.8.0 or newer, arithmetic operations will automatically revert in case of integer overflow or underflow. --- ```solidity=757 using SafeMath for uint256; ``` - `SafeMath` library is used for `uint256` type in `burnBuild` contract. --- ```solidity=898 using SafeMath for uint256; ``` - `SafeMath` library is used for `uint256` type in `burnAirdrop` contract. --- ```solidity=978 using SafeMath for uint256; ``` - `SafeMath` library is used for `uint256` type in `burnedFi` contract.
The smart contract does not check or store the return value of an external call in a local or state variable, which may introduce vulnerabilities due to the unhandled outcome. --- ```solidity=958 uniswapRouter.addLiquidityETH{value: ethAmount}( address(_burnedFi), tokenAmount, 0, // slippage is unavoidable 0, // slippage is unavoidable address(0xdead), block.timestamp ); ```
It is not recommended to use Solidity's `transfer()` and `send()` functions for transferring native tokens, 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=939 payable(address(_burnedFi)).transfer(amount); ``` - `burnAirdrop._drop` uses `transfer()`. --- ```solidity=1146 payable(address(burnHolder)).transfer(balance); ``` - `burnedFi.burnToholder` uses `transfer()`.
The linked functions are equivalent to the compiler-generated getter functions for the respective variables.
| Address | Chain | Source code |
|---|---|---|
| 0x19c0…98a40x19c018e13cff682e729cc7b5fb68c8a641bf98a4 | Chain: BNB Chain | Source code: Verified source |
| 0xb471…9c7f0xb47174c19a9761eee0c3ae85ef189bf3fd329c7f | Chain: BNB Chain | Source code: Verified source |
1,044 projects reviewed · 1,393 reports · latest May 2025
See CertiK’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us