PartyA Liquidation Fee Recipient Cleanup

Final settlement pays the capped PartyA liquidation fee to the address that started the liquidation.

Summary

The PartyA liquidation fee (LF) now has one receiver: liquidators[partyA][0], the address that started the PartyA liquidation.

Before v0.8.6, PartyA LF was split between two receivers: the caller that started liquidation and the caller recorded when the liquidation type was first determined during price submission. The release makes the first liquidation call the only paid step.

v0.8.6 removes the second receiver and pays the LF only to the starter at final settlement. The later liquidation calls remain role-gated; this change only selects the fee recipient.

What changed

Before v0.8.6: PartyA LF was split 50/50 between liquidators[partyA][0] and liquidators[partyA][1].

liquidators[partyA][0] was the caller of liquidatePartyA or deferredLiquidatePartyA. liquidators[partyA][1] was the first caller of setSymbolsPrice or deferredSetSymbolsPrice; later price-setting calls did not add more LF receivers.

After v0.8.6, PartyA LF has one receiver. The final capped LF goes to liquidators[partyA][0], the caller that starts liquidation. Price setters do not receive PartyA LF.

The cap logic did not change. PartyA LF is still limited by maxLiquidationProfitPerPosition * partyAPositionsCount[partyA], and any amount above the cap goes to the liquidation insurance vault.

Final settlement accounting

The LF is handled during PartyA liquidation finalization. The liquidated PartyA's LF_OUT amount is capped at the portion funded by its allocated balance immediately before finalization. The rest of that starting allocation is reported as realized-PnL outflow. The starter receives the full capped LF as a direct allocated credit. 

// Pay capped LF to the liquidation starter.
uint256 lf = accountLayout.liquidationDetails[partyA].liquidationFee;
uint256 lfFromAllocated = lf < previousAllocatedBalance ? lf : previousAllocatedBalance;
LibAccount.decreasePartyAAllocatedBalance(partyA, lfFromAllocated, SharedEvents.BalanceChangeType.LF_OUT);
if (lf > 0) {
	address liquidationStarter = accountLayout.liquidators[partyA][0];
	LibAccount.increasePartyAAllocatedBalance(liquidationStarter, lf, SharedEvents.BalanceChangeType.LF_IN);
}

The resulting balance movement is:

  • The PartyA decrease method records the allocated-funded portion with reason LF_OUT.
  • The starter increase method credits the full capped LF with reason LF_IN.
  • Each method emits the corresponding existing BalanceChangePartyA event from the same mutation boundary.

If the capped LF is zero, no LF balance-change events are emitted.