Noah security record

All **Noah** tokens are sent to the deployer assigned address `addr` when deploying the contract. This is a potential centralization risk as the deployer can distribute **Noah** tokens without the consensus of the community.

Addresses should be checked before assignment or external call to make sure they are not zero addresses. ```solidity=18 admin = _admin; ``` - `_admin` is not zero-checked before being used. --- ```solidity=47 feeTo = _feeTo; ``` - `_feeTo` is not zero-checked before being used. --- ```solidity=52 admin = _admin; ``` - `_admin` is not zero-checked before being used. --- ```solidity=73 token0 = _token0; ``` - `_token0` is not zero-checked before being used. --- ```solidity=74 token1 = _token1; ``` - `_token1` is not zero-checked before being used. --- ```solidity=25 factory = _factory; ``` - `_factory` is not zero-checked before being used. --- ```solidity=26 WETH = _WETH; ``` - `_WETH` is not zero-checked before being used.

The return value of the transfer()/transferFrom() call is not checked. ```solidity=137 INoahPair(pair).transferFrom(msg.sender, pair, liquidity); // send liquidity to pair ```

The return value of an external call is not stored in a local or state variable. ```solidity=44 INoahFactory(factory).createPair(tokenA, tokenB); ```

```solidity=19 address public factory; ``` 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.

It is expected that invocations of the form `transfer(recipient, amount)` succeed and return `true` if * The address in `recipient` is not the zero address, * `amount` does not exceed the balance of address `msg.sender`, * transferring `amount` to the address `recipient` does not lead to an overflow of the recipient's balance, and * the supplied gas suffices to complete the call. Nevertheless, the `transfer` function of `Token` fails in some of those admissible cases.

It is expected that invocations of the form `transfer(recipient, amount)` where the address in `recipient` equals the address in `msg.sender` (i.e. self-transfers) succeed and return `true` if * The value in `amount` does not exceed the balance of `msg.sender` and * the supplied gas suffices to complete the call. Nevertheless, the `transfer` function of `Token` fails in some of those admissible cases.

It is expected that non-reverting invocations of `transfer(recipient, amount)` that return `true` and where the address in `recipient` equals the address of `msg.sender` (i.e. self-transfers) do not change the balance of address `msg.sender`. However, in `Token.transfer` the balance of address `msg.sender` is changed by executing a self-transfer.

It is expected that invocations of `transferFrom(from, dest, amount)` succeed and return `true` if * the value of `amount` does not exceed the balance of address `from`, * the value of `amount` does not exceed the allowance of `msg.sender` for address `from`, * transferring a value of `amount` to the address in `dest` does not lead to an overflow of the recipient's balance, and * the supplied gas suffices to complete the call. Nevertheless, the `transferFrom` function of `Token` fails in some of those admissible cases.

It is expected that invocations of `transferFrom(from, dest, amount)` where the address in `dest` equals the address in `from` (i.e. self-transfers) succeed and return `true` if: * The value of `amount` does not exceed the balance of address `from`, * the value of `amount` does not exceed the allowance of `msg.sender` for address `from`, and * the supplied gas suffices to complete the call. Nevertheless, the `transferFrom` function of `Token` fails for some self-transfers in these admissible cases.