DigiVerse - Audit Addendum

In the contract `DIGIVERSE` 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 include/exclude address from fees, enable/disable swap and liquify process, change threshold for triggering swap and liquify process, transfer ETH or tokens out of the contract, change marketing wallet address and change configuration for antisnipe.  In the contract `Ownable` 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 transfer/renounce the ownership of the contract. 

All of the swapped native tokens are sent to the marketing wallet. This imposes a centralization risk. Any compromise to the address may allow a hacker to transfer those tokens from the address, resulting in severe damage to the project.

All of the DIGI tokens are sent to the contract deployer. This is a centralization risk because the deployer 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.

A sandwich attack may 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 (executing before the target) a transaction to purchase one of the assets and make profits by backrunning (executing after the target) a transaction to sell the asset. The following function is 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: - `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens`

The antisnipe feature is specifically disabled in function `swapAndLiquify`. This function is used for swapping DIGI token in the token contract to native tokens. This indicates that the following line may return false: ```solidity= antisnipe.assureCanTransfer(token_contract_address, from, to, amount); ```

Users will pay fees when buying or selling tokens. In this project, it seems that users will only pay fees when buying/selling tokens and does not have anything in return, which does not incentivize users purchasing tokens in the first place.

It is observed that on some chains, some DIGI tokens are locked in Pinksale, while others are not. We would like to confirm if it is the intended design.

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects. ### External call(s) ```solidity=698 _transfer(sender, recipient, amount); ``` * This function call executes the following external call(s). * In `DIGIVERSE.transferToAddressETH`, * `(succ,None) = recipient.call{value: amount}("")` * In `DIGIVERSE.swapTokensForEth`, * `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens(tokenAmount,0,path,address(this),block.timestamp)` * In `DIGIVERSE._transfer`, * `antisnipe.assureCanTransfer(msg.sender,from,to,amount)` ### State variables written after the call(s) ```solidity=699 _approve(sender, _msgSender(), currentAllowance - amount); ``` * This function call executes the following assignment(s). * In `DIGIVERSE._approve`, * `_allowances[_owner][spender] = amount` --- ### External call(s) ```solidity=749 antisnipe.assureCanTransfer(msg.sender, from, to, amount); ``` ```solidity=763 swapAndLiquify(); ``` * This function call executes the following external call(s). * In `DIGIVERSE.transferToAddressETH`, * `(succ,None) = recipient.call{value: amount}("")` * In `DIGIVERSE.swapTokensForEth`, * `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens(tokenAmount,0,path,address(this),block.timestamp)` ### State variables written after the call(s) ```solidity=773 _tokenTransfer(from, address(this), fee); ``` * This function call executes the following assignment(s). * In `DIGIVERSE._tokenTransfer`, * `_tOwned[sender] -= amount` * In `DIGIVERSE._tokenTransfer`, * `_tOwned[recipient] += amount` ```solidity=777 _tokenTransfer(from, to, amount); ``` * This function call executes the following assignment(s). * In `DIGIVERSE._tokenTransfer`, * `_tOwned[sender] -= amount` * In `DIGIVERSE._tokenTransfer`, * `_tOwned[recipient] += amount`

Based on the naming, the auditor assumes that `marketingTokensCollected` represents how many tokens are there in the contract, `totalMarketingTokensCollected` represents how many tokens has been/will be swapped to ETH and send to the marketing wallet. In rare cases where tokens are directly sent to the contract, these tokens are swapped to ETH but not considered in these two variables.

Function `swapETHForTokens` is never used in this contract. And it is unclear how does this function served as a fallback to the `swapAndLiquify`.