梁培利DeFi去中心化金融課程筆記2024版

孤飞發表於2024-07-03
中心化筆記

課程連結：https://space.bilibili.com/220951871/channel/collectiondetail?sid=2824381&ctype=0

講義倉庫：https://github.com/liangpeili/defi-2024/tree/main

DeFi簡介

  • DeFi:Uniswap/AAVE/Curve/DAl/Compound等；
  • GameFi:從CryptoKitties開始；
  • SocailFi:nostr/Damus/friend.tech/xpet;
  • 國內目前政策：去fi留block,服務實體經濟

CeFi的主要組成機構與職能

  • 中央銀行：發行法定貨幣
  • 商業銀行：存款、結算、信貸等；
  • 保險公司：風險轉移與分散；
  • 證券公司：證券買賣、交易，證券承銷等；
  • 銀監會、證監會和保監會；
  • 國家金融監督管理總局

CeFi的特點

  • 集中的賬戶管理
  • 交易審查與監控
  • 基於對機構的信任
  • 手續費作為主要利潤來源
  • 不透明性/資訊差

DeFi的起點

Bitcoin:A Peer-to-Peer Electronic Cash System

2021：DeFi之夏

以太坊DeFi生態一覽：全球支付、錢包、基礎設施、交易所、投資、身份認證、市場、保險、借貸、穩定幣、衍生產品

DeFi的特點

  • 賬號個人管理：Not your keys,not your coins
  • 無需許可
  • 開源可驗證
  • 可程式設計性
  • 注意：目前國內並沒有做純Defi的政策空間

課程安排

  • 以Uniswap為核心，梳理DeFi領域的上下游產品及其原理
  • 從穩定幣入手，逐步介紹去中心化交易所Uniswap的核心邏輯，進而擴充套件到其他領域Defi產品（如借貸等）和演算法。
  • 理論課24學時+實驗課8學時
  • 《區塊鏈應用系統開發實踐》32學時

穩定幣

貨幣的演化

  • 實物貨幣
  • 金屬貨幣
  • 基於黃金等貴金屬抵押的法定貨幣
  • 基於信用的法定貨幣
  • 電子貨幣
  • 數字貨幣？

基於法幣抵押的穩定幣一一USDT

  • 穩定幣市值排名第一；
  • 由Tether發；
  • 中心化管理；
  • 可以凍結賬戶，銷燬黑U，增發；

基於法幣抵押的穩定幣—BUSD

  • Paxos發行的美元穩定幣
  • 受紐約金融服務局NYDFS的監管
  • 用了Binance的品牌
  • 可以1：1購買和贖回
  • 100%的美元或者美元現金等價物支撐
  • 僅在以太坊發行
  • 2023年2月份停止發行

基於加密資產超額抵押的穩定幣一DAI

  • DAl是Maker Protocol的主要產品；
  • Maker Protocol由MakerDAO管理；
  • MKR是MakerDAO的治理代幣；
  • 有利息

MakerDAO 生態組成

DAI的供應量控制

  • 貸款利率：Stability Fee
  • 存款利率：DAI Saving Rate(DSR)
  • 如果1DAI=0.99USD,提高利率
  • 如果1DAI=1.01USD,降低利率

思考：為什麼DAI會有怎麼高的年化盈利能力？

理解MakerDAO團隊如何透過DAI專案盈利，可以從以下幾個方面考慮：

  1. 穩定費用（Stability Fee）：
    MakerDAO透過向借款人收取穩定費用來盈利。當使用者將加密資產（如ETH）抵押以鑄造DAI時，需要支付穩定費用，這些費用是按借款金額的年化利率計算的。穩定費用的支付是透過MKR代幣進行的，這些費用最終會被銷燬，從而減少MKR的總供應量，提升其價值。

  2. 清算罰金（Liquidation Penalty）：
    當抵押品價值下降到一定程度（即抵押率低於維持率）時，會觸發清算過程。清算過程中，部分抵押品會被出售以償還債務。清算過程中會收取清算罰金，這也是一種收入來源。

  3. 協議費用（Protocol Fees）：
    MakerDAO可能會透過不同的協議費用來盈利，比如在特定操作或服務中收取一定比例的手續費。這些費用也會歸入專案的盈利。

  4. 增值的MKR代幣：
    透過收取穩定費用和清算罰金等方式，MakerDAO可以控制和減少MKR代幣的供應量。隨著專案的成功和生態系統的擴大，MKR代幣的需求增加，其市場價值也會隨之上升。MKR代幣增值是團隊和早期支持者的重要盈利途徑。

  5. 風險管理產品：
    MakerDAO團隊還可以開發和提供一些高階的金融工具和風險管理產品，這些產品可以在開放市場上銷售或作為服務的一部分，產生收入。

透過上述方式，MakerDAO團隊能夠透過其穩定幣專案實現盈利，同時維持DAI的穩定性和系統的正常執行。

案例分析

  • 假設 1 ETH = 2000 USD， 質押了5個ETH 到Maker Vault，按照150%的超額抵押率，最多可以借出

  • 10000 / 150% = 6666.67 個 DAI。保險起⻅，⽤戶借出 5000 DAI，其餘1666.67為緩衝區。

  • 情形1: ETH 漲價到3000 USD。此時5 ETH = 15000 USD，基於150%的抵押率，⽤戶最多可以借出10000 DAI。

  • 情形2: ETH 跌到1500 USD，此時5 ETH = 7500 USD， 7500 USD / 5000 DAI = 150%。⽤戶⾯臨三個選擇：

    • 往Maker Vault 質押更多的ETH；

    • 還回5000 DAI + Stability Fee， 拿回5個 ETH；

    • 還回部分DAI + Stability Fee，增加⾃⼰的緩衝區；

DAI 的防護網之一—— Colleteral Auction

  • 情形3: ETH 跌到1200 USD，此時5 ETH = 6000 USD，觸發清算，Keeper 介⼊清算流程；5 個ETH 按照市價折扣3%進⾏拍賣，每次增加0.5%，直到拍賣成功；
  • Keeper 使⽤DAI 來競拍，價⾼者得；
  • 扣除5000 DAI + Penalty Fee 等費⽤，其餘 ETH 返回給⽤戶；

DAI 的防護網之二—— Maker Buffer

  • Stability Fee/Penalty Fee等緩慢積攢；
  • 情形4: ETH 跌到900 USD，此時5 ETH = 4500 USD，拍賣後的缺⼝為 500 USD；
  • 從Maker Buffer ⽀付500 DAI， 彌補缺⼝；

DAI 的防護網之三—— Debt Auction

  • 情形5: ETH 跌到900 USD，此時5 ETH = 4500 USD，拍賣後的缺⼝為500 USD，⽽Maker Buffer ⾥只有100 DAI，資⾦缺⼝為400 USD。
    • 增發MKR 進⾏拍賣；
    • ⽤戶使⽤DAI 參與拍賣，拍賣得到的DAI 來彌補缺⼝；
    • ⼀種對社群治理懲罰的⽅式；

Decentralized Autonomous Organization (DAO)

  • ⼀種新型的組織形式
  • 發⾏治理Token
  • 治理Token 代表投票權
  • 社群共治、共建、共享

MakerDAO 的執行機制

提案階段

  1. 發起提案：任何MKR 持有⼈都可以發起新提案；
  2. 在MakerDAO 社群討論；
  3. 提交最佳化後的提案；
  4. Risk Team 對其進⾏⻛險評估；

投票階段

  • ⼀個MKR Token表示⼀個投票權，可以代理；
  • 投票期⼀般持續7天；
  • 根據投票結果決定是否透過；（4% 同意）

Surplus Auction

  • Maker Buffer Limit
  • 超出限制後的DAI ⽤來拍賣購買MKR；
  • 銷燬MKR；
  • ⼀種社群治理的獎勵⽅式；

基於演算法的穩定幣—一AMPL

總結

  • 穩定幣誕生的原因
  • 穩定幣的型別：USDT/USDC/BUSD/DAI/AMPL
  • USDT的中心性
  • DAI的執行原理
  • Maker Protocol中的清算
  • AMPL的執行原理

ERC4626

Vault

  • 資產的管理、分紅
  • 使用者充值某項資產，獲取某個憑證(避免使用費用高昂的鏈上資料庫)
  • 該憑證作為分紅、退出的依據
  • Yield Farming/借貸/質押等

ERC4626 assets & shares

  • 返回⾦庫的基礎資產代幣地址：

    function asset() external view returns (address assetTokenAddress);

  • 返回⾦庫管理的基礎代幣總額：

    function totalAssets() external view returns (uint256 totalManagedAssets);

  • 數量估計

    function convertToShares(uint256 assets) external view returns (uint256 shares);

function convertToAssets(uint256 shares) external view returns (uint256 assets);

充值資產，獲取shares

function maxDeposit(address receiver) external view returns (uint256 maxAssets);

function previewDeposit(uint256 assets) external view returns (uint256 shares);

function deposit(uint256 assets, address receiver) external returns (uint256 shares);

function maxMint(address receiver) external view returns (uint256 maxShares);

function previewMint(uint256 shares) external view returns (uint256 assets);

function mint(uint256 shares, address receiver) external returns (uint256 assets);

返還shares，拿回資產

function maxWithdraw(address owner) external view returns (uint256 maxAssets);

function previewWithdraw(uint256 assets) external view returns (uint256 shares);

function withdraw(uint256 assets, address receiver, address owner) external returns (uint256 shares);

function maxRedeem(address owner) external view returns (uint256 maxShares);

function previewRedeem(uint256 shares) external view returns (uint256 assets);

function redeem(uint256 shares, address receiver, address owner) external returns (uint256 assets);

兩個事件

event Deposit(address indexed sender, address indexed owner, uint256 assets, uint256 shares);

event Withdraw(address indexed sender,address indexed receiver,address indexed owner,uint256 assets,uint256 shares);

contracts/interfaces/IERC4626.sol:https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/interfaces/IERC4626.sol

// SPDX-License-Identifier: MIT
// OpenZeppelin Contracts (last updated v5.0.0) (interfaces/IERC4626.sol)

pragma solidity ^0.8.20;

import {IERC20} from "../token/ERC20/IERC20.sol";
import {IERC20Metadata} from "../token/ERC20/extensions/IERC20Metadata.sol";

/**
 * @dev Interface of the ERC-4626 "Tokenized Vault Standard", as defined in
 * https://eips.ethereum.org/EIPS/eip-4626[ERC-4626].
 */
interface IERC4626 is IERC20, IERC20Metadata {
    event Deposit(address indexed sender, address indexed owner, uint256 assets, uint256 shares);

    event Withdraw(
        address indexed sender,
        address indexed receiver,
        address indexed owner,
        uint256 assets,
        uint256 shares
    );

    /**
     * @dev Returns the address of the underlying token used for the Vault for accounting, depositing, and withdrawing.
     *
     * - MUST be an ERC-20 token contract.
     * - MUST NOT revert.
     */
    function asset() external view returns (address assetTokenAddress);

    /**
     * @dev Returns the total amount of the underlying asset that is “managed” by Vault.
     *
     * - SHOULD include any compounding that occurs from yield.
     * - MUST be inclusive of any fees that are charged against assets in the Vault.
     * - MUST NOT revert.
     */
    function totalAssets() external view returns (uint256 totalManagedAssets);

    /**
     * @dev Returns the amount of shares that the Vault would exchange for the amount of assets provided, in an ideal
     * scenario where all the conditions are met.
     *
     * - MUST NOT be inclusive of any fees that are charged against assets in the Vault.
     * - MUST NOT show any variations depending on the caller.
     * - MUST NOT reflect slippage or other on-chain conditions, when performing the actual exchange.
     * - MUST NOT revert.
     *
     * NOTE: This calculation MAY NOT reflect the “per-user” price-per-share, and instead should reflect the
     * “average-user’s” price-per-share, meaning what the average user should expect to see when exchanging to and
     * from.
     */
    function convertToShares(uint256 assets) external view returns (uint256 shares);

    /**
     * @dev Returns the amount of assets that the Vault would exchange for the amount of shares provided, in an ideal
     * scenario where all the conditions are met.
     *
     * - MUST NOT be inclusive of any fees that are charged against assets in the Vault.
     * - MUST NOT show any variations depending on the caller.
     * - MUST NOT reflect slippage or other on-chain conditions, when performing the actual exchange.
     * - MUST NOT revert.
     *
     * NOTE: This calculation MAY NOT reflect the “per-user” price-per-share, and instead should reflect the
     * “average-user’s” price-per-share, meaning what the average user should expect to see when exchanging to and
     * from.
     */
    function convertToAssets(uint256 shares) external view returns (uint256 assets);

    /**
     * @dev Returns the maximum amount of the underlying asset that can be deposited into the Vault for the receiver,
     * through a deposit call.
     *
     * - MUST return a limited value if receiver is subject to some deposit limit.
     * - MUST return 2 ** 256 - 1 if there is no limit on the maximum amount of assets that may be deposited.
     * - MUST NOT revert.
     */
    function maxDeposit(address receiver) external view returns (uint256 maxAssets);

    /**
     * @dev Allows an on-chain or off-chain user to simulate the effects of their deposit at the current block, given
     * current on-chain conditions.
     *
     * - MUST return as close to and no more than the exact amount of Vault shares that would be minted in a deposit
     *   call in the same transaction. I.e. deposit should return the same or more shares as previewDeposit if called
     *   in the same transaction.
     * - MUST NOT account for deposit limits like those returned from maxDeposit and should always act as though the
     *   deposit would be accepted, regardless if the user has enough tokens approved, etc.
     * - MUST be inclusive of deposit fees. Integrators should be aware of the existence of deposit fees.
     * - MUST NOT revert.
     *
     * NOTE: any unfavorable discrepancy between convertToShares and previewDeposit SHOULD be considered slippage in
     * share price or some other type of condition, meaning the depositor will lose assets by depositing.
     */
    function previewDeposit(uint256 assets) external view returns (uint256 shares);

    /**
     * @dev Mints shares Vault shares to receiver by depositing exactly amount of underlying tokens.
     *
     * - MUST emit the Deposit event.
     * - MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the
     *   deposit execution, and are accounted for during deposit.
     * - MUST revert if all of assets cannot be deposited (due to deposit limit being reached, slippage, the user not
     *   approving enough underlying tokens to the Vault contract, etc).
     *
     * NOTE: most implementations will require pre-approval of the Vault with the Vault’s underlying asset token.
     */
    function deposit(uint256 assets, address receiver) external returns (uint256 shares);

    /**
     * @dev Returns the maximum amount of the Vault shares that can be minted for the receiver, through a mint call.
     * - MUST return a limited value if receiver is subject to some mint limit.
     * - MUST return 2 ** 256 - 1 if there is no limit on the maximum amount of shares that may be minted.
     * - MUST NOT revert.
     */
    function maxMint(address receiver) external view returns (uint256 maxShares);

    /**
     * @dev Allows an on-chain or off-chain user to simulate the effects of their mint at the current block, given
     * current on-chain conditions.
     *
     * - MUST return as close to and no fewer than the exact amount of assets that would be deposited in a mint call
     *   in the same transaction. I.e. mint should return the same or fewer assets as previewMint if called in the
     *   same transaction.
     * - MUST NOT account for mint limits like those returned from maxMint and should always act as though the mint
     *   would be accepted, regardless if the user has enough tokens approved, etc.
     * - MUST be inclusive of deposit fees. Integrators should be aware of the existence of deposit fees.
     * - MUST NOT revert.
     *
     * NOTE: any unfavorable discrepancy between convertToAssets and previewMint SHOULD be considered slippage in
     * share price or some other type of condition, meaning the depositor will lose assets by minting.
     */
    function previewMint(uint256 shares) external view returns (uint256 assets);

    /**
     * @dev Mints exactly shares Vault shares to receiver by depositing amount of underlying tokens.
     *
     * - MUST emit the Deposit event.
     * - MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the mint
     *   execution, and are accounted for during mint.
     * - MUST revert if all of shares cannot be minted (due to deposit limit being reached, slippage, the user not
     *   approving enough underlying tokens to the Vault contract, etc).
     *
     * NOTE: most implementations will require pre-approval of the Vault with the Vault’s underlying asset token.
     */
    function mint(uint256 shares, address receiver) external returns (uint256 assets);

    /**
     * @dev Returns the maximum amount of the underlying asset that can be withdrawn from the owner balance in the
     * Vault, through a withdraw call.
     *
     * - MUST return a limited value if owner is subject to some withdrawal limit or timelock.
     * - MUST NOT revert.
     */
    function maxWithdraw(address owner) external view returns (uint256 maxAssets);

    /**
     * @dev Allows an on-chain or off-chain user to simulate the effects of their withdrawal at the current block,
     * given current on-chain conditions.
     *
     * - MUST return as close to and no fewer than the exact amount of Vault shares that would be burned in a withdraw
     *   call in the same transaction. I.e. withdraw should return the same or fewer shares as previewWithdraw if
     *   called
     *   in the same transaction.
     * - MUST NOT account for withdrawal limits like those returned from maxWithdraw and should always act as though
     *   the withdrawal would be accepted, regardless if the user has enough shares, etc.
     * - MUST be inclusive of withdrawal fees. Integrators should be aware of the existence of withdrawal fees.
     * - MUST NOT revert.
     *
     * NOTE: any unfavorable discrepancy between convertToShares and previewWithdraw SHOULD be considered slippage in
     * share price or some other type of condition, meaning the depositor will lose assets by depositing.
     */
    function previewWithdraw(uint256 assets) external view returns (uint256 shares);

    /**
     * @dev Burns shares from owner and sends exactly assets of underlying tokens to receiver.
     *
     * - MUST emit the Withdraw event.
     * - MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the
     *   withdraw execution, and are accounted for during withdraw.
     * - MUST revert if all of assets cannot be withdrawn (due to withdrawal limit being reached, slippage, the owner
     *   not having enough shares, etc).
     *
     * Note that some implementations will require pre-requesting to the Vault before a withdrawal may be performed.
     * Those methods should be performed separately.
     */
    function withdraw(uint256 assets, address receiver, address owner) external returns (uint256 shares);

    /**
     * @dev Returns the maximum amount of Vault shares that can be redeemed from the owner balance in the Vault,
     * through a redeem call.
     *
     * - MUST return a limited value if owner is subject to some withdrawal limit or timelock.
     * - MUST return balanceOf(owner) if owner is not subject to any withdrawal limit or timelock.
     * - MUST NOT revert.
     */
    function maxRedeem(address owner) external view returns (uint256 maxShares);

    /**
     * @dev Allows an on-chain or off-chain user to simulate the effects of their redeemption at the current block,
     * given current on-chain conditions.
     *
     * - MUST return as close to and no more than the exact amount of assets that would be withdrawn in a redeem call
     *   in the same transaction. I.e. redeem should return the same or more assets as previewRedeem if called in the
     *   same transaction.
     * - MUST NOT account for redemption limits like those returned from maxRedeem and should always act as though the
     *   redemption would be accepted, regardless if the user has enough shares, etc.
     * - MUST be inclusive of withdrawal fees. Integrators should be aware of the existence of withdrawal fees.
     * - MUST NOT revert.
     *
     * NOTE: any unfavorable discrepancy between convertToAssets and previewRedeem SHOULD be considered slippage in
     * share price or some other type of condition, meaning the depositor will lose assets by redeeming.
     */
    function previewRedeem(uint256 shares) external view returns (uint256 assets);

    /**
     * @dev Burns exactly shares from owner and sends assets of underlying tokens to receiver.
     *
     * - MUST emit the Withdraw event.
     * - MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the
     *   redeem execution, and are accounted for during redeem.
     * - MUST revert if all of shares cannot be redeemed (due to withdrawal limit being reached, slippage, the owner
     *   not having enough shares, etc).
     *
     * NOTE: some implementations will require pre-requesting to the Vault before a withdrawal may be performed.
     * Those methods should be performed separately.
     */
    function redeem(uint256 shares, address receiver, address owner) external returns (uint256 assets);
}

ERC4626 Vault Smart Contract tutorial | DeFi Vault tutorial

去中心化交易所

中心化交易所的業務模式——以幣安為例

  • 交易費：交易所透過提供買賣加密貨幣的平臺來收取交易費用有些交易所還提供高階交易選項，如槓桿交易，這通常會帶來更高的費用；
  • 上幣費：專案方團隊後面都會去找交易所上幣，然而上幣需要繳納一筆數額不小的上幣費；
  • 量化交易：使用者在交易所中，一般數字資產幣都是暫時存放在交易所，基本上交易所掌握所有籌碼可以選擇做多或者做空，交易所可以去賺取差價，而使用者提幣出去也能賺取手續費；
  • 原生代幣；

中心化交易所的交易模式——訂單簿模式

  • 中央限價訂單簿(CLOB)就是一本由出價和報價組成的許可權透明賬本，從最好價開始依次排序(兩邊分別是參與者願意買/賣的價格)。
  • 所有的參與者都能看到所有的報價和出價，他們也可以參與其中。
  • 訂單簿中兩邊的第一行，即是最好的報價/出價。

訂單簿模式的優劣優勢

  • 優勢

    • 透明的流動性

    • 做市商可自由出入

    • 做市商可以自由決定價格與數量

  • 劣勢

    • 冷啟動問題（很難給出初始流動性)
    • 對非流動性資產不利
    • 如果是鏈上交易所，則對鏈的TPS的要求很高

鏈上交易方案：自動做市商

  • 出現原因：以太坊的TPS對於支撐鏈上訂單簿的實時更新來說太低了。反面案例：Solana鏈由於其60K的TPS,其上有許多訂單簿模式的交易所。
  • 交易所裡沒有訂單簿，只有一系列預設的函式，為各類貨幣的互相交換來定價。
  • 這些預設的函式（例如×*y=k)基於兩頭貨幣在各自流動性池中的供給變化率，來設定價格。在某個貨幣的流動性池內，任何人都能夠提供該種貨幣以增加其流動性，從而獲得收益。

CPAMM:Constant Product Auto Market Maker

  • 基礎公式：xy=k
  • Liquidity Provider(LP)5 Liquidity Provider Token(LPT)
  • LPT數量s=sqrt(x*y)
  • 初始流動性確定價格

Dex的去中心性

  • 任何人都可以新增流動性，成為LP,並拿到LP Token;
  • LP在任意時間可以移除流動性並銷燬LP Token,拿回自己新增的Token;
  • 使用者可以使用非官方的前端頁面來進行交易；
  • 交易時收取一定手續費，並且分配給LPT Holder;

自動化做市模式的優劣

  • 優勢：

    • 對於新的代幣，可以很方便的冷啟動

    • 去中心化

    • 代幣交換可組合性很高

  • 劣勢：

    • 所有價格點的統一流動性（在Uniswap V3中已解決)

    • 滑點頻繁

    • 波動性大，經常有很大的臨時虧損（流動性提供者在平均表現上是盈利的)

CPAMM裡的數學

  • 起始狀態：x*y=k
  • 新增流動性Add liquidity
    • (x+△x)y+△y)=k1,其中△x/△y=×/y,k1>k
  • 交易Swap
    • (x-△x)y+△y)=k或(X+△x)y-△y)=k
  • 移除流動性Remove liquidity
    • (x-△X)y-△y)=k2,其中△x/△y=×/y,k2<k

Uniswap

Uniswap 簡介

Uniswap更新歷史

Uniswap V2
  • 2020年5月釋出
  • 增加ERC20-ERC20直接互換
  • 增加Flash Swap快閃記憶體交換
  • 增加Oracle預言機
  • 改進手續費收取方式
  • 引爆了DeFi賽道
  • 2020年9月，發行治理代幣UNI
Uniswap V2的核心合約
  • Uniswap V2 Core
    • UniswapV2Pair.sol
    • UniswapV2Factory.sol
  • Uniswap V2 Periphery
    • Router contract
    • Library contract
Uniswap vs SushiSwap
  • 2020年8月28日，SushiSwap釋出；
  • SushiSwap fork了Uniswap,並且做了一些改進；
  • SushiSwap增加了獎勵系統，從Uniswap吸引走許多流動性；
  • 作為回擊，2020年9月Uniswap宣佈發行UN‖作為治理代幣；
Uniswap V3
  • 2021年5月，Uniswap V3釋出；
  • 主要特性：
    • 增加集中流動性：
    • 最佳化手續費設定；
    • LPT改成基於NFT的Liquidity Token;
    • 改進開源協議；
Uniswap V4
  • 2023年6月23日釋出程式碼草案；
  • 新增主要特性：
    • Hook
    • Singleton Pool Manager Design
    • Reintroduction of Native ETH
    • Flash Accounting
  • 目標：更快、更省gas fee,容易整合；成為DeFi領域的基礎設施；

Uniswap vs Binance

  • 無須實名認證程式碼開源
  • 上幣不收費
  • 使用者自己管理資金，不用託管到交易所
  • 社群治理

後續將詳細分析Uniswap的數學模型，建議直接觀看影片並手寫筆記！

https://www.bilibili.com/video/BV1nw4m1Q7hd/?spm_id_from=333.788&vd_source=06e4e8652ea90d79dadb7a59ff8acd36

去中心化借貸

為什麼會有借貸這個業務？

  • 需求方（創業、購車、購房等)和資金方的匹配；
  • 銀行的主要利潤來源；
  • 借唄、微粒貸等網際網路產品；
  • 用好了是助力，用不好是災難；
  • 最簡單直接的策略：不碰網貸；

區塊鏈裡的借貸

中心化借貸產品：Genesis Capita/BlockFi等；
去中心化借貸產品：AAVE、Compound、dy/dx等；

Borrower端需要考慮的問題

  • 1.抵押物是什麼？
  • 2.抵押率怎麼定？
  • 3.借款利率
    • 是多少？
    • 怎麼確定？
    • 如何根據市場情況變化？
  • 4.清算
    • 什麼情況下會被清算？
    • 怎樣清算？
    • 價格來源是什麼？

平臺方需要考慮的問題

  • 如何保護存款人的資金？
  • 如何在提高資金利用率的情況下，保障存款人的正常業務？
  • 收多少個點的服務費？
  • 平臺執行異常的情況下如何應對？

貸款利率的確定

  • 目標：
    • 提高存款使用率
    • 保證存款人自由提取，防止擠兌
  • 存款使用率的定義：存款使用率=未還借款數量/（未還借款數量+剩餘存款數量)
  • 根據存款使用率動態調節貸款利率

存款利率的確定

  • 存款×存款利率+fee=借款×借款利率
  • 存款利率<借款利率

資產託管

  • 資產託管在智慧合約
  • 有沒有託管憑證
    • 借貸複式記賬法
    • 使用token做憑證
  • 復投的利息計算
    • daily compound
    • monthly compound
    • block compound

複式記賬vs Token憑證

  • T0時刻，使用者A存入100DAI
  • T1時刻，從T0到現在產生利息20DAI,此時使用者B存入100DAI
  • T2時刻，從T1到現在產生利息20DAI
  • 問：使用者A和使用者B的利息各自是多少？
    • 複式記賬法計算
    • 使用Token憑證計算
    • 使用者A:100DAl->100cDAl
    • 使用者B:100DA1->100100/120->83.33cDA
  • 使用Token憑證的優勢：
    • 省去複雜的計算過程
    • cToken可以在市面流通

抵押物和抵押率

  • 一般基於超額抵押來控制風險
  • 流動性差、流動性小的代幣需要更高的抵押率；
  • 流動性好、流動量大的代幣需要較低的抵押率；

清算

目的：保護存款人，償還存款人的資產；
健康因子公式：

\[\begin{aligned}&\mathrm{Health} Factor= \frac{\Sigma Value of Collateral_{i}*Liquidation Threshold_{i}}{Total Value of Debts}\\&0<\mathrm{Liquidation~Threshold}<1\end{aligned} \]

清算閾值是衡量資產安全的一個標準；
當健康因子小於1時，說明該頭寸可被清算；

清算的方式

  • 荷蘭式拍賣：Maker Protocol/DDEX
  • 獎勵Keeper:按市場價給予一定的折扣，比如5%
  • 現貨市場出售：CEX/DEX

資產價格來源預言機

  • 中心化預言機；
  • 去中心化預言機，如Chainlink等；
  • 預言機的任何失誤都會導致災難性的結果；

使用借貸產品的理由

  • 存款人：存款收利息
  • 借款人：
    • 做多
    • 做空
    • 借款投資
    • 使用價值

相關文章