Read the findings of the 2022 Web3 Security Report

The comment suggests that `liquidityAlloc` should be 3% while `liquidityAlloc` is set to 3750.

Incorrect percent

The linked variables could be declared as `constant` since these state variables are never modified.

Variables that could be declared as `constant`

The contract has 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 different compiler versions. This can lead to an 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.

Unlocked compiler version

Events should always be emitted in sensitive functions that are controlled by centralization roles.

Missing emit events

According to the comment, the recipient of BUSD should be the contract but instead the recipient is always the address set in `marketWallet`.  

Inconsistent Comments and Code

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:

- `_swapTokensForBUSD()`
- `_swapTokensForBNB()`
- `_addLiquidity()`

Potential Sandwich Attacks

The linked functions are `external` functions making external calls to a contract that is not part of the scope of this audit. Functions defined like such introduce great risk to the contract since volatile code introduce an attack.

External Dependency

In the contract, `Sing`, the role, `_owner`, has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set the transaction fees to 100% maximize theft.

**Summary of Attack**
Suppose Oscar compromises the owner role. Oscar would
1.) Call the functions `setMarketWallet` and `setLiquidityLocker` to set his address to `marketWallet` and `liquidityLocker` so that whenever a transfer takes place his address receive the fees.
2.) Then call the function `setMinimumTokensBeforeSwap()` to set the variable `minimumTokensBeforeSwap` to zero so that whenever a transfer takes place the contract will automatically liquidate some of its tokens. 
3.) Set the `buyTax`, `sellTax`, `liquidityAlloc` to 100% to maximize profits. 

![](https://accelerator-tasks-prod.s3.amazonaws.com/0b53975d7d57498fa62b56b801b2f388/diagrams/centralization-Sing-_owner.svg)

Centralization Risk in Sing.sol

The linked functions do contain logic that sets a bound on how high the fees could be set to. If a hacker compromises the hacker role then they could set the fees to 100% to aid them in stealing as many funds as they can.

No Bound On Fees


The following functions are declared as `public`, contain array function arguments, and are not invoked in any of the contracts contained within the project's scope:

- `excludeFromFee()`
- `includeInFee()`

The functions that are never called internally within the contract should have external visibility. 

Function Visibility Optimization

Sing

Sing.sol

contracts

Sing

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

2

1

7