HODL security record

The contract `HodlToken` extends from `Ownable` contract, the `owner` role has authority over the following functions: - `transferOwnership`: Transfers ownership of the contract to a new address. - `renounceOwnership`: Renounces the ownership of the contract. In the contract `HodlToken`, - the role `feeSetter` has authority over the following functions: - `setTaxRates`: Sets the tax rates. - `changeFeeSetter`: Changes the address of `feeSetter`. - `initTax`: Initializes all the tax rates. - `normalizeTax`: Sets all the tax rates to the default values. - the role `whiteListSetter` has authority over the following functions: - `setPair`: Adds or removes an address from the pairs mapping. - `setSenderWhitelist`: Adds or removes an address from the sender whitelist. - `setRecipientWhitelist`: Adds or removes an address from the recipient whitelist. - `setCallerWhitelist`: Adds or removes an address from the caller whitelist. - `setFullWhitelist`: Adds or removes an address from all the whitelists. - `changeWhiteListSetter`: Changes the address of `whiteListSetter`. - the role `owner` has authority over the following functions: - `changeFeeSetter`: Changes the address of `feeSetter`. - `changeFeeToSetter`: Changes the address of `feeToSetter`. - `changeWhiteListSetter`: Changes the address of `whiteListSetter`. - `initTax`: Initializes all the tax rates. - `normalizeTax`: Sets all the tax rates to the default values. - the role `feeToSetter` has authority over the following functions: - `setAddresses`: Sets the pool address and the developer address. - `changeFeeToSetter`: Changes the address of `feeToSetter`. Any compromise of the privileged accounts may allow a hacker to exploit this authority, whitelist their own account, manipulate the tax rate, and impose exorbitant taxes on users, thereby inflicting significant harm on the entire project.

`210_000_000_000_000_000 * 1e6` `HODL` 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.

In the `HodlToken` smart contract, the `_transfer` function has been modified to include a tax mechanism for token transfers. This tax is applied unless the caller, sender, or recipient is on a whitelist. When a non-whitelisted transfer occurs and the total tax rate is greater than zero, the contract calculates the tax and distributes it as follows: - A portion of the tax is burned. - A portion is allocated to a pool. - A portion is designated for the developer. The respective amounts are calculated based on their individual tax rates in relation to the total tax rate. However, due to the truncation that occurs with Solidity's division, a small amount of tokens, known as "dust," may remain in the contract. Currently, there is no direct method to remove these residual tokens, which means they could become permanently locked within the contract.

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=799 try jackpot.tradeEvent(sender, amount) {} catch {} ``` ### State variables written after the call(s) ```solidity=802 super._transfer(sender, recipient, amount); ``` * This function call executes the following assignment(s). * In `ERC20._transfer`, * `_balances[from] = fromBalance - amount` * In `ERC20._transfer`, * `_balances[to] += amount`

According to the function name `burn`, the function should burn tokens as requested by the caller and reduce the total supply of this token. However, within this `burn` function, the `_transfer` method of the parent contract is called, which transfers the tokens to a dead address rather than performing a `_burn` operation. Consequently, this does not reduce the total supply of the token.

Addresses are not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. For example, transferring tokens to a zero address can result in a permanent loss of those tokens. ```solidity=755 poolAddress = _poolAddress; ``` - `_poolAddress` is not zero-checked before being used. --- ```solidity=756 developerAddress = _developerAddress; ``` - `_developerAddress` is not zero-checked before being used. --- ```solidity=757 jackpot = IJackpot(_jackpot); ``` - `_jackpot` is not zero-checked before being used. --- ```solidity=831 poolAddress = _poolAddress; ``` - `_poolAddress` is not zero-checked before being used. --- ```solidity=832 developerAddress = _developerAddress; ``` - `_developerAddress` is not zero-checked before being used. --- ```solidity=833 jackpot = IJackpot(_jackpot); ``` - `_jackpot` is not zero-checked before being used. --- ```solidity=865 feeSetter = _new; ``` - `_new` is not zero-checked before being used. --- ```solidity=871 feeToSetter = _new; ``` - `_new` is not zero-checked before being used. --- ```solidity=877 whiteListSetter = _new; ``` - `_new` is not zero-checked before being used.

The change of `_owner` by function `transferOwnership()` overrides the previously set `_owner` with the new one without guaranteeing the new `_owner` is able to actuate transactions on-chain.