DBTC security record

The `autoBurnLiquidityPairTokens` function uses `super.transferFrom` to transfer `DBTC` tokens from the pair address to a dead address. However, the function may revert due to insufficient allowance. Since `_mainPair` refers to the deployed pair address for `DBTC` and the `currency`, there is no method to set `allowance[_mainPair][address(this)]` within the `_mainPair` contract, which is required for `super.transferFrom` to execute successfully. As a result, whenever the `fundAddress` calls the `burnLiquidityPairTokens` function to burn tokens from the pair address, the transaction will revert.

The `burnLiquidityPairTokens` function is designed to burn `DBTC` tokens in the liquidity pair to potentially increase the value of `DBTC`. However, the function lacks proper access control, allowing any user to call it. Below is the relevant code snippet: ```solidity function burnLiquidityPairTokens() external { require(block.timestamp >= lastLpBurnTime + lpBurnFrequency, "Not yet"); autoBurnLiquidityPairTokens(); } ``` In contrast, the `_tokenTransfer` function restricts this operation to only be triggered by `sender == burnLiquidityAddress`. The absence of similar access control in `burnLiquidityPairTokens` allows any user to exploit this function, potentially manipulating the market to increase their profit from buying or selling `DBTC` tokens.

The `_tokenTransfer` function applies fees for both adding and removing liquidity, which can lead to users being charged both fees simultaneously. Below is the relevant code snippet: ```solidity if (isAdd || isRemove) { if (addLiquidityFee > 0) { uint256 fee = amount * addLiquidityFee / 10000; amount -= fee; _basicTransfer(sender, address(this), fee); } if (removeLiquidityFee > 0) { uint256 fee = amount * removeLiquidityFee / 10000; amount -= fee; _basicTransfer(sender, address(this), fee); } } ``` In scenarios where `isAdd` is true (indicating an adding liquidity transaction) and both `addLiquidityFee` and `removeLiquidityFee` are greater than zero, the contract will apply both fees. This results in an incorrect fee deduction, causing user's financial loss.

The `_isAddLiquidity()` function exhibits inaccuracies under specific conditions, making it difficult to determine if liquidity is being added or removed within a single transaction. 1. The returned result may vary depending on whether the token is token0 or token1 in the pair. 2. The returned result may also vary depending on whether the caller uses the Uniswap router or directly invokes the pair's `swap()`, `mint()`, or `burn()` functions. Executing a swap similar to a flash loan through the [linked code logic](https://github.com/Uniswap/v2-core/blob/1136544ac842ff48ae0b1b939701436598d74075/contracts/UniswapV2Pair.sol#L172) may allow an arbitrager to bypass the `_isAddLiquidity` check. Due to this misjudgment, the caller may avoid paying fees or gain other undue profits. The `_isRemoveLiquidity()` function has a similar issue.

The modifier `lockTheSwap` is never used and therefore can cause the contract to be vulnerable to potential reentrancy attacks when swaps and transfers are being processed.

The `_tokenDistributor` acts as an intermediary to transfer the swapped `currency` to `address(this)`. If the allowance of `address(this)` is not correctly set in the new `distributor` contract, the `transferFrom` method will revert. ```solidity _swapRouter.swapExactTokensForTokensSupportingFeeOnTransferTokens( half, 0, path, address(_tokenDistributor), block.timestamp ) {} catch { emit Failed_swapExactTokensForTokensSupportingFeeOnTransferTokens(half); } uint256 newBal = _c.balanceOf(address(_tokenDistributor)); if (newBal != 0) { _c.transferFrom(address(_tokenDistributor), address(this), newBal); } ```

It is expected that the `balanceOf` function always succeeds, assuming that its execution does not run out of gas. However, the implementation of `balanceOf` in contract `DBTCoinNew` will revert in the following case: ```solidity if (account == _mainPair && msg.sender == _mainPair && antiSYNC) { require(super.balanceOf(_mainPair) > 0, "!sync"); } ``` Additionally, the `antiSYNC` variable can not completely prevent the price manipulation.

The comment in the `calculateFee` is not consistent with the code. ```solidity function calculateFee(uint256 amount) public view returns (uint256 burnAmount) { if (dailyDropPercentage <= 500) { return (0); // 正常10%划点 } else if (dailyDropPercentage <= 1000) { return (amount * 500 / 10000); // 划点15%，其中5%销毁 } else if (dailyDropPercentage <= 1500) { return (amount * 1000 / 10000); // 划点20%，其中10%销毁 } else if (dailyDropPercentage <= 2000) { return (amount * 1500 / 10000); // 划点25%，其中15%销毁 } else if (dailyDropPercentage <= 3000) { return (amount * 2000 / 10000); // 划点30%，其中20%销毁 } else if (dailyDropPercentage <= 4000) { return (amount * 2500 / 10000); // 划点35%，其中25%销毁 } else { return (amount * 2500 / 10000); // 划点35%，其中25%销毁 } } ```

In the constructor, the token contract approves the router with the maximum allowance using the following code snippet: ```solidity IERC20(currency).approve(address(_swapRouter), MAX); ``` However, when the currency is updated, the relevant allowance is not updated accordingly. This can cause swap operations to fail since the new currency might not have the appropriate allowance set for the router.

The cited addresses input lack a validation check to ensure they are not `address(0)`. This omission may result in the relevant addresses being set to an incorrect value, potentially causing adverse effects on the project.