Imbalanced approach of distributing the liquidation fee within `setSymbolsPrice` function
The imbalance approach of distributing the liquidation fee within `setSymbolsPrice` function could be exploited by malicious liquidators to obtain the liquidation fee without completing their tasks and maximizing their gains. While doing so, it causes harm or losses to other parties within the protocols.\\nA PartyA can own a large number of different symbols in its portfolio. To avoid out-of-gas (OOG) errors from occurring during liquidation, the `setSymbolsPrice` function allows the liquidators to inject the price of the symbols in multiple transactions instead of all in one go.\\nAssume that the injection of the price symbols requires 5 transactions/rounds to complete and populate the price of all the symbols in a PartyA's portfolio. Based on the current implementation, only the first liquidator that calls the `setSymbolsPrice` will receive the liquidation fee. Liquidators that call the `setSymbolsPrice` function subsequently will not be added to the `AccountStorage.layout().liquidators[partyA]` listing as Line 88 will only be executed once when the `liquidationType` is still not initialized yet.\\n```\\nFile: LiquidationFacetImpl.sol\\n    function setSymbolsPrice(address partyA, PriceSig memory priceSig) internal {\\n..SNIP..\\n        if (accountLayout.liquidationDetails[partyA].liquidationType == LiquidationType.NONE) {\\n            accountLayout.liquidationDetails[partyA] = LiquidationDetail({\\n                liquidationType: LiquidationType.NONE,\\n                upnl: priceSig.upnl,\\n                totalUnrealizedLoss: priceSig.totalUnrealizedLoss,\\n                deficit: 0,\\n                liquidationFee: 0\\n            });\\n..SNIP..\\n            AccountStorage.layout().liquidators[partyA].push(msg.sender);\\n        } else {\\n            require(\\n                accountLayout.liquidationDetails[partyA].upnl == priceSig.upnl &&\\n                    accountLayout.liquidationDetails[partyA].totalUnrealizedLoss ==\\n                    priceSig.totalUnrealizedLoss,\\n                "LiquidationFacet: Invalid upnl sig"\\n            );\\n        }\\n    }\\n```\\n\\nA malicious liquidator could take advantage of this by only setting the symbol prices for the first round for each liquidation happening in the protocol. To maximize their profits, the malicious liquidator would call the `setSymbolsPrice` with none or only one (1) symbol price to save on the gas cost. The malicious liquidator would then leave it to the others to complete the rest of the liquidation process, and they will receive half of the liquidation fee at the end of the liquidation process.\\nSomeone would eventually need to step in to complete the liquidation process. Even if none of the liquidators is incentivized to complete the process of setting the symbol prices since they will not receive any liquidation fee, the counterparty would eventually have no choice but to step in to perform the liquidation themselves. Otherwise, the profits of the counterparty cannot be realized. At the end of the day, the liquidation will be completed, and the malicious liquidator will still receive the liquidation fee.
Consider a more balanced approach for distributing the liquidation fee for liquidators that calls the `setSymbolsPrice` function. For instance, the liquidators should be compensated based on the number of symbol prices they have injected.\\nIf there are 10 symbols to be filled up, if Bob filled up 4 out of 10 symbols, he should only receive 40% of the liquidation fee. This approach has already been implemented within the `liquidatePartyB` function via the `partyBPositionLiquidatorsShare` variable. Thus, the same design could be retrofitted into the `setSymbolsPrice` function.
Malicious liquidators could exploit the liquidation process to obtain the liquidation fee without completing their tasks and maximizing their gains. While doing so, many liquidations would be stuck halfway since it is likely that no other liquidators will step in to complete the setting of the symbol prices because they will not receive any liquidation fee for doing so (not incentivized).\\nThis could potentially lead to the loss of assets for various parties:\\nThe counterparty would eventually have no choice but to step in to perform the liquidation themselves. The counterparty has to pay for its own liquidation, even though it has already paid half the liquidation fee to the liquidator.\\nMany liquidations would be stuck halfway, and liquidation might be delayed, which exposes users to greater market risks, including the risk of incurring larger losses or having to exit at an unfavorable price.
```\\nFile: LiquidationFacetImpl.sol\\n    function setSymbolsPrice(address partyA, PriceSig memory priceSig) internal {\\n..SNIP..\\n        if (accountLayout.liquidationDetails[partyA].liquidationType == LiquidationType.NONE) {\\n            accountLayout.liquidationDetails[partyA] = LiquidationDetail({\\n                liquidationType: LiquidationType.NONE,\\n                upnl: priceSig.upnl,\\n                totalUnrealizedLoss: priceSig.totalUnrealizedLoss,\\n                deficit: 0,\\n                liquidationFee: 0\\n            });\\n..SNIP..\\n            AccountStorage.layout().liquidators[partyA].push(msg.sender);\\n        } else {\\n            require(\\n                accountLayout.liquidationDetails[partyA].upnl == priceSig.upnl &&\\n                    accountLayout.liquidationDetails[partyA].totalUnrealizedLoss ==\\n                    priceSig.totalUnrealizedLoss,\\n                "LiquidationFacet: Invalid upnl sig"\\n            );\\n        }\\n    }\\n```\\n