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 vault. If an entire vault is liquidated, all (or part) of its collateral is seized by the system and sold to repay debt.


Staking 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 with collateral in the vault. If an entire vault is below its minimum C-Ratio, anyone can pay its debt with sUSD and receive collateral.


The current version of the protocol implements a socialized liquidations mechanism. This proposal implements a similar system for positions within a vault, as we anticipate a pool controlled by the Spartan Council will effectively replace the current debt pool. We anticipate vault liquidations will typically occur with pools backing experimental markets. Because the v2x debt pool is undifferentiated, there isn't an analogy to the v2x system (outside of how liquidations were handled prior to SIP-148).



When a staking position is liquidated, the liquidator receives a fixed SCCP-configurable amount of this collateral. The remainder is tracked by the liquidations manager, a contract which tracks how much of the collateral can be claimed by each account with collateral in the same vault (i.e. also participating in this pool by staking same collateral type). The staking position is closed, effectively transferring the debt responsibility to the others in the vault. The collateral delegation of the pool remains the same.

A vault’s minimum c-ratio is determined by governance, based on the type of collateral it contains. When a vault is liquidated, the liquidator provides sUSD and receives collateral from the vault. The share of collateral received by the liquidator is determined by the proportion of the vault’s debt being provided by the liquidator (in sUSD).


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 staking position for each account participating in the vault. This could be gas intensive and disincentivize liquidators from maintaining the system's health.

This proposal departs from the existing protocol’s liquidations mechanism in that 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 notification systems to ensure that stakers are aware when their C-Ratios are falling below the target.

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

Technical Specification

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

liquidatePosition(uint vaultId, 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 StakingPosition and reduce the totalDebtShares on the pool by the amount of shares worth the amount of debt related to this StakingPosition.
  • Call acceptLiquidations on the liquidations manager with the appropriate parameters.

The Liquidations Manager will implement the following interface:

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

Note that the liquidations manager should convert SNX to eSNX when claimed. See SIP 305 for more information.

liquidateVault(uint poolId, address collateralType, uint amount)

  • Confirm that the specified vault is below its minimum C-ratio.
  • Burn amount of sUSD from msg.sender.
  • Calculate what percentage of the total debt held by this vault is covered by amount. msg.sender receives this percentage of collateral held by this vault.
  • 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 vault by the amount of shares worth amount.

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 staking position in a vault holding this collateral type.

Copyright and related rights waived via CC0.