DeFi 借貸概念：清算

原文鏈接：https://medium.com/smlxl/defi-lending-concepts-part-2-liquidations-7f0f0ffec96c

譯文出自：登鏈翻譯計劃

譯者：翻譯小組 校對：Tiny 熊

這篇文章是借貸系列文章的二篇，本文我們將回顧 DeFi 清算的運作方式，以及爲什么它們很重要。

在上一篇文章中，我們回顧了 Defi 借貸協議的核心概念，以及不同的協議如何選擇實現這些操作，例如份額幣，在這篇文章中，我們將重點討論我們認爲是最令人興奮的 Defi 借貸概念之一：清算。

超額抵押和壞账

清算和清算閾值

Compound：账戶流動性

Maker

AAVE V2 - 健康系數

破產頭寸分析

超額抵押和壞账

你可能還記得我們以前的文章^[5]，協議用戶只能用他們提供給協議的抵押品的一個可變比例來借入資產。這是有道理的，因爲協議需要確保，如果你無法償還債務，它可以從你那裏收回其資產（或任何價值相同的其他資產）。這種資產抵押的過程始於傳統金融服務，例如，今天，人們可以把他們的房子或蘭博基尼作爲償還貸款的擔保。

抵押依靠的前提是抵押品的價格保持其價值 -- 盡管房子或蘭博基尼的價格不能保證，但它們各自的價值比 ERC20 或 NFT 的價值波動要小。

在大多數 DeFi 貸款協議中，你的抵押貸款資產必須比你的貸款有更高價值--也被稱爲超額抵押。

如果貸款協議想保持財務穩定，只允許超額抵押貸款，這符合貸款協議的利益。想象一下，你提供一些資產作爲抵押品，而這個資產的價值突然下降到低於你從協議中貸款的資產價值。你就會缺乏償還貸款的動力。畢竟，你在償還貸款過程中搶救出來的抵押品現在的價值將低於你實際償還貸款的金額。這筆貸款現在就得不到償還。

每出現得不到償還的貸款對其協議都是不利的。穿倉貸款產生的債務在協議中造成了不安全，畢竟，債務的數額是貸款人無法從協議中收回的資產數額。爲了強調這種債務有多糟糕：如果協議上出現相當於傳統金融服務的 "銀行擠兌"，最後從協議中提取資產的用戶將沒法提取資產。

很自然，有大量壞账的協議對用戶的吸引力就會降低。

清算和清算閾值

我們已經確定，當抵押品的價值低於借款人連本帶利的債務價值時，被稱爲抵押不足，借款人的債務對借貸協議的健康構成威脅。爲了防止抵押不足的頭寸的積累，協議允許不一定是協議用戶的第三方（稱爲清算人）來償還抵押不足（或接近抵押不足）的借款人的債務。通過償還抵押不足的債務，清算人有權要求索取債務人的抵押品，同時獲得折扣。這個過程被稱爲清算。

你可能想知道：爲什么協議要依靠第三方來清算不健康的頭寸？畢竟，協議可以將自動清算機制植入其代碼中。

發送清算交易需要耗費大量的 Gas。如果協議自動發送這些昂貴的交易，由此產生的 Gas 成本將增加他們的運營成本，從而削弱協議利潤。

此外，一個自動清算系統的設計將是非常困難的。一個協議不僅要考慮一個頭寸是否應該自動清算，還要考慮何時清算，並以反映市場波動的速度進行清算。通過激勵專門的第三方來清算這些頭寸，將這個過程外包出去要容易得多。

清算本身並不有利可圖--爲了使這一過程有利可圖，債務人的抵押品的價值必須高於其所欠債務。如果不能保證這一過程會給他們帶來利潤，清算者就不會清算頭寸。

但是，一個頭寸何時可以清算？這個條件是由協議決定的，由他們分配給每個資產的清算閾值（liquidation threshold）的函數確定。

有了清算閾值，時間就成了關鍵。正如我們所知，如果一個頭寸的債務價值超過其抵押品的價值，清算這些頭寸對清算人來說是無利可圖的，協議會被壞账纏身。因此，安全的清算閾值爲清算人提供了足夠的時間，在他們達到無力償還之前清算超額抵押的頭寸。

現在我們了解了每個相關方保持頭寸健康的動機，我們將展示協議如何實際執行這些機制的例子：

Compound：账戶流動性

Compound，指的是他們在账戶流動性參數下的頭寸清算閾值，由 Compound 的主合約--Comptroller 計算。

Comptroller 有一個名爲getAccountLiquidity()的函數，返回關於账戶流動性的信息。在內部這個函數調用getHypotheticalAccountLiquidityInternal()：

pragma solidity ^ 0.8 .13;

struct AccountLiquidityLocalVars {
  uint sumCollateral;
  uint sumBorrowPlusEffects;
  uint cTokenBalance;
  uint borrowBalance;
  uint exchangeRateMantissa;
  uint oraclePriceMantissa;
  Exp collateralFactor;
  Exp exchangeRate;
  Exp oraclePrice;
  Exp tokensToDenom;
}

// ...

function getHypotheticalAccountLiquidityInternal(
  address account,
  CToken cTokenModify,
  uint redeemTokens,
  uint borrowAmount) internal view returns(Error, uint, uint) {

  AccountLiquidityLocalVars memory vars;
  uint oErr;

  CToken[] memory assets = accountAssets[account];
  for (uint i = 0; i < assets.length; i++) {
    CToken asset = assets[i];

    (oErr, vars.cTokenBalance, vars.borrowBalance, vars.exchangeRateMantissa) =
    asset.getAccountSnapshot(account);
    if (oErr != 0) {
      return (Error.SNAPSHOT_ERROR, 0, 0);
    }
    vars.collateralFactor = Exp({
      mantissa: markets[address(asset)].collateralFactorMantissa
    });
    vars.exchangeRate = Exp({
      mantissa: vars.exchangeRateMantissa
    });

    vars.oraclePriceMantissa = oracle.getUnderlyingPrice(asset);
    if (vars.oraclePriceMantissa == 0) {
      return (Error.PRICE_ERROR, 0, 0);
    }
    vars.oraclePrice = Exp({
      mantissa: vars.oraclePriceMantissa
    });
    vars.tokensToDenom = mul_(mul_(vars.collateralFactor, vars.exchangeRate),
      vars.oraclePrice);
    vars.sumCollateral = mul_ScalarTruncateAddUInt(vars.tokensToDenom,
      vars.cTokenBalance, vars.sumCollateral);
    vars.sumBorrowPlusEffects = mul_ScalarTruncateAddUInt(vars.oraclePrice,
      vars.borrowBalance, vars.sumBorrowPlusEffects);

    if (asset == cTokenModify) {
      vars.sumBorrowPlusEffects = mul_ScalarTruncateAddUInt(vars.tokensToDenom,
        redeemTokens, vars.sumBorrowPlusEffects);
      vars.sumBorrowPlusEffects = mul_ScalarTruncateAddUInt(vars.oraclePrice,
        borrowAmount, vars.sumBorrowPlusEffects);
    }
  }

  if (vars.sumCollateral > vars.sumBorrowPlusEffects) {
    return (Error.NO_ERROR, vars.sumCollateral - vars.sumBorrowPlusEffects, 0);
  } else {
    return (Error.NO_ERROR, 0, vars.sumBorrowPlusEffects - vars.sumCollateral);
  }
}

源碼^[6]

我們在這裏看到，這個函數的主要邏輯是在一個 for-loop 的範圍內。這表明，一個账戶的流動性是通過遍歷該账戶參與的所有市場來計算的。換句話說，在計算账戶流動性時，所有由账戶借入的資產，或用作抵押品的資產都會被考慮。

回顧一下，在我們的上一篇文章^[7]中，cTokenBalance是用戶作爲抵押品的標的資產的金額。在這個例子中，我們還可以看到 borrowBalance和一些神祕的 exchangeRateMantissa，它們都是由 getAccountSnapshot()返回。

在我們之前的文章中對可通用的exchangeRate變量的討論中：

一個任意的匯率， 如果其 exchangeRate<1，可以增加鑄幣量，如果 exchangeRate>1，可以減少鑄幣量

這對exchangeRateMantissa來說是成立的，它代表了cToken與標的資產之間的匯率。

在我們的例子中，可以看到，在獲得上面提到的 3 個參數後，監理公司要做的第一件事是獲得它目前正在迭代的特定市場的collateralFactor（抵押品系數）。這個 collateralFactor（抵押品系數）信息是一個指標，表明用戶可以用他們的抵押品借到多少錢。從這個定義中，我們可以假設，用戶對他們存入的每一個抵押品所能借到的金額都是不同的。

這個數額在不同資產之間不同的主要原因是，在協議的眼中，每個資產都有自己的 "風險"，這通常歸結爲一個資產的價值隨着時間的推移可能有多大的波動。

Compound 的治理（governance）會根據市場情況改變抵押品系數，但在任何時候，他們的抵押品系數不能超過 0.9--最多只能借到你所存抵押品的 90%：

pragma solidity ^ 0.8 .13;

uint internal constant collateralFactorMaxMantissa = 0.9e18; // 0.9

》 源碼^[8]

然後，我們看到對oracle.getUnderlyingPrice(asset)的調用，它調用了一個外部合約，稱爲Oracle^[9]。

Oracles 是借貸協議中使用的合約，用於獲取以某種通用貨幣（通常是美元、ETH 或協議使用的穩定幣）計價的某種資產的價格。

現在，我們已經涵蓋了所有影響單個市場的頭寸健康度的因素，所以我們將寫下計算單個市場的 "账戶流動性(AccountLiquidity)"的方程式：

注：在 Compound 中，資產的價格是以美元（USD）計價的。

這是一個相當多的變量，但如果你記的["份額代幣 "](https://learnblockchain.cn/article/5684 ""份額代幣 "")的 Compound 部分，你會看到表達式爲：

簡單地代表了用戶的 cTokens 的標的資產價值。

此外，borrowBalance_{user}變量，正如你在這裏看到的，是用戶借入資產的總余額，包括其應計利息。

因此，下面的账戶流動性方程是有意義的：

Maker

另一個爲清算抵押品不足的頭寸設定閾值的協議是 Maker。

讓我們研究一下該協議部署的處理清算的兩個合約：

• Dog：在遷移到清算 2.0 後部署的（正如 Maker 治理描述的）。這裏的清算功能是bark()。

• Cat：清算 1.2，bite()。

• grab()：在部署 Cat 合約之前，作爲清算的方式使用vat合約。

讓我們看一下bite()的代碼片段：

pragma solidity ^ 0.8 .13;

function bite(bytes32 ilk, address urn) external returns(uint id) {
    (, uint rate, uint spot) = vat.ilks(ilk);
    (uint ink, uint art) = vat.urns(ilk, urn);

    require(live == 1, "Cat/not-live");
    require(spot > 0 && mul(ink, spot) < mul(art, rate), "Cat/not-unsafe");

源碼^[10]

還有一個來自bark()的類似代碼片段：

pragma solidity ^ 0.8 .13;

function bark(bytes32 ilk, address urn, address kpr) external returns
  (uint256 id) {
    require(live == 1, "Dog/not-live");

    (uint256 ink, uint256 art) = vat.urns(ilk, urn);
    Ilk memory milk = ilks[ilk];
    uint256 dart;
    uint256 rate;
    uint256 dust; {
      uint256 spot;
      (, rate, spot, , dust) = vat.ilks(ilk);
      require(spot > 0 && mul(ink, spot) < mul(art, rate), "Dog/not-unsafe");

源碼^[11]

你可能注意到，兩者都有相同的不安全信息。因此，每個清算函數對金庫安全的要求是相同的，這可以用這個等式表示：

我們可以用它來定義需要保持的不等式，以使金庫（Maker 對頭寸的稱呼）仍然是安全的：

寫得更漂亮一些：

我們建議讀者繞道去看看MakerDAO 詞匯表^[12]，它擴展了我們提供的關於整個 Maker 生態系統的不同變量名稱和術語的信息。

另外，你也可以相信我們在這裏概述的內容：

spot_{ilk}在不等式中被用作抵押品的價格，以 DAI 爲單位並除以抵押品的清算率（由 governance 合約決定）。

ink_{urn}是頭寸的抵押品余額。

rate_{ilk}是特定抵押品類型的累積債務。當與art_{urn}（即一個頭寸借入的債務額）相乘，我們可以得到 DAI 的總債務。

爲了簡化我們剛才的內容，不使用 Maker 的術語，方程是這樣的：

注：Maker 使用 DAI -- 該協議自己的穩定幣 -- 來表示抵押品和債務的價值。

AAVE V2 - 健康系數

AAVE V2 也定義了他們自己的閾值，健康系數（HealthFactor）。一個健康系數值爲H_{f}<1 的用戶可以被清算。

這裏定義了：

pragma solidity ^ 0.8 .13;

vars.healthFactor = calculateHealthFactorFromBalances(
  vars.totalCollateralInETH,
  vars.totalDebtInETH,
  vars.avgLiquidationThreshold
);

// ...

/**
 * @dev Calculates the health factor from the corresponding balances
 * @param totalCollateralInETH The total collateral in ETH
 * @param totalDebtInETH The total debt in ETH
 * @param liquidationThreshold The avg liquidation threshold
 * @return The health factor calculated from the balances provided
 **/
function calculateHealthFactorFromBalances(
  uint256 totalCollateralInETH,
  uint256 totalDebtInETH,
  uint256 liquidationThreshold
) internal pure returns(uint256) {
  if (totalDebtInETH == 0) return uint256(-1);

  return (totalCollateralInETH.percentMul(liquidationThreshold)).wadDiv(totalDebtInETH);
}

源碼^[13]

很明顯，當用戶沒有債務時，他們的頭寸不能被清算，所以健康系數默認爲type(uint256).max。

否則，"健康系數"定義爲：

注：AAVE V2 以 ETH 表示其抵押品和債務價值。

其中 "LiquidationThreshold "是通過治理爲每個資產獨立定義的，這項任務目前委托給Gauntlet^[14]，它爲協議提供所有風險參數，包括 "LiquidationThreshold"。

穿倉頭寸分析

現在我們已經涵蓋了壞账的概念，我們將提供一個真實世界的例子來說明其重要性

我們將涉及的頭寸是 AAVE V2 的以下账戶：0x227cAa7eF6D955A92F483dB2BD01172997A1a623。

讓我們开始調查它的現狀，通過調用 AAVE V2 借貸協議上的getUserAccountData函數：

現在讓我們把上面看到的東西分解一下，體會一下這個倉位的水下情況有多嚴重：

• 債務總額（totalDebtETH）：17.83508595148699eth

• 抵押品總額（totalCollateralETH）：0.013596360502551568 eth

這就是我們需要了解的，這個倉位有問題--抵押品的價值對應其所產生的債務的一個微不足道的部分。

但是，這些頭寸是如何達到這種狀態的呢？

爲了回答這個問題，我們可以看看這個用戶在 AAVE 上執行的最新操作：

看起來一切都很好，直到13514857區塊，其中用戶從 AAVE 借用了一些資產。讓我們看看他們做了什么：

債務人借了 700,000 MANA，快速檢查一下 MANA 的美元價格會發現，價格是：

每 MANA 單位 0.00032838ETH。

所以通過一些簡單的乘法，我們知道這個用戶對協議的債務增加了：

0.00032838 * 700000 = 229.866 ETH

也值得回顧一下這個區塊的 ETH 的美元價格這裏^[15]，它是 4417.40 美元。

注意上圖中13517657區塊發生的入金操作，就在借款後的幾個小時。

讓我們看看市場上是否有什么東西動搖了用戶的信心：

➜~cast call - b 13517657 0xA50ba011c48153De246E5192C8f9258A2ba79Ca9 "getAssetPrice(address)"
0x0F5D2fB29fb7d3CFeE444a200298f468908cC942
0x000000000000000000000000000000000000000000000000000131d14dce4400

以上是一個發送到 AAVE V2 Price Oracle 的 RPC 調用，以獲得指定區塊的 1 單位 MANA 的價值，單位爲 Wei。

如果我們用這個數據轉換前述的價格，我們可以看到發生了什么：

0.00033625 * 700000 = 235.375 eth

在短短的幾個小時內，產生的債務是~5.5ETH，價值~24000 美元。哎喲。

由於我們知道這個頭寸的結局，我們知道它在某些時候是可以清算的，所以讓我們檢查涉及這個用戶地址的liquidationCall的調用：

select
evt_block_number,
collateralAsset,
debtAsset,
debtToCover,
liquidatedCollateralAmount,
liquidator
from
aave_v2_ethereum.LendingPool_evt_LiquidationCall
where
user = from_hex('0x227cAa7eF6D955A92F483dB2BD01172997A1a623')
order by
evt_block_number desc;

可以隨意在 Dune Analytics^[16]上運行上述查詢。

一旦我們找到第一個清算事件，我們就可以理解爲什么用戶在借貸後不久就存入了資產：

+------------------+--------------------------------------------+--------------------------------------------+-------------------------+----------------------------+--------------------------------------------+
| evt_block_number | collateralAsset                            | debtAsset                                  | debtToCover             | liquidatedCollateralAmount | liquidator                                 |
+------------------+--------------------------------------------+--------------------------------------------+-------------------------+----------------------------+--------------------------------------------+
|         13520838 | 0x6B175474E89094C44DA98B954EEDEAC495271D0F | 0x0F5D2FB29FB7D3CFEE444A200298F468908CC942 | 17919685927295406794873 |    58271102282974799175987 | 0xB2B3D5B6215D4FB23BF8DD642D385C4B44AADB2A |
+------------------+--------------------------------------------+--------------------------------------------+-------------------------+----------------------------+--------------------------------------------+

在這裏我們可以看到，第一次清算發生在區塊13520838。這次清算是在用戶還沒有存入資金之前（在存款交易之前約 7 分鐘）。

然後，在區塊13520838-13522070之間發生了一連串的小清算，價值不菲：

select
count( * ) as num_liquidations
from
aave_v2_ethereum.LendingPool_evt_LiquidationCall
where
user = from_hex('0x227cAa7eF6D955A92F483dB2BD01172997A1a623')
and evt_block_number <= 13522070 and evt_block_number >= 13520838

+ - - - - - - - - - +
| num_liquidations |
+ - - - - - - - - - +
| 87 |
+ - - - - - - - - - +

讓我們檢查一下在這些區塊之間被清算人從用戶那裏扣押的所有抵押資產類型：

select
SUM(liquidatedCollateralAmount) as amountSeized,
  collateralAsset
from
aave_v2_ethereum.LendingPool_evt_LiquidationCall
where
user = from_hex('0x227cAa7eF6D955A92F483dB2BD01172997A1a623')
and evt_block_number <= 13522070 and evt_block_number >= 13520838
group by collateralAsset

我們可以看到只有 2 種資產，DAI（穩定幣）和 ETH。

+--------------------------+--------------------------------------------+
| amountSeized             | collateralAsset                            |
+--------------------------+--------------------------------------------+
| 387663228503220484547359 | 0x6B175474E89094C44DA98B954EEDEAC495271D0F |
+--------------------------+--------------------------------------------+
| 499940913071713798854    | 0xC02AAA39B223FE8D0A0E5C4F27EAD9083C756CC2 |
+--------------------------+--------------------------------------------+

以及它們的金額：

• ~50 ETH

• ~387,663 DAI

有人可能會問，爲什么清算會發生是一小塊一小塊進行的？

好吧，當像這樣巨大的頭寸被一次性清算時，市場會將如此大規模的抵押品清算理解爲這些資產類型的賣出信號。記住：根據協議的清算人獎勵政策，清算中獲得的資產是以折扣價購买的。

隨着拋售壓力的增加，一次大規模的清算可能會產生一個清算的雪球。其他市場參與者可能也會出售他們的資產，導致資產價格進一步 "拋售"，這反過來又會導致協議中其他頭寸的更多清算。

因此，協議通常限制一次清算所能處理的資產量。AAVE 的這個限制的版本，作爲一個變量，可以看到下面：

pragma solidity ^ 0.8 .13;

// from ...

uint256 internal constant LIQUIDATION_CLOSE_FACTOR_PERCENT = 5000;

function liquidationCall(
  address collateralAsset,
  address debtAsset,
  address user,
  uint256 debtToCover,
  bool receiveAToken
) external override returns(uint256, string memory) {

    // ...

    vars.maxLiquidatableDebt =
      vars.userStableDebt.add(vars.userVariableDebt).percentMul(
        LIQUIDATION_CLOSE_FACTOR_PERCENT
      );

    // ...

我們可以看到，限制比例是 50%，這意味着在一次清算中只允許償還頭寸的一半債務。

清算人也有動力將清算分成小塊。如果在清算時，市場上沒有足夠的流動性，無法將抵押資產全額提供給清算人。通過將清算分成小塊，清算人有更大的機會獲得流動資產，並從清算中獲得利潤。

此外，如果市場上的債務資產沒有足夠的流動性，那么清算人甚至在一开始就獲得該資產以償還抵押不足的用戶的債務可能會成本昂貴。

最後，想象一下試圖清算大量的某種你不擁有這么多數量代幣。如果你去 DEX 並試圖用一些 WETH 或任何其他資產來交換這個代幣，你也可能會遇到很高的 Gas 費用，使你的清算無利可圖。

回到我們的例子，爲了檢查清算鏈後的頭寸參數，需要解析從getUserAccountData返回給我們的數據：

from io import BytesIO
from binascii import unhexlify
from dataclasses import dataclass


@dataclass(frozen=True)
class UserAccountData:
    totalCollateralETH: int
    totalDebtETH: int
    availableBorrowsETH: int
    currentLiquidationThreshold: int
    ltv: int
    healthFactor: int


def parse_user_account_data(uacd: str) -> UserAccountData:
    uacd_bytes = unhexlify(uacd[2:])

    assert len(uacd_bytes) == 192

    uacd_bytes = BytesIO(uacd_bytes)
    total_collateral_eth = int.from_bytes(bytes=uacd_bytes.read(32), byteorder="big", signed=False)
    total_debt_eth = int.from_bytes(bytes=uacd_bytes.read(32), byteorder="big", signed=False)
    available_borrows_eth = int.from_bytes(bytes=uacd_bytes.read(32), byteorder="big", signed=False)
    current_liquidation_threshold = int.from_bytes(bytes=uacd_bytes.read(32), byteorder="big", signed=False)
    ltv = int.from_bytes(bytes=uacd_bytes.read(32), byteorder="big", signed=False)
    health_factor = int.from_bytes(bytes=uacd_bytes.read(32), byteorder="big", signed=False)

    return UserAccountData(
        totalCollateralETH=total_collateral_eth,
        totalDebtETH=total_debt_eth,
        availableBorrowsETH=available_borrows_eth,
        currentLiquidationThreshold=current_liquidation_threshold,
        ltv=ltv,
        healthFactor=health_factor,
    )

然後我們用cast來查詢 chain 的情況：

➜  ~ cast call -b 13522070 0x7d2768dE32b0b80b7a3454c06BdAc94A69DDc7A9 "getUserAccountData(address)" 0x227cAa7eF6D955A92F483dB2BD01172997A1a623
0x000000000000000000000000000000000000000000000000085b5b5e846685f4000000000000000000000000000000000000000000000002743544e203a3e4ae00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001f710000000000000000000000000000000000000000000000000000000000001d9500000000000000000000000000000000000000000000000000260a45667b706b

最後解析輸出：

parse_user_account_data('0x000000000000000000000000000000000000000000000000085b5b5e846685f4000000000000000000000000000000000000000000000002743544e203a3e4ae00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001f710000000000000000000000000000000000000000
000000000000000000001d9500000000000000000000000000000000000000000000000000260a45667b706b')
UserAccountData(totalCollateralETH=602175436690458100, totalDebtETH=45267162967098778798, availableBorrowsETH=0, currentLiquidationThreshold=8049, ltv=7573, healthFactor=10707342303391851)

在這裏我們看到了清算對頭寸的影響：幾乎沒有任何抵押品了~准確地說，是 0.6 個 ETH。但是債務呢？45.26716296709878 ETH !

那么在這個區塊的高度，MANA 的價格是多少呢？

➜~cast call - b 13522070 0xA50ba011c48153De246E5192C8f9258A2ba79Ca9 "getAssetPrice(address)"
0x0F5D2fB29fb7d3CFeE444a200298f468908cC942
0x00000000000000000000000000000000000000000000000000031015cc1da8f2

0.000862110734985458 eth!

如果你還記得，用戶在幾個小時前剛剛以 0.00032838 ETH 的價格借入 MANA。這相當於在一只股票上开了一個空頭頭寸，而這只股票的價格是火箭般的 2.65 倍--Oof ?‍?!

清算者無法在 MANA 的價格拋售得太厲害之前及時清算全部頭寸，使這個過程無利可圖，我們就剩下一個無力償還的頭寸。

現在我們可以體會到一個有效的流動性閾值的重要性，在避免協議中的壞账。

小結:

雖然我們不能明確地說，可以用一個方程式來定義頭寸的流動性閾值，但我們肯定可以看到協議之間的相似之處：

• 所有協議都將其閾值定義爲抵押品與債務的某個函數（無論是比率還是差值）。

• 所有協議都留有一定的治理空間，以決定每個抵押品風險參數的價值，以應對市場條件的變化，因爲一些資產比其他資產更不穩定。

• 所有協議都使用預言機對其抵押品和債務價格進行計價，並使用廣泛接受的貨幣（例如，ETH，USD，DAI）。

我們已經看到，Maker 和 AAVE 選擇使用相同的方程式來表示頭寸的安全性：

作者：Tal^[17] 研究員 @ smlXL, 感謝 Sam Ragsdale^[18] 和爲本帖提供建議和反饋的 smlXL 團隊成員。

感謝 Chaintool^[19] 對本翻譯的支持。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。

---

標題：DeFi 借貸概念：清算

地址：https://www.torrentbusiness.com/article/35269.html

標籤：