Liquidators will not be incentivized to liquidate certain PartyB accounts due to the lack of incentives
Liquidating certain accounts does not provide a liquidation fee to the liquidators. Liquidators will not be incentivized to liquidate such accounts, which may lead to liquidation being delayed or not performed, exposing Party B to unnecessary risks and potentially resulting in greater asset losses than anticipated.\\n```\\nFile: LiquidationFacetImpl.sol\\n    function liquidatePartyB(\\n..SNIP..\\n        if (uint256(-availableBalance) < accountLayout.partyBLockedBalances[partyB][partyA].lf) {\\n            remainingLf =\\n                accountLayout.partyBLockedBalances[partyB][partyA].lf -\\n                uint256(-availableBalance);\\n            liquidatorShare = (remainingLf * maLayout.liquidatorShare) / 1e18;\\n\\n            maLayout.partyBPositionLiquidatorsShare[partyB][partyA] =\\n                (remainingLf - liquidatorShare) /\\n                quoteLayout.partyBPositionsCount[partyB][partyA];\\n        } else {\\n            maLayout.partyBPositionLiquidatorsShare[partyB][partyA] = 0;\\n        }\\n```\\n\\nAssume that the loss of Party B is more than the liquidation fee. In this case, the else branch of the above code within the `liquidatePartyB` function will be executed. The `liquidatorShare` and `partyBPositionLiquidatorsShare` variables will both be zero, which means the liquidators will get nothing in return for liquidating PartyBs\\nAs a result, there will not be any incentive for the liquidators to liquidate such positions.
Considering updating the liquidation incentive mechanism that will always provide some incentive for the liquidators to take the initiative to liquidate insolvent accounts. This will help to build a more robust and efficient liquidation mechanism for the protocols. One possible approach is to always give a percentage of the CVA of the liquidated account as a liquidation fee to the liquidators.
Liquidators will not be incentivized to liquidate those accounts that do not provide them with a liquidation fee. As a result, the liquidation of those accounts might be delayed or not performed at all. When liquidation is not performed in a timely manner, PartyB ended up taking on additional unnecessary risks that could be avoided in the first place if a different liquidation incentive mechanism is adopted, potentially leading to PartyB losing more assets than expected.\\nAlthough PartyBs are incentivized to perform liquidation themselves since it is the PartyBs that take on the most risks from the late liquidation, the roles of PartyB and liquidator are clearly segregated in the protocol design. Only addresses granted the role of liquidators can perform liquidation as the liquidation functions are guarded by `onlyRole(LibAccessibility.LIQUIDATOR_ROLE)`. Unless the contracts are implemented in a manner that automatically grants a liquidator role to all new PartyB upon registration OR liquidation functions are made permissionless, PartyBs are likely not able to perform the liquidation themselves when the need arises.\\nMoreover, the PartyBs are not expected to be both a hedger and liquidator simultaneously as they might not have the skillset or resources to maintain an infrastructure for monitoring their accounts/positions for potential late liquidation.
```\\nFile: LiquidationFacetImpl.sol\\n    function liquidatePartyB(\\n..SNIP..\\n        if (uint256(-availableBalance) < accountLayout.partyBLockedBalances[partyB][partyA].lf) {\\n            remainingLf =\\n                accountLayout.partyBLockedBalances[partyB][partyA].lf -\\n                uint256(-availableBalance);\\n            liquidatorShare = (remainingLf * maLayout.liquidatorShare) / 1e18;\\n\\n            maLayout.partyBPositionLiquidatorsShare[partyB][partyA] =\\n                (remainingLf - liquidatorShare) /\\n                quoteLayout.partyBPositionsCount[partyB][partyA];\\n        } else {\\n            maLayout.partyBPositionLiquidatorsShare[partyB][partyA] = 0;\\n        }\\n```\\n