DBTC security record

#### _owner In the contract `DBTCoinNew`, the privileged role `_owner` has authority over several functions. - launch() - setFeeWhiteList() - setSwapRouter() - setCurrency() - setSwapPairList() - setAntiSYNC() - setInSwap() - setTokenDistributor() - setBuyFundFee() - setBuyLPFee() - setBuyBurnFee() - setBuyMarketingFee() - setSellFundFee() - setSellLPFee() - setSellBurnFee() - setSellMarketingFee() - setSellReflowFee() - setReflowAmount() - setAddLiquidityFee() - setRemoveLiquidityFee() - setCurrencyIsEth() - setStartTradeBlock() - setMainPair() - setLastLpBurnTime() - setLpBurnRate() - setLpBurnFrequency() - setTradeFee() - setEnableOffTrade() - setTotalFundAmountReceive() - setFundAddress() - setBurnLiquidityAddress() - setDailyDropPercentage() - setOpeningPrice() - setLastUpdateTimestamp() - setClaims() - renounceOwnership() - transferOwnership() Any compromise to the privileged account may allow the hacker to take advantage of this authority, update the configuration of the contract, and transfer assets. #### fundAddress In the contract `DBTCoinNew`, the privileged role `fundAddress` has authority over several functions. - setClaims() Any compromise to the privileged account may allow the hacker to take advantage of this authority and transfer assets. --- In the updated version [0x9643C079291f36bAf1d4B2C9FB4657D4307A198a](https://bscscan.com/address/0x9643C079291f36bAf1d4B2C9FB4657D4307A198a#code), the privileged functions are changed as below. #### _owner - `Claims` - `setFeeWhiteList` - `setSwapPairList` - `setBuyFees` - `setSellFees` - `launch` - `setLastLpBurnTime` - `setLpBurnRate` - `setLpBurnFrequency` - `setTradeFee` - `setEnableOffTrade` - `setFundAddress` - `setBurnLiquidityAddress` - `setDailyDropPercentage` - `setOpeningPrice` - `setLastUpdateTimestamp` - `burnLiquidityPairTokens` #### burnLiquidityAddress - `burnLiquidityPairTokens` --- It is important to note that the functions `setDailyDropPercentage()`, `setOpeningPrice()`, and `setLastUpdateTimestamp()` allow the `_owner` role to set critical state variables: `dailyDropPercentage`, `openingPrice`, and `lastUpdateTimestamp`. These variables directly influence the calculation of the burn amount for each token transfer.

All of the `DBTC` tokens are sent to the hardcoded addresses, which are EOAs. This is a centralization risk because the accounts can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

The `autoBurnLiquidityPairTokens` function in the `DBTCoinNew` contract introduces a deflationary token burn mechanism. However, this feature creates arbitrage opportunities that can be exploited by attackers for profit. For example: 1. An attacker monitors the burn mechanism and identifies when a burn operation is about to occur. 2. The attacker front-runs this burn operation and purchases DBTC tokens at a lower price. 3. Once the burn operation is executed, the token supply decreases, leading to a price increase. 4. The attacker then sells the DBTC tokens at a higher price to secure a profit.

The `_tokenTransfer` function updates the `openingPrice` during sell transactions and calculates fees based on the daily drop percentage. However, the `getPrice()` function, which determines the `currentPrice`, is dependent on the pair's reserves, making it susceptible to manipulation by whale users or malicious actors. For example: 1. A whale may sell a large amount at the start of the period (24 hours), causing the `openingPrice` to be set based on the price before this sale. 2. As subsequent sellers observe the token price dropping, they begin to sell as well. The significant difference between the `openingPrice` and `currentPrice` results in a high `dailyDropPercentage`, leading to increased fees calculated by the `calculateFee` function. As a result, users who follow the actions of the whale may suffer financial losses due to the high fees.

The current implementation incorrectly calculates the `currencyAmount` during a token swap. The variable `before` captures the balance of this contract, while `_after` captures the balance of the `_tokenDistributor`. Given that the receiver of the swap is `_tokenDistributor`, the calculation of `currencyAmount` is inappropriate and incorrect. This can lead to incorrect distribution of the currency. ```solidity ... uint256 before = IERC20(currency).balanceOf(address(this)); try _swapRouter.swapExactTokensForTokensSupportingFeeOnTransferTokens( amount, _calculateSwapToCurrencyAmount(amount), path, address(_tokenDistributor), block.timestamp ) { uint256 _after = IERC20(currency).balanceOf(address(_tokenDistributor)); uint256 currencyAmount = _after - before; ... ```