Fidelis security record

In the `escrowconfig_2` subroutine, the manager address can call the config subroutine and let the contract opt in the three input assets. We have three questions regarding the assets opting in operations: 1. How is it ensured that the opt-in operations are performed before further asset transfers are made? 2. Related to todo, given that there could be multiple unknown assets to be transferred, how are those assets ensured to be opted in? 3. Our current understanding is that there will be two assets involved in a pool, Fidelis Trust Points and USDC. Here in the `escrowconfig_2` subroutine, there are three assets to opt-in. We would like to learn the use cases of the third asset.

During the code audit, we browsed through the documentation and found two issues related to the business logic: 1. Can the Trust Points be freely traded? If so, trust points will have a value outside of the Fidelis project. If the price of trust points fluctuates significantly, is the impact on the loan acceptable? 2. The documentation mentioned that “Borrower can request a one-time extension initiating a grace period by completing a Fidelis approved a personal finance training course.” It seems this feature is not included in the current version of the smart contract. We would like to learn that if this would be operated off-chain?

In the invest subroutine, L229-236, there is a condition `require(staked_amount * 10000 >= loan_amount)`. We did not find any languages about the number `10000` in the provided documentation. We would like to learn more about the number and its design.

In the current implementation, `fee` is a predefined value instead of a calculated value. Our understanding is that the variable `fee` represents the interest and fees. The current implementation meets neither the development phase scenario nor the MVP deployment phase scenario, according to the documentation. ```text In the development phase, loans are issued at 15% interest: 10.5% - Fidelis as the administrator and Liquidity Partner 3.0% - Backers 1.5% - Default Pool For the MVP deployment phase: 5.5% - Fidelis as Administrator 5.0% - Liquidity Partner 3.0% - Backers 1.5% - Default Pool ```

In the current version of the TEAL file, there are some unused variables and some unfinished subroutines: * unused global states:`start_date`, `end_date`, `beneficiary`, `stable_token` * unused local states: `"<AppID>_key"` in the `invest_0` subroutine * unused scratch spaces: slot `0`, slot `2` * unused branches: `main_l17`("force_close") and `main_l15`("check_default")

Given that `reclaim_1` is called through `callsub` and there is a `return 1` following a success call (L75-77), we believe that `reclaim_1` is a subroutine instead of a normal branch. We noticed that in the `reclaim_1` subroutine, `return` is used instead of `retsub`. The current implementation might be compiled from a PyTeal version of contract and the code flow is fine. If there is more logic to be added in the `main_l21` branch in L75, the direct `return 1` of `reclaim_1` may jump over what is after the subroutine call on L76.