UltronVault

In the contract `Ownable` the role `_owner` has authority over the functions shown in the diagram below.  - `renounceOwnership()`: This function allows the current owner to relinquish ownership of the contract. Once executed, the ownership is transferred to the zero address, indicating that there is no owner. This function can only be called by the owner of the contract. - `transferOwnership(address newOwner)`: This function allows the current owner to transfer the ownership of the contract to a new owner. The new owner's address must not be a zero address. This function can only be called by the owner of the contract. In the contract `ULTRON` the role `_owner` has authority over the functions shown in the diagram below.  - `excludeFromReward(address account)`: This function allows the contract owner to exclude a specific account from receiving rewards. The account must not be already excluded. If the account holds any reflective tokens, they are converted to standard tokens. This function can only be called by the owner of the contract. - `includeInReward(address account)`: This function allows the contract owner to include an account in receiving rewards. The account must be currently excluded from rewards. The function removes the account from the list of excluded accounts, sets the number of their owned standard tokens to zero, and enables them to receive rewards again. This function can only be called by the owner of the contract. - `claimStuckTokens(address token)`: This allows the contract owner to transfer any ERC20 token sent in the contract to the owner's address. The only exception is that the owner can't claim the contract's own tokens. This function can only be called by the owner of the contract. - `excludeFromFees(address account, bool excluded)`: Similar to the previous excludeFromFees function, this function allows the contract owner to set whether a specific account is excluded from fees. The status of an account (excluded or not) can be updated by the owner of the contract. 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.

All initial `ULTRON` tokens are sent to the contract deployer by the following statement when deploying the contract. This is a potential centralization risk as the deployer can distribute `ULTRON` tokens without the consensus of the community. ```solidity=425 _rOwned[owner()] = _rTotal; ```

Generally, deflationary tokens are incompatible with DEX and special rules need to be coded for DEX addresses eg. excluding them from reward. Otherwise, a hacker can exploit the protocol using the reflection mechanism. The balance of accounts that include rewards is calculated by `rAmount/rate`, where the rate is determined base on the total supply. If the `deliver()` function is executed with significant input, it can significantly decrease `rTotal`, thereby allowing for manipulation of the rate.

The function below has a known bug: ```solidity=525 function includeInReward(address account) external onlyOwner() { require(_isExcluded[account], "Account is already included"); for (uint256 i = 0; i < _excluded.length; i++) { if (_excluded[i] == account) { _excluded[i] = _excluded[_excluded.length - 1]; _tOwned[account] = 0; _isExcluded[account] = false; _excluded.pop(); break; } } } ``` Variable `_rOwned[account]` is not updated in the function `includeInReward()`, which will make the accounts included siphon off the tokens out of the balances of all token holders. The Rate was higher at the moment of the `excludeFromReward(account)` call, so the `_rOwned[account] / _tOwned[account]` ratio is bigger than expected for accounts included in the reward.

The condition `!_isExcluded[sender] && !_isExcluded[recipient]` can be included in `else` .

State variables that never change should be declared as `constant` to save gas. ```solidity=353 string private _name = "Ultron Vault"; ``` - `_name` should be declared `constant`. --- ```solidity=354 string private _symbol = "ULTRON"; ``` - `_symbol` should be declared `constant`. --- ```solidity=355 uint8 private _decimals = 18; ``` - `_decimals` should be declared `constant`. --- ```solidity=377 address private DEAD = 0x000000000000000000000000000000000000dEaD; ``` - `DEAD` should be declared `constant`.

The return value of the transfer()/transferFrom() call is not checked. ```solidity=548 ERC20token.transfer(msg.sender, balance); ```

One or more state variables are never used in the codebase. Variable `DEAD` in `ULTRON` is never used in `ULTRON`. ```solidity=377 address private DEAD = 0x000000000000000000000000000000000000dEaD; ``` ```solidity=341 contract ULTRON is Context, IERC20, Ownable { ```

It is not recommended to use Solidity's `transfer()` and `send()` functions for transferring Ether, since some contracts may not be able to receive the funds. Those functions forward only a fixed amount of gas (2300 specifically) and the receiving contracts may run out of gas before finishing the transfer. Also, EVM instructions' gas costs may increase in the future. Thus, some contracts that can receive now may stop working in the future due to the gas limitation. ```solidity=543 payable(msg.sender).transfer(address(this).balance); ``` - `ULTRON.claimStuckTokens` uses `transfer()`.

```solidity uint256 public taxFeeonBuy; uint256 public taxFeeonSell; uint256 private liquidityFeeonBuy; uint256 private liquidityFeeonSell; uint256 public marketingFeeonBuy; uint256 public marketingFeeonSell; address public marketingWallet; address public uniswapV2Pair; ``` The above variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.