Africa Code Academy: Fidelis

In the contract `approval.teal`, the role `manager` has authority over the following subroutine: * `escrowconfig_2` In the contract `approval.teal`, the role `agent_address` has authority over the following subroutine: * `pull_4` In particular, the `agent_address` can pull any amount of any asset of the contract. Any compromise to the `manager` or `agent_address` accounts may allow a hacker to take advantage of this authority.

In the `repay_3` subroutine, there are checks making sure that the repayment amount (`txna ApplicationArgs 1`) is greater than 0 and less than or equal to the global balance. It is also checked that the sender is actively holding the asset of repayment (`txna Assets 0`). However, the asset of repayment (`txna Assets 0`) is provided by the caller through transaction input, which can be different from the asset that has been borrowed.

We feel that the workflow is as what is shown in the diagram below. Please correct us if there is any misunderstanding.  The current implementation does not match our understanding in the following ways: 1. The current implementation does not check if the `loan_state` is `alive` for the `repay_3` subroutine. 2. After execution of the `reclaim_1` subroutine, the `loan_state` is not updated. One approach is to update back to `openToInvestment`. Another approach is to update it to some new states like `reclaimed`, and let the `reclaimed` state be a final state, etc.

The smart contract is missing some checks on transactions. In addition, in commit hash `a52d84008a830e74db08f1d1ba2599ee543e5f87`, there are new `RekeyTo == Sender` requirements in subroutines `invest`, `reclaim` and `repay`, which would adding the `Sender` address to the `Auth-Addr` to the signer address.