Read the findings of the 2022 Web3 Security Report

An owner is possible to gain ownership of the contract even if he calls function `renounceOwnership` to renounce the ownership. This can be achieved by performing the following operations:
1. Call `lock` to lock the contract. The variable `_previousOwner` is set to the current owner.
2. Call `unlock` to unlock the contract.
3. Call `renounceOwnership` to leave the contract without an owner. 
4. Call `unlock` to regain ownership.

Possible to Gain Ownership after Renouncing the Contract Ownership

All of the `BuyBackToken` tokens are sent to the contract deployer 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

The following functions are declared as `public` and are not invoked in any of the contracts contained within the project's scope. The functions that are never called internally within the contract should have external visibility. 

- `name()`
- `symbol()`
- `decimals()`
- `transfer()`
- `allowance()`
- `approve()`
- `transferFrom()`
- `increaseAllowance()`
- `decreaseAllowance()`
- `isExcludedFromReward()`
- `totalFees()`
- `minimumTokensBeforeSwapAmount()`
- `buyBackUpperLimitAmount()`
- `deliver()`
- `reflectionFromToken()`
- `excludeFromReward()`
- `isExcludedFromFee()`
- `excludeFromFee()`
- `includeInFee()`
- `setBuyBackEnabled()`

Function Visibility Optimization

Private function `addLiquidity` does not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.

Redundant Function

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:

- `swapTokensForEth()`
- `swapETHForTokens()`

Potential Sandwich Attacks

The contract is serving as the underlying entity to interact with third party `PancakeSwap` protocols. 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.

Third Party Dependencies

In the contract `BuyBackToken`, the role `owner` has authority over the following functions:
- `excludeFromReward()`
- `includeInReward()`
- `excludeFromFee()`
- `includeInFee()`
- `setTaxFee()`
- `setBuybackFee()`
- `setMaxTxAmount()`
- `setMarketingFee()`
- `setNumTokensSellToAddToLiquidity()`
- `setBuybackUpperLimit()`
- `setMarketingAddress()`
- `setSwapAndLiquifyEnabled()`
- `setBuyBackEnabled()`
- `presale()`


Any compromise to the `owner` account may allow a hacker to take advantage of this authority and manipulate fee rate and fee addresses, include and exclude any user from reward or fees, enter "presale mode", and reset other important state variables. 

Centralization Related Risks

The variable `_tTotal`, `_name`, `_symbol` and `_decimals` assigned in the constructor can declare with `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 will not be stored in storage. Still, values will directly insert the values into the runtime code.

On the other hand, immutable variable `deadAddress` can be declared as constant. Its value is never changed, nor is it assigned in constructor. 

Variable Declare as Immutable or Constant

The error message in `require(_isExcluded[account], "Account is already excluded")` does not describe the error correctly.

Incorrect error message

In the `_transfer()` function of `BuyBackToken`, the balance of `BuyBackToken` is swapped to BNB. Part of the BNB is sent to dappbuilderAddress and marketingAddress as fees. For what's left, the contract takes 1% to swap back to `BuyBackToken` and burn it. This means that the other 99% will be left in contract, and there's no way to retrieve it. 

SafeMoneyBSC

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

10

0

10

0

0