梁培利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專案盈利，可以從以下幾個方面考慮：

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

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

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

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

風險管理產品：
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 的執行機制

提案階段

發起提案：任何MKR 持有⼈都可以發起新提案；
在MakerDAO 社群討論；
提交最佳化後的提案；
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等；
預言機的任何失誤都會導致災難性的結果；

使用借貸產品的理由

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

DEFI去中心化交易所開發，DEFI去中心化交易APP原始碼系統
2022-01-28
中心化APP原始碼
去中心化金融平臺deFI開發優勢及步驟詳解
2023-05-19
中心化
Morton網格交易法去中心化金融DeFi新興模式開發
2023-04-27
中心化模式
去中心化defi金融信貸平臺開發設計邏輯及原始碼分析
2023-05-10
中心化原始碼
網站SEO課程筆記整理版！
2020-08-21
網站筆記
網站SEO課程筆記整理版（2）
2020-08-22
網站筆記
機器學習課程筆記
2018-05-15
機器學習筆記
中心化與去中心化
2014-01-23
中心化
python課程筆記
2016-06-15
Python筆記
【課程筆記】中科大凸優化（三）
2022-03-06
筆記優化
【課程筆記】中科大凸優化（二）
2022-02-28
筆記優化
史丹佛大學凸優化課程筆記-0
2018-02-21
優化筆記
去中心化Defi單雙幣質押挖礦系統開發|DeFi合約開發
2023-05-11
中心化
會計學課程筆記
2020-10-22
筆記
王道C短期課程筆記
2021-01-01
筆記
物聯網課程筆記
2024-04-14
筆記
以太坊學習筆記————3、WEB：去中心化應用平臺
2018-06-17
筆記Web中心化
去中心化衍生品交易：dYdX如何用槓桿交易賦能DeFi牛市?
2020-11-30
中心化
FINTOCH（分投趣）去中心化金融平臺開發特性分析
2023-05-11
中心化
達內課程學習筆記
2018-08-23
筆記
萬物互聯課程筆記
2018-08-17
筆記
Stanford機器學習課程筆記——SVM
2015-01-29
機器學習筆記
UI設計課程筆記（三）
2016-03-23
UI筆記
[Triton課程筆記] 2.2.3 BLS續
2024-06-26
筆記
3.17去中心化微博
2018-11-08
中心化
去中心化的思考
2017-12-19
中心化
國際貨幣基金組織：去中心化金融的承諾與陷阱
2023-01-10
中心化
區塊鏈去中心化和傳統去中心化的區別
2018-09-04
區塊鏈中心化
遨遊Unix–APUE課程筆記【１】
2019-05-12
筆記
資料庫課程作業筆記
2019-04-24
資料庫筆記
Python基礎課程筆記5
2021-09-09
Python筆記
Andrew ng 深度學習課程筆記
2018-01-27
深度學習筆記
遨遊Unix — APUE課程筆記【2】
2017-06-07
筆記
什麼是去中心化錢包？去中心化錢包是什麼意思？
2022-06-18
中心化
谷歌機器學習課程筆記（4）——降低損失
2018-10-19
谷歌機器學習筆記
《資料庫系統原理》課程筆記
2020-11-02
資料庫筆記
data cleaning(資料清洗) 課程筆記
2014-08-11
筆記
3月24日廣州DBA課程筆記
2007-04-05
筆記
MIT6S081課程筆記
2024-05-12
MIT筆記