Liquidations

Liquidations operate under different trust assumptions from other vault actions. Instead of requiring a 2-of-2 multisig, they rely on:

• A single signature

• The pre-image of a hash

How Liquidation Works

1. Hash Generation

   A hash is generated by sending a request to the price oracle. The oracle returns:

   • A quote for the current BTC/USD price

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

   • A hash to be used in the vault’s liquidation path

2. User Agreement

   Each time a user updates their vault, they agree to a new liquidation threshold. This threshold is enforced by the hash generated by the oracle. The user’s agreement is embedded in a transaction output that:

   • Requires the MPC Network’s signature to unlock

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

Privacy and Data Handling

• Only the oracle system has access to the threshold hash logic.

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

• The oracle does not store any hashes or pre-images. It derives the pre-image only when:

  • A liquidator requests it, and

  • The market price has crossed the vault’s agreed liquidation threshold

Three-Layer Security Mechanism

1. Oracle Blindness

   1. The oracle cannot identify which specific vault it is serving.

      1. It keeps no history of generated hashes or pre-images.

2. Separation of Roles

   1. The oracle is entirely separate from the MPC Network.

   2. This separation acts as a fail-safe to prevent collusion or shared compromise.

3. MPC Network Backstop

   1. If the oracle becomes compromised, the MPC Network can fall back on its own internal price references.

   2. This allows it to reject any transactions that would otherwise threaten protocol integrity.

This layered approach ensures that liquidations remain secure, privacy-preserving, and resilient, even in the event of oracle failure or compromise.