SIP-304: Liquidations (V3)

NetworkEthereum & Optimism
ImplementorDaniel Beal (@dbeal-eth), Leonardo Massazza (@leomassazza), Alejandro Santander (@ajsantander)

Simple Summary

This SIP proposes a mechanism for liquidations in Version 3 of the Synthetix protocol. Liquidated positions have their collateral and debt distributed among other participants in their fund. If an entire fund is liquidated, all (or part) of its collateral may be seized by the system and sold to repay debt.


Positions below their minimum C-Ratios can have their collateral seized by the liquidations manager, which tracks how much of this collateral each account can claim. The debt is automatically redistributed among the other accounts in the fund. If an entire fund is below its minimum C-Ratio, anyone can pay its debt with sUSD and receive collateral


The current version of the protocol is transitioning to a socialized liquidations mechanism to avoid cascading liquidations. This proposal implements a similar system for positions within a fund, as we anticipate a fund controlled by the Spartan Council will effectively replace the current debt pool.

We anticipate fund liquidations will typically occur with funds backing experimental markets. Accordingly, fund liquidations are designed here primarily to ensure that the debt backing sUSD is recovered.



When a position is liquidated, the liquidator receives a fixed SCCP-configurable amount of this collateral. The remainder is tracked by the liquidations manager, a new contract which tracks how much of the collateral can be claimed by each account also participating in this fund. The position in the fund is closed, effectively transferring the debt responsibility to the others in the fund. The staking position of the fund (and its related markets’ supply targets) remain the same.

A fund’s minimum C-Ratio is based on a weighted average of the minimum C-ratio of all the collateral types assigned to the fund. When a fund is liquidated, the liquidator provides sUSD and receives all types of collateral staked in the fund. The share of collateral received by the liquidator is determined by the proportion of the fund’s debt being provided by the liquidator (in sUSD). The fund stops provided liquidity to the markets in its staking position (to prevent additional debt inflation), reducing the supply caps in these markets.


Due to engineering limitations related to scalability, we can’t automatically restake liquidation rewards on behalf of stakers. We would need to create a new CollateralEntry for each account participating in the fund. It may be possible to automatically restake if we only socialized collateral among those staking the liquidated collateral type. But, because debt is distributed pro-rata, this would be unfair to those staking in the minority collateral type.

Another outcome of this design is that users may receive liquidation rewards of collateral types they haven’t staked. While this may not be ideal, they will only receive assets that have been approved by the Spartan Council. Further, by leveraging multicalls, we can allow users to withdraw, exchange, and restake collateral with a seamless user experience.

This proposal also departs from the existing protocol’s liquidations mechanism notably in two ways. First, we have not included flagging functionality, where users are given a fixed period of time to fix their C-Ratio after dropping below the minimum prior to liquidation. This is because immediate liquidations are safer for the system, we already have a buffer created by the target C-Ratio requirements, and we can develop an improved notifications system to ensure that stakers are aware when their C-Ratios are falling below the target.

Second, this proposal does not escrow liquidation rewards. Because the debt from the liquidated account is being immediately transferred to the other stakers in its fund and stakers will be required to manually restake these rewards, holding these rewards in escrow seems unnecessarily punitive.

Also, we considered having liquidations occur on accounts but decided against this, as liquidating an account across multiple funds would cause unnecessary implementation complexity. More importantly, this mechanism allows stakers to compartmentalize risk across different funds and collateral types.

Technical Specification

This SIP adds two methods to the Fund contract with the following functionality:

liquidatePosition(uint fundId, uint accountId, address collateralType)

  • Confirm that the specified collateral entry is below its minimum C-ratio.
  • msg.sender receives the SCCP-configurable amount of liquidation rewards. If the total value of this position is less than the rewards amount, msg.sender receives the total amount of collateral in the position.
  • Delete the relevant CollateralEntry and reduce the totalDebtShares on the fund by the amount of shares worth the amount of debt related to this CollateralEntry.
  • Call acceptLiquidations on the liquidations manager with the appropriate parameters.

The Liquidations Manager will implement the following interface:

interface ILiquidationManager {
	function acceptLiquidation(uint fundId, address collateralType, uint amount);
	function collateralAvailable(uint fundId, uint accountId, address collateralType) view returns (uint);
	function claim(uint fundId, uint accountId, address collateralType);

liquidateFund(uint fundId, uint amount)

  • Confirm that the specified fund is below its minimum C-ratio.
  • Burn amount of sUSD from msg.sender.
  • Calculate what percentage of the total debt held by this fund is covered by amount. msg.sender receives this percentage of each collateral type held assigned to this fund.
  • Get all of the collateral (or the percentage of the collateral relative to the amount sUSD to total debt) reducing debt shares.
  • Reduce the totalDebtShares on the fund by the amount of shares worth amount.
  • Stop this fund from providing liquidity to markets by setting all weights to 0 with a call to setFundPosition. A fund should not be able to alter its position until its C-Ratio return above its minimum.

Test Cases

Relevant tests will be developed during implementation.

Configurable Values (Via SCCP)

Collateral Types will have an additional configurable value:

  • Liquidation Reward (uint) - The amount this asset provided to a user who is liquidating a position while this collateral type.

Copyright and related rights waived via CC0.