LIF3 security record

Contract L3USD takes a less than 0.2% fee for each token transfer, and the fee is collected by the contract owner. If the fees is not flowed back to the users in some way, eventually all the L3USD token would end up in the contract owner's wallet.

The following 2 functions changes important state variables but don't emit relevant events as notifications. 1. Function `transferOwnership()` updates contract owner address. 2. Function `transferFrom()` updates the allowance before token transfer.

The `_to` or `_spender` input address in function `approve()`, `transfer()` and `transferFrom()` are missing a check that it is not `address(0)`. This would allow users to send token to zero address and essentially burn their tokens and decrease the amount of L3USD in circulation.

The variables `name`, `symbol` and `decimals` 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. An advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they are not located in storage.

Function `_transferAllRewards()` calculates the reward amount for each reward token and transfers them to the caller. The *require* check on line 536 will revert the entire transaction if one of the reward token balance is not sufficient for the transfer. If the contract is short on one reward token, it could stop all users from claiming their rewards. ```solidity=532 for (uint256 rewardId = 0; rewardId < rewardsLength; ++rewardId) { address reward = rewards[rewardId]; uint256 userRewards = _calculateReward(startOfClaim, endOfClaim, lock.lockTime, lock.amount, reward); if (userRewards > 0) { require( IERC20(reward).balanceOf(address(this)) >= userRewards, "Too little rewards in contract to pay to user" ); address sender = msg.sender; IERC20(reward).safeTransfer(sender, userRewards); emit RewardPaid(sender, userRewards); } } ```

The contract is serving as the underlying entity to interact with third party deposit and reward token contracts, and prb math library. The scope of the audit treats 3rd party entities as black boxes and assumes their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. Additionally, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to addresses, etc.