Lithium Finance Ⅳ

In the contract **EnquiryPool** the role **_owner** has authority over the functions shown in the diagram below. Any compromise to the **_owner** account may allow the hacker to take advantage of this authority.  In the contract **Reputation** the role **_owner** has authority over the functions shown in the diagram below. Any compromise to the **_owner** account may allow the hacker to take advantage of this authority. 

The `RP_TOKEN` owned by the user decreases gradually on a daily basis over time, but calling `mint()` or `burn()` can continuously push the starting calculation time backward. Therefore, the user only needs to call `updateAnswer()` daily to trigger the call to `mint()` or `burn()`, which could avoid the RP_TOKEN reduction mechanism.

The exchange rate of `_stakeAmount` and `_stakeToken` is variable in the real market, which means that the fixed exchange rate of `enquiries[_enquiryId].BACrossRate` may allow users to stake the lower-priced token in the market in order to take advantage of it. This situation may not be intended and could potentially be addressed in future updates.

The Lithium project uses a system of inquiries through the addition of rewards by price seekers and predictions and quotations by price experts to measure the value of NFTs, realizing a price oracle for NFTs. However, many logic implementations are not within the scope of this audit, such as the generation of correct prices, the specific allocation of rewards, and the mechanism for obtaining RP_Tokens. It is recommended for the client recheck whether the logic is correct.

We would like the client to provide with us more information about the calculation of the `balanceOf()`. The mathematical models are not in the scope of this audit.

We would like to know where the `_signature` come from when a price expert is trying to create an answer.

The contract is serving as the underlying entity to interact with one or more third-party protocols. The audit scope treats third-party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=623 address _token, ``` - The function `EnquiryPool._transferInToken` and `EnquiryPool._transferOutToken` interacts with the third-party contract with `IERC20` interface via `_token`.

The use of two different stake tokens for each enquiry may add complexity and potentially cause issues. It is unclear why this design was made and we are looking forward to any information about the necessity of using it.

There is no cap for the max total minting amount of the `RP_Token`, hence the token could be minted unlimitedly.