DEFED security record

The account information is not recorded in the contract `AssetManagement`, we assume that the project might query events and maintain the accounts in their own server. This part is not public to the users.

The function `_approve()` is after the function `_transfer()`. It's recommended to move the function `_approve()` in front of the `_transfer` step to check early and revert in time to save gas when the allowance is not enough.

The part of logic is hidden in the interactions with third-party protocols or centralized manipulation. For example, function `transferToEthereum()` has no permission control, we assume that there is no `vToken` stuck in the contract. So if the user wants to transfer to Ethereum, he/she needs to transfer `vToken` to the contract first. And how will the remainder of the cross-chain transfer be completed. If no `vToken` can be left in the contract, each external call must spend all of the minted tokens. The team should ensure that the control process is reliable and complete.

`public` functions that are never called by the contract could be declared as `external`. `external` functions are more efficient than `public` functions.

The amount recorded in the events of the functions may be inconsistent with the actual amount. The contract `AssetManagement` does not support deflationary tokens. And adapting deflationary coins with non-deflationary `vToken` may be problematic.

The function `deposit()` and `depositForRepay()` are totally the same, except the event and error message. We would like to confirm with the client whether there is need to distinguish the two functions and if the functions can be merged. The same case exists between function `depositETHForRepay()` and `depositETH()`.

State variables that never change should be declared as `constant` to save gas. ```solidity=43 uint256 public lastTokenId; ``` - `lastTokenId` should be declared `constant`.

The contracts are serving as the underlying entity to interact with third-party `BANKCARDNFT`, `bridgeFeeController`, `lendingPool`, `virtualDefedToken`, `FlashSwapCallee`, `IVeDEFE` protocols. 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. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc.

The return value of an external call is not stored in a local or state variable. ```solidity=85 IERC20(vToken).approve(lendingPool,amount); ``` --- ```solidity=101 IERC20(vToken).approve(lendingPool,amount); ``` --- ```solidity=102 ILendingPool(lendingPool).repay(vToken, amount,rateMode,proxyAddr); ``` --- ```solidity=137 IERC20(virtualDefedToken).approve(veDEFE,amount); ``` --- ```solidity=61 ILendingPool(params.lendingPool).withdraw(vToken,amount,params.bridgeControl); ``` --- ```solidity=101 IERC20(vToken).approve(params.lendingPool,targetAmount); ``` --- ```solidity=118 ILendingPool(params.lendingPool).withdraw(vToken,fee,networkFeeVault); ``` --- ```solidity=135 ILendingPool(params.lendingPool).withdraw(vToken,amount,params.bridgeControl); ``` --- ```solidity=160 IERC20(vToken).approve(params.lendingPool,targetAmount); ``` --- ```solidity=192 ILendingPool(params.lendingPool).withdraw(vToken,amount,address(this)); ``` --- ```solidity=199 ILendingPool(params.lendingPool).repay(vToken, targetAmount,rateMode,address(this)); ```

The linked 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.