Audits that take no more than 20 days to complete, now start within 10 days 

The linked statement casts a `uint256` value to an `int256` without evaluating its bounds. This can be dangerous since an unchecked cast can lead to overflow. Furthermore, the function `getIndexOfKey()` is never called by another function, making the type conversion unnecessary. 

Unsafe Cast And Unused Function

The private function `_isNodeOwner` is never called by another function within the contract. 

Redundant  Code Components

The linked variables could be declared as `constant` since these state variables are never modified.

Variables That Could Be Declared As `constant`

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Missing Emit Events

The contract has an unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to different compiler versions. This can lead to ambiguity when debugging as compiler-specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

Furthermore, there are multiple pragma directives declared throughout the contract.

Unlocked Compiler Version | Multiple Pragma Directives With Different Solidity Versions 

The function `distributeRewards()` can consume a lot of gas because:
* State variable `nodeOwners.keys.length` is accessed multiple times
* State variable `_totalEarn` is accessed and modified multiple times
* The function updates the yield of every node owning address, and every one of their nodes.

Costly Loop

External calls are made inside a *for* loop. This might lead to a denial-of-service attack. If any of the calls fail, it will cause the entire loop to revert. 

The function argument `users` allows the owner to specify which addresses will receive a free node. If a call to `nodeManager._createNode()` reverts for any one of the addresses, the entire function call of `giveNode()` will revert. However, `giveNode()` can be called again with that address removed from the `users` argument to bypass the revert. 

Although this is possible, a more optimized approach would be to implement a pull-over-push strategy.

External Call Inside Loop

Addresses should be checked before assignment or external call to make sure they are not zero addresses.

Missing Zero Address Validation

Comparisons that are always true or always false may be incorrect or unnecessary.

Type `uint256` will always be greater than or equal to zero. Therefore, it is unnecessary to check:
```solidity
require(... && nodeTypeID >= 0)
```

Tautology

Literals with many digits are difficult to read and review.

Too Many Digits

The return value of an external call is not stored in a local or state variable.

Unused Return Value

The order of external call/transfer, storage manipulation, and event emission must follow the check-effect-interaction pattern.

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.

Check Effect Interaction Pattern Violated

After [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884) was included in the Istanbul hard fork, it is not recommended to use `.transfer()` or `.send()` for transferring ether as these functions have a hard-coded value for gas costs making them obsolete as they are forwarding a fixed amount of gas, specifically `2300`. This can cause issues in case the linked statements are meant to be able to transfer funds to other contracts instead of EOAs.

Usage of `transfer()` for sending Ether

In the contract `Angel`, the role `owner` has authority over the functions: 
* `setSwapTokensAtAmount()`
* `giveNode()`
* `updateGasForProcessing()`
* `updateClaimingTimestamp()`
* `updateMaxNodes()`
* `setMinimumNodeUseRef()`
* `setMinimumNodeSetRef()`
* `setMaxAmountPerNode()`
* `getNodeTypes()`
* `editNodeType()`
* `addNodeType()`
* `disableNodeType()`
* `enableNodeType()`
* `processDistribution()`
* `setFuturUsePool()`
* `setDistributionPool()`
* `blacklistAddress()`
* `setFuturUseSellFee()`
* `setBurnSellFee()`
* `setFuturUseNodeFee()`
* `setLiquidityPoolFee()`
* `setDistributionSwapFee()`
* `setPairAddress()`
* `setBoosterChildAmount()`
* `updateUniswapV2Router()`
* `excludeFromFees()`


Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and:
* Set the maximum number of nodes to an unlimited amount with `updateMaxNodes()` and create an unlimited amount of nodes for themselves with `giveNode()`.
* Set the claiming timestamp to a large number by calling `updateClaimingTimestamp()` such that no user can claim rewards from their nodes.
* Set the maximum amount of booster nodes to any amount with `setMaxAmountPerNode()`.
* Disable or enable any node type at any point to stop or start a node type from receiving yield with `disableNodeType()` and `enableNodeType()`.
* Adjust the fee structure for fees sent to the liquidity pool, future use, and distribution swap when purchasing a new node.
* Change the addresses of the liquidity pool, future use, and distribution swap.
* Include or exclude any user from the liquidity pool, future use, and distribution swap fees.
* Edit the properties of any node type, such as the amount of yield produced per distribution, time to upgrade, and which node it will upgrade to with `editNodeType()`.
* Create a new node type with any properties with `addNodeType()`.

Centralization Related Risks

All of the `Angel` tokens are sent to the contract deployer when deploying the contract. This could be a centralization risk as the deployer can distribute `Angel` tokens without obtaining the consensus of the community.

Initial Token Distribution

All variable types within Solidity are initialized to their default \"empty\" value, which is usually their zeroed out representation. 

Particularly:
- `uint` / `int`: All `uint` and `int` variable types are initialized at `0`
- `address`: All `address` types are initialized to `address(0)`
- `byte`: All `byte` types are initialized to their `byte(0)` representation
- `bool`: All `bool` types are initialized to `false`
- `ContractType`: All contract types (i.e. for a given `contract ERC20 {}` its contract type is `ERC20`) are initialized to their zeroed out address (i.e. for a given `contract ERC20 {}` its default value is `ERC20(address(0))`)
- `struct`: All `struct` types are initialized with all their members zeroed out according to this table

Redundant Variable Initialization

It is always better, regarding Gas Optimization, to use `memory` instead of `storage` when it is possible.

Angel Nodes

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

17

0

15

1

1