YFX-V3

1. Based on the business logic of the `priceForLiquidate()` and `priceForIndex()` functions in `MarketPriceFeed.sol`, it is evident that the code on line 361 and line 366 fetches the price of the market collateral token consistently. Therefore, to reduce gas fee consumption, it is advisable to modify line 366 as follows: `response.price = response.indexPrice`. 2. Based on the code logic where `_settleFunding()` function is called on line 319, it can be inferred that after this code execution, `position.frLastX96` is already set to the latest value. Therefore, there is no need to assign `position.frLastX96` again on line 376.

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. As a result, an inconsistency in the amount will occur and the transaction may fail due to the validation checks. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee) to the target contract, only 90 tokens actually arrive to the contract. In the `YFX` protocol, if the ERC20 deflationary tokens are used as base assets, the balance of pool token recorded in `Vault` is different from the exact amount of token deposited.

1. When calculating `Maker` earnings, in order to maximize the benefits of the fund pool, the choice of off-chain and `ChainLink` prices for the collateral token of the market will be based on the current long and short asset situation in the market. The contract calling relationship when getting prices for pool is as follows:: `Pool.getPriceForPool() -> MarketPriceFeed.priceForPool() -> FastPriceFeed.getIndexPrice()`. 2. When calculating the trading price for limit orders, to ensure that the trading price is not lower than the trigger price when opening long positions and not higher than the trigger price when opening short positions, it is necessary to filter from the off-chain or `Chainlink` prices based on the `_maximise` parameter of the `getIndexPrice()` function. However, the code implementation of the `getIndexPrice()` function in the `FastPriceFeed` contract does not include any code logic for filtering the maximum or minimum values of off-chain and `ChainLink` prices based on the given parameter value `_maximise`.

Based on the logical structure of the function `priceForTrade()` in `MarketPriceFeed.sol`, it can be inferred that there are two sources for the contract trading price: Off-chain centralized price feeding program and ChainLink Price Feed. The selection of the price source depends on project configuration and factors such as stability of off-chain prices compared to ChainLink on-chain prices. The following four scenarios in which the off-chain price will be used; otherwise, the ChainLink on-chain price will be adopted. 1. Off-chain price is more stable than ChainLink on-chain price. 2. There is a significant difference between the off-chain price and ChainLink on-chain price. 3. Off-chain price is at its extremum (either greater or smaller than the ChainLink on-chain price). 4. Off-chain price is enforced. Once the price source is determined, the `controller` role is authorized to make three adjustments to the price through configuration (either upward or downward). The adjustment ratios are recorded in the following three state variables: `spreadBasisPoints`, `adjustmentBasisPoints`, and `slipPoint`.

Based on the code logic found in lines 106 and 108 of `FundingLogic.sol`, it can be inferred that the `funding rate` is positively correlated with the underlying asset price and the difference in long and short positions. However, during a bullish market, both the underlying asset price and the long and short positions increase, while during a bearish market, the asset price decreases, and the long and short positions increase. This leads to varying rates of change for the `funding rate` in different market conditions (bullish and bearish), resulting in a relatively weaker adjustment capability of the `funding rate` toward the long position when it surpasses the short position.

The contract is serving as the underlying entity to interact with one or more third party protocols(`ChainLink`, `rewardRouter`, different `Tokens`, etc). The scope of the audit treats third party entities as black boxes and assume 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.