Liquidations

Liquidations have different trust assumptions compared to other vault actions. Instead of relying on a 2/2 multisig, they require:

• A Single Signature

• The Pre-image of a Hash

How Liquidation Works

1. Hash Generation:

   • A hash is obtained by sending a request to an oracle.

   • The oracle returns:

     • A quote for the current price

     • A liquidation price based on risk parameters from the Master CRS

     • The hash to be used in the liquidation path

2. User Agreement:

   • Every time a user updates their vault, they explicitly agree to a new liquidation threshold.

   • This threshold is enforced by the oracle-generated hash.

   • The user’s agreement is embedded in the form of a signature on an output that:

     • Requires the MPC Network’s signature to unlock

     • Requires the pre-image of the hash contained in the OP_RETURN of the transaction

Privacy and Data Handling

• This information is only available to the oracle system.

• Neither the MPC Network nor the user ever sees the hash or its pre-image.

• The oracle doesn’t store the hash or pre-image. Instead, it derives the pre-image when:

  1. A liquidator requests it

  2. The price has crossed the designated liquidation threshold

Three-Layer Security Mechanism

1. Oracle Blindness:

   • The oracle is blind to the specific vault it’s offering liquidation for.

   • It does not keep a history of pre-images.

2. Separation of Roles:

   • The oracle system is completely detached from the MPC Network.

   • This separation acts as a backstop mechanism to prevent collusion.

3. MPC Network Backstop:

   • If the oracle system becomes compromised, the MPC Network has an internal price scheme.

   • This ensures the network can backstop the signing of any transactions deemed harmful to the protocol.

This structure ensures that liquidations are secure, transparent, and resilient, even in the event of oracle system failures.