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

![](https://accelerator-tasks-prod.s3.amazonaws.com/e57f46d056754a0388bbed580cb2c47c/diagrams/centralization_Ownable__owner.svg)

---


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

![](https://accelerator-tasks-prod.s3.amazonaws.com/e57f46d056754a0388bbed580cb2c47c/diagrams/centralization_S2K__owner.svg)


Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and update the sensitive settings and execute sensitive functions of the project.

Centralization Risks in S2K.sol

```solidity
// add the liquidity
router.addLiquidityETH{value: bnbAmount}(
    address(this),
    tokenAmount,
    0, // slippage is unavoidable
    0, // slippage is unavoidable
    owner(),
    block.timestamp
);
```

The `addLiquidity` function calls the `router.addLiquidityETH` function with the `to` address specified as `owner()` for acquiring the generated LP tokens from the `S2K-BNB` pool. As a result, over time the `_owner` address will accumulate a significant portion of LP tokens. If the `_owner` is an EOA (Externally Owned Account), mishandling of its private key can have devastating consequences to the project as a whole.

Centralized Risk in `addLiquidity`

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:

- `router.swapExactTokensForETHSupportingFeeOnTransferTokens()`

Potential Sandwich Attacks

According to current design, the total percentages of `_marketing` and `_liquidity` must not be greater than 100 in both `taxes` and `sellTaxes`. There are no validations to guarantee these in the functions `setTaxes()` and `setSellTaxes()`.

Lack of Input Validation

The `swapForFees()` function converts part of the S2K tokens to BNB. The rest part of S2K tokens and part of the converted BNB are deposited into the S2K-BNB pool on pancakeswap as liquidity. For every `swapTokensForBnb()` function call with a default setting of `sellTaxes.marketing` and `sellTaxes.liquidity`(Taxes(2,2);), a small amount of BNB and a small amount of S2K will be leftover in the contract. The contract appears to provide a way to withdraw those BNB and S2K to the `owner()` address

Leftover Tokens Caused by Unoptimized One-Sided Supply.

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Missing Emit Events

The comment describing the `swapForFees()` function is inaccurately set to as below:
```solidity
// Split the contract balance into halves
```
According to implementation in L480-L482, contract balance will not be necessarily split into halves.

Sports 2K75

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

7

0

7

0

0