目录

1. 前言   1.1

2. AAVE借贷协议概述   1.2

1. 核心逻辑和架构   1.2.1

3. 借贷逻辑   1.3

1. deposit=存款   1.3.1

2. borrow=借款   1.3.2

3. repay=偿还   1.3.3

4. redeem=赎回   1.3.4

5. liquidation=清算   1.3.5

1. 健康因子Health Factor   1.3.5.1

6. Swap borrow rate mode=切换借贷利率模型   1.3.6

4. 子模块   1.4

1. aToken   1.4.1

1. 代币的作用   1.4.1.1

2. Governance治理   1.4.2

3. Safety Module安全模块   1.4.3

4. Flash Loan闪电贷   1.4.4

5. 稳定币GHO   1.4.5

6. Credit Delegation信用委托   1.4.6

7. Debt Tokenization=债务代币化   1.4.7

5. 利率模型   1.5

1. 可变利率vs稳定利率   1.5.1

2. 稳定利率   1.5.2

3. 各种参数   1.5.3

6. 版本   1.6

1. AAVE v1   1.6.1

2. AAVE v2   1.6.2

1. Gas优化和改进   1.6.2.1

3. AAVE v3   1.6.3

1. E-Mode   1.6.3.1

2. Isolation Mode   1.6.3.2

3. Portal   1.6.3.3

4. Risk Management   1.6.3.4

1. Granular borrowing power control   1.6.3.4.1

2. Price Oracle Sentinel   1.6.3.4.2

3. Siloed Borrowing   1.6.3.4.3

5. 权限和角色管理   1.6.3.5

6. 协议特性   1.6.3.6

7. Multiple Rewards and Claim   1.6.3.7

7. 对比   1.7

1. AAVE vs Compound   1.7.1

8. 开发相关   1.8

1. 核心的类和代码   1.8.1

2. AAVE V3合约概览   1.8.2

3. 审计报告   1.8.3

4. 漏洞赏金   1.8.4

9. 附录   1.9

1. 名词和术语   1.9.1

2. AAVE资料   1.9.2

3. AAVE发展进化历史   1.9.3

4. 参考资料   1.9.4

借贷协议：AAVE

- 最新版本： v1.0.0

- 更新时间： 20240930

简介

整理介绍区块链和加密货币领域中的借贷协议龙头之一：AAVE。先是概述和核心逻辑架构；然后是借贷协议，包括deposit存款、borrow借款、repay偿还、redeem赎回、liquidation清算和借贷利率模型；清算包括健康因子；以及子模块，包括aToken及代币的作用、Governance治理、Safety Module安全模块、Flash Loan闪电贷、稳定币GHO、Credit Delegation信用委托、Debt Tokenization债务代币化；以及利率模型，包括可变利率、稳定利率、两者对比、各种参数；以及三种版本AAVE v1、v2、v3，以及相关的Gas优化、E-Mode、Isolation Mode、Portal、Risk Management的Granular borrowing power control、Price Oracle Sentinel、Siloed Borrowing、权限和角色管理、协议特性、Multiple Rewards and Claim；以及AAVE和其他的对比，比如Compound；再就是开发相关的核心类和代码、V3合约概览、审计报告、漏洞赏金；最后附录加上名字术语、AAVE资料、发展进化历史等。

源码+浏览+下载

本书的各种源码、在线浏览地址、多种格式文件下载如下：

HonKit源码

- crifan/lending_protocol_aave: 借贷协议：AAVE

如何使用此HonKit源码去生成发布为电子书

详见：crifan/honkit_template: demo how to use crifan honkit template and demo

在线浏览

- 借贷协议：AAVE book.crifan.org

- 借贷协议：AAVE crifan.github.io

离线下载阅读

- 借贷协议：AAVE PDF

- 借贷协议：AAVE ePub

- 借贷协议：AAVE Mobi

版权和用途说明

此电子书教程的全部内容，如无特别说明，均为本人原创。其中部分内容参考自网络，均已备注了出处。如发现有侵权，请通过邮箱联系我  admin 艾特 crifan.com ，我会尽快删除。谢谢合作。

各种技术类教程，仅作为学习和研究使用。请勿用于任何非法用途。如有非法用途，均与本人无关。

鸣谢

感谢我的老婆陈雪的包容理解和悉心照料，才使得我 crifan 有更多精力去专注技术专研和整理归纳出这些电子书和技术教程，特此鸣谢。

其他

作者的其他电子书

本人 crifan 还写了其他 150+ 本电子书教程，感兴趣可移步至：

crifan/crifan_ebook_readme: Crifan的电子书的使用说明

关于作者

关于作者更多介绍，详见：

关于CrifanLi李茂 – 在路上

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 10:15:16

AAVE借贷协议概述

ETHLend

- ETHLend

- AAVE前身是ETHLend

- ETHLend = ETH Lend = 以太币的借贷

- 发展历史

- 于2017年由早期加密货币采纳者Stani Kulechov创立，最初推出的名称是ETHLend (LEND)，以应对缺乏基于以太坊网络的借贷应用

- 2018年9月，ETHLend更名为Aave

- 主要模式：P2P借贷

- P2P贷款业务结构

- P2P托管借贷存在的问题

- P2P借贷是通过在线平台将贷款方（lender）和借款方（borrower）联系起来，以便难以从金融机构获得贷款的个人或公司通过中间利率（约8–12％）来获得贷款。另一方面，韩国不少用户把P2P贷款借贷服务称为“众筹型贷款”。换句话来讲，从个人那里收集的资金为对个人，公司和项目提供贷款服务，其偿还的本金和利息重新分配给投资者的商业模型。因此，P2P贷方主要负责1）代表投资者直接对借款方进行信用评估并厘定贷款协议，2）委托管理客户资产（贷款，抵押品等）

AAVE

- AAVE

- Logo

- 中文： 阿夫

- 名称含义

- Aave在芬兰语中是“鬼”的意思

- 为了强调该协议的理念：在DeFi段中建立一个清晰开放的生态系统

- 所以Logo是鬼=幽灵的图案

- 是什么

- DeFi借贷平台

- DeFi领域中一种借贷协议=一个借贷平台

- 一种允许用户借入加密资产并从存款中获利的开源协议

- 一个去中心化的非托管流动性市场协议

- 一个非托管的DeFi协议

- 在去中心化的环境中为客户提供一系列金融服务

- 综述

- 3.AAVE

- 项目类型：借贷

- 支持公链：以太坊生态的 7 条公链

- TVL：39 亿美元

- 项目定位：基于以太坊生态的去中心化借贷平台

- 项目优势：创新性地设置了安全模块，增强了资金安全性

- 运作机制：Aave 是一个多链借贷协议，用户可以通过存款赚取收益，也可以存入支持的抵押物并借入其它资产。协议收取一部分利息收入，用于维持 DAO 并支持协议贡献者。收取的比例由储备系数决定，根据资产风险的不同，储备系数在 10%～35% 之间

- 概述

- Aave是一个去中心化的非托管流动性市场协议，用户可以作为供应商或借款人参与其中。供应商向市场提供流动性以赚取被动收入，而借款人能够以过度抵押(永久)或抵押不足(一次性流动性)的方式借款

- 最大特点

- 闪电贷

- 多代币支持

- 无抵押借贷

- 发展情况

- AAVE已集成到其他平台、钱包等

- My Ether Wallet

- DeFi Saver

- Idle Finance

- Zerion

- Trustwallet

- 安全模块

- （1）用户可以将他们的代币质押在安全模块（SM），以提供可用于保护协议的资金，相应地他们也可以获得由生态系统储备基金发出的 AAVE 代币奖励。

- （2）安全模块可以保护协议免受资金短缺事件的影响。当智能合约风险、预言机故障和清算风险导致资金意外损失时，可能会发生资金短缺事件。在这种情况下，安全模块最多可以使用资金的 30% 来维持协议的稳定。

- （3）安全模块中质押的资金让 AAVE 代币的持有者能够捕获协议的价值，并能够提供链上交易所需的流动性，又让普通用户的资金更加安全。协议允许额外铸造 AAVE 代币，并通过拍卖来偿还债务，让协议的正常运行多了一重保险。

- 代币

- ETHLend的：LEND

- aave

- 代币：AAVE

- 属于：Aave

- 概述：Aave通过改进提案(AP1)，在2020年10月3日(区块高度10978863)将Aave平台代币LEND以100:1的比例转换为AAVE。Aave是一个开源的去中心化借贷协议，为用户提供存款和借贷服务。借贷双方用户的存款利率与贷款利率是根据平台借款量和存款量通过算法来计算得到的，并且平台采用Chainlink的预言机来保证抵押物价格的公平性。

- 衍生代币=协议代币：aToken

- 稳定币：GHO

- 路线图=发展历史

- 2017年11月

- ETHLend在ICO中募集了1600万美元。这笔资金被用来创建一个去中心化的点对点借贷平台。

- 2018年9月

- 一家新的母公司，Aave，宣布将取代ETHLend。

- 2019年10月

- Aave V1公共测试网正式上线。

- 2020年1月

- Aave V1上线。ETHLend停止运作。

- 2020年10月

- 发行AAVE加密代币（以1:100的比例从旧代币LEND迁移到AAVE）。

- 2020年12月

- AAVE V2上线，它包含几个新功能，而Aave V1继续运行。

- 2021年7月

- Aave计划中的机构型DeFi产品Aave Pro被改名为Aave Arc。原因是要把它的功能描绘成机构进入去中心化金融领域的门槛

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 10:09:02

核心逻辑和架构

- AAVE借贷协议

- 协议版本

- AAVE v1

- 详见：AAVE V1

- AAVE v2

- 详见：AAVE V2

- AAVE v3

- 详见：AAVE V3

- 核心内容

- ETHLend

- AAVE V2

- 协议架构Protocol Architecture

- AAVE v1

- AAVE V2

- 对比

- V2和V1架构图的核心区别

1. 以前存储在LendingPoolCore合约中的资金现在存储在每个特定的attoken中

2. 这使得协议在资产之间更好地隔离，这有利于实现可感知产量的attoken。

1. LendingPoolCore和LendingPoolDataProvider已被删除并替换为库。这在优化代码复杂性和冗长性的同时，将所有操作的气体足迹减少了15%到20%。

1. 现在所有的动作都通过LendingPool进行;在每个token上替换以前需要的redeem()。

1. 债务代币跟踪用户债务

- 核心流程

- 关键词=核心动作=核心事件

- 包括

- deposit=存入

- redeem == withdraw=取回

- borrow=借出

- repay=偿还

- swap = Rate swap == Swap borrow rate mode = 利率调整 = 切换借贷利率模型

- liquidation=清算

- 其他特殊

- flash loan=闪电贷

- 对应合约中的函数

- LendingPool

- deposit()

- withdraw()

- borrow()

- repay()

- swapBorrowRateMode()

- setUserUseReserveAsCollateral()

- flashloan()

- liquidationCall()

- 主要逻辑、关系、顺序

- 先存款deposit -> 后赎回redeem==withdraw

- 先借款borrow -> 后偿还repay / 或清算liquidation

- 根据需要，去切换借贷利率模型Swap borrow rate mode ？

- AAVE借贷流程 流程

- 概述

- LendingPool合约中实现的高级功能之一是贷款头寸的标记化。当用户存入特定的准备金时，他会收到相应数量的aTokens，这些token映射了所存入的流动性，并积累了所存入的基础资产的利息。代币是在存款时铸造的，它们的价值会增加，直到它们在赎回或清算时被烧毁。每当用户打开借贷头寸时，用作抵押品的代币被锁定，无法转让。

- One of the advanced features implemented in the LendingPool contract is the tokenization of the lending position. When a user deposits in a specific reserve, he receives a corresponding amount of aTokens, tokens that map the liquidity deposited and accrue the interests of the deposited underlying assets. Atokens are minted upon deposit, their value increases until they are burned on redeem or liquidated. Whenever a user opens a borrow position, the tokens used as collateral are locked and cannot be transferred.

- 详解

- 首先，用户在 Aave 存入资金时，协议会铸造与标的资产 1:1 数量的 aTokens 代币，该代币符合 ERC20 标准，可以转移或进行交易。另外，存款利息的发放体现在 aToken 的余额上，即用户的 aToken 余额会随着时间的推移而增长

- 其次，用户存入资产进行抵押后，即可在协议借出一定比例的资产，一般为超额抵押借贷；在借款时，用户可以选择固定利率或浮动利率两种模式。另外，根据不同代币的风险情况，每个代币的最大可借出资产价值（LTV）都不一样。如图 ，DAI 的 LTV 为 75%，即抵押 1 个 DAI 可借出对应 0.75 个 DAI 价值的资产

- 最后，用户在协议上进行偿还借出资产，并需要支付利息，利息由每个资产的利用率及市场的供需情况决定。若抵押资产的价格下跌，导致抵押品价值与借出资产价值的比例低于清算阈值时，用户将面临清算；清算过程依赖于预言机的喂价，Aave 协议使用的是 Chainlink。当用户完成偿还操作后，即可取回抵押资产，同时协议销毁对应的 aTokens

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 10:01:22

借贷逻辑

- deposit = 存款

- 逻辑

- 用户通过deposit函数向协议存款时，可以选择ERC20token资产或者ETH，不可以两者混用，如果是ETH的话那么reserve地址就是0xEEEE…EEEE。主要逻辑就是调用core合约的更新储备状态函数，而后mint出一笔新的atoken作为用户的资产凭证，随后通过core合约向储备地址转款。其中referralCode只在最后的emit事件时使用，用于判断用户是否会接受奖励

- 流程

- 代码

/**

* @dev deposits The underlying asset into the reserve. A corresponding amount of the overlying asset (aTokens)

* is minted.

* @param _reserve the address of the reserve

* @param _amount the amount to be deposited

* @param _referralCode integrators are assigned a referral code and can potentially receive rewards.

**/

function deposit(address _reserve, uint256 _amount, uint16 _referralCode)

external

payable

nonReentrant

onlyActiveReserve(_reserve)

onlyUnfreezedReserve(_reserve)

onlyAmountGreaterThanZero(_amount)

{

AToken aToken = AToken(core.getReserveATokenAddress(_reserve));

bool isFirstDeposit = aToken.balanceOf(msg.sender) == 0;

core.updateStateOnDeposit(_reserve, msg.sender, _amount, isFirstDeposit);

//minting AToken to user 1:1 with the specific exchange rate

aToken.mintOnDeposit(msg.sender, _amount);

//transfer to the core contract

core.transferToReserve.value(msg.value)(_reserve, msg.sender, _amount);

//solium-disable-next-line

emit Deposit(_reserve, msg.sender, _amount, _referralCode, block.timestamp);

}

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-28 10:34:13

deposit=存款

- deposit = 存款

- 逻辑

- 用户通过deposit函数向协议存款时，可以选择ERC20token资产或者ETH，不可以两者混用，如果是ETH的话那么reserve地址就是0xEEEE…EEEE。主要逻辑就是调用core合约的更新储备状态函数，而后mint出一笔新的atoken作为用户的资产凭证，随后通过core合约向储备地址转款。其中referralCode只在最后的emit事件时使用，用于判断用户是否会接受奖励

- 流程

- 代码

/**

* @dev deposits The underlying asset into the reserve. A corresponding amount of the overlying asset (aTokens)

* is minted.

* @param _reserve the address of the reserve

* @param _amount the amount to be deposited

* @param _referralCode integrators are assigned a referral code and can potentially receive rewards.

**/

function deposit(address _reserve, uint256 _amount, uint16 _referralCode)

external

payable

nonReentrant

onlyActiveReserve(_reserve)

onlyUnfreezedReserve(_reserve)

onlyAmountGreaterThanZero(_amount)

{

AToken aToken = AToken(core.getReserveATokenAddress(_reserve));

bool isFirstDeposit = aToken.balanceOf(msg.sender) == 0;

core.updateStateOnDeposit(_reserve, msg.sender, _amount, isFirstDeposit);

//minting AToken to user 1:1 with the specific exchange rate

aToken.mintOnDeposit(msg.sender, _amount);

//transfer to the core contract

core.transferToReserve.value(msg.value)(_reserve, msg.sender, _amount);

//solium-disable-next-line

emit Deposit(_reserve, msg.sender, _amount, _referralCode, block.timestamp);

}

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 09:45:57

borrow=借款

- borrow= 借款 = 借贷

- 说明

- 借款行为，以剩余的抵押品锁着为前提，将一定数量的标的资产转移给用户

- 流程

- 逻辑

- 对于借款的逻辑，为了缩减局部变量，使用了一个结构体来当作局部的用户全局信息。首先会检查用户借贷的目标储备是否允许借贷，确定借款利率模式以及有没有足够的储备金。随后计算当前发起借款用户的抵押资金、借贷总额、总手续费、当前LTV、清算阈值以及健康因子。当上述条件都满足后会计算当前借款的必须抵押资金，只有抵押金额大于借款额后才会调用core合约执行转账逻辑，将借出款从储备中转给用户。

- 代码

/**

* @dev data structures for local computations in the borrow() method.

*/

struct BorrowLocalVars {

uint256 principalBorrowBalance;

uint256 currentLtv;

uint256 currentLiquidationThreshold;

uint256 borrowFee;

uint256 requestedBorrowAmountETH;

uint256 amountOfCollateralNeededETH;

uint256 userCollateralBalanceETH;

uint256 userBorrowBalanceETH;

uint256 userTotalFeesETH;

uint256 borrowBalanceIncrease;

uint256 currentReserveStableRate;

uint256 availableLiquidity;

uint256 reserveDecimals;

uint256 finalUserBorrowRate;

CoreLibrary.InterestRateMode rateMode;

bool healthFactorBelowThreshold;

}

/**

* @dev Allows users to borrow a specific amount of the reserve currency, provided that the borrower

* already deposited enough collateral.

* @param _reserve the address of the reserve

* @param _amount the amount to be borrowed

* @param _interestRateMode the interest rate mode at which the user wants to borrow. Can be 0 (STABLE) or 1 (VARIABLE)

**/

function borrow(

address _reserve,

uint256 _amount,

uint256 _interestRateMode,

uint16 _referralCode

)

external

nonReentrant

onlyActiveReserve(_reserve)

onlyUnfreezedReserve(_reserve)

onlyAmountGreaterThanZero(_amount)

{

// Usage of a memory struct of vars to avoid "Stack too deep" errors due to local variables

BorrowLocalVars memory vars;

//check that the reserve is enabled for borrowing

require(core.isReserveBorrowingEnabled(_reserve), "Reserve is not enabled for borrowing");

//validate interest rate mode

require(

uint256(CoreLibrary.InterestRateMode.VARIABLE) == _interestRateMode ||

uint256(CoreLibrary.InterestRateMode.STABLE) == _interestRateMode,

"Invalid interest rate mode selected"

);

//cast the rateMode to coreLibrary.interestRateMode

vars.rateMode = CoreLibrary.InterestRateMode(_interestRateMode);

//check that the amount is available in the reserve

vars.availableLiquidity = core.getReserveAvailableLiquidity(_reserve);

require(

vars.availableLiquidity >= _amount,

"There is not enough liquidity available in the reserve"

);

(

,

vars.userCollateralBalanceETH,

vars.userBorrowBalanceETH,

vars.userTotalFeesETH,

vars.currentLtv,

vars.currentLiquidationThreshold,

,

vars.healthFactorBelowThreshold

) = dataProvider.calculateUserGlobalData(msg.sender);

require(vars.userCollateralBalanceETH > 0, "The collateral balance is 0");

require(

!vars.healthFactorBelowThreshold,

"The borrower can already be liquidated so he cannot borrow more"

);

//calculating fees

vars.borrowFee = feeProvider.calculateLoanOriginationFee(msg.sender, _amount);

require(vars.borrowFee > 0, "The amount to borrow is too small");

vars.amountOfCollateralNeededETH = dataProvider.calculateCollateralNeededInETH(

_reserve,

_amount,

vars.borrowFee,

vars.userBorrowBalanceETH,

vars.userTotalFeesETH,

vars.currentLtv

);

require(

vars.amountOfCollateralNeededETH <= vars.userCollateralBalanceETH,

"There is not enough collateral to cover a new borrow"

);

/**

* Following conditions need to be met if the user is borrowing at a stable rate:

* 1. Reserve must be enabled for stable rate borrowing

* 2. Users cannot borrow from the reserve if their collateral is (mostly) the same currency

*    they are borrowing, to prevent abuses.

* 3. Users will be able to borrow only a relatively small, configurable amount of the total

*    liquidity

**/

if (vars.rateMode == CoreLibrary.InterestRateMode.STABLE) {

//check if the borrow mode is stable and if stable rate borrowing is enabled on this reserve

require(

core.isUserAllowedToBorrowAtStable(_reserve, msg.sender, _amount),

"User cannot borrow the selected amount with a stable rate"

);

//calculate the max available loan size in stable rate mode as a percentage of the

//available liquidity

uint256 maxLoanPercent = parametersProvider.getMaxStableRateBorrowSizePercent();

uint256 maxLoanSizeStable = vars.availableLiquidity.mul(maxLoanPercent).div(100);

require(

_amount <= maxLoanSizeStable,

"User is trying to borrow too much liquidity at a stable rate"

);

}

//all conditions passed * borrow is accepted

(vars.finalUserBorrowRate, vars.borrowBalanceIncrease) = core.updateStateOnBorrow(

_reserve,

msg.sender,

_amount,

vars.borrowFee,

vars.rateMode

);

//if we reached this point, we can transfer

core.transferToUser(_reserve, msg.sender, _amount);

emit Borrow(

_reserve,

msg.sender,

_amount,

_interestRateMode,

vars.finalUserBorrowRate,

vars.borrowFee,

vars.borrowBalanceIncrease,

_referralCode,

//solium-disable-next-line

block.timestamp

);

}

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-28 10:36:35

repay=偿还

- repay = 偿还 = 偿还贷款 = 偿还借款

- 说明

- 偿还操作允许用户偿还全部或部分借款金额加上发起费用和应计利息

- 流程

- 逻辑

- 用户可以通过repay函数来偿还贷款，不过没有金额的限制，还款金额为-1时代表全部还款。

- 首先计算用户当前欠款额、利息、办理手续费等信息，而后计算出用户的所需还款具体数目（本金+利息+手续费）。如果用户的还款额度小于手续费数目，那么协议优先考虑将用户的还款转入手续费收集地址；如果用户还款的额度大于没有还清的手续费，那么一样的优先偿还手续费。剩下的金额才会转入用户借款储备地址

- 代码

/**

* @notice repays a borrow on the specific reserve, for the specified amount (or for the whole amount, if uint256(-1) is specified).

* @dev the target user is defined by _onBehalfOf. If there is no repayment on behalf of another account,

* _onBehalfOf must be equal to msg.sender.

* @param _reserve the address of the reserve on which the user borrowed

* @param _amount the amount to repay, or uint256(-1) if the user wants to repay everything

* @param _onBehalfOf the address for which msg.sender is repaying.

**/

struct RepayLocalVars {

uint256 principalBorrowBalance;

uint256 compoundedBorrowBalance;

uint256 borrowBalanceIncrease;

bool isETH;

uint256 paybackAmount;

uint256 paybackAmountMinusFees;

uint256 currentStableRate;

uint256 originationFee;

}

function repay(address _reserve, uint256 _amount, address payable _onBehalfOf)

external

payable

nonReentrant

onlyActiveReserve(_reserve)

onlyAmountGreaterThanZero(_amount)

{

// Usage of a memory struct of vars to avoid "Stack too deep" errors due to local variables

RepayLocalVars memory vars;

(

vars.principalBorrowBalance,

vars.compoundedBorrowBalance,

vars.borrowBalanceIncrease

) = core.getUserBorrowBalances(_reserve, _onBehalfOf);

vars.originationFee = core.getUserOriginationFee(_reserve, _onBehalfOf);

vars.isETH = EthAddressLib.ethAddress() == _reserve;

require(vars.compoundedBorrowBalance > 0, "The user does not have any borrow pending");

require(

_amount != UINT_MAX_VALUE || msg.sender == _onBehalfOf,

"To repay on behalf of an user an explicit amount to repay is needed."

);

//default to max amount

vars.paybackAmount = vars.compoundedBorrowBalance.add(vars.originationFee);

if (_amount != UINT_MAX_VALUE && _amount < vars.paybackAmount) {

vars.paybackAmount = _amount;

}

require(

!vars.isETH || msg.value >= vars.paybackAmount,

"Invalid msg.value sent for the repayment"

);

//if the amount is smaller than the origination fee, just transfer the amount to the fee destination address

if (vars.paybackAmount <= vars.originationFee) {

core.updateStateOnRepay(

_reserve,

_onBehalfOf,

0,

vars.paybackAmount,

vars.borrowBalanceIncrease,

false

);

core.transferToFeeCollectionAddress.value(vars.isETH ? vars.paybackAmount : 0)(

_reserve,

_onBehalfOf,

vars.paybackAmount,

addressesProvider.getTokenDistributor()

);

emit Repay(

_reserve,

_onBehalfOf,

msg.sender,

0,

vars.paybackAmount,

vars.borrowBalanceIncrease,

//solium-disable-next-line

block.timestamp

);

return;

}

vars.paybackAmountMinusFees = vars.paybackAmount.sub(vars.originationFee);

core.updateStateOnRepay(

_reserve,

_onBehalfOf,

vars.paybackAmountMinusFees,

vars.originationFee,

vars.borrowBalanceIncrease,

vars.compoundedBorrowBalance == vars.paybackAmountMinusFees

);

//if the user didn't repay the origination fee, transfer the fee to the fee collection address

if(vars.originationFee > 0) {

core.transferToFeeCollectionAddress.value(vars.isETH ? vars.originationFee : 0)(

_reserve,

msg.sender,

vars.originationFee,

addressesProvider.getTokenDistributor()

);

}

//sending the total msg.value if the transfer is ETH.

//the transferToReserve() function will take care of sending the

//excess ETH back to the caller

core.transferToReserve.value(vars.isETH ? msg.value.sub(vars.originationFee) : 0)(

_reserve,

msg.sender,

vars.paybackAmountMinusFees

);

emit Repay(

_reserve,

_onBehalfOf,

msg.sender,

vars.paybackAmountMinusFees,

vars.originationFee,

vars.borrowBalanceIncrease,

//solium-disable-next-line

block.timestamp

);

}

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-28 10:39:10

redeem=赎回

- redeem = 赎回

- 说明

- 赎回操作允许用户将一定数量的attoken交换为基础资产

- 实际金额兑换是使用attoken / 基础汇率E(i)计算的

- 流程

- 逻辑

- 用户可以通过redeemUnderlying来赎回标的资产，首先会判断储备中是否有足够的流动资金来满足用户的赎回操作，而后通过core合约的updateStateOnRedeem和transferToUser来完成更新储备信息和转款操作。

- 代码

/**

* @dev Redeems the underlying amount of assets requested by _user.

* This function is executed by the overlying aToken contract in response to a redeem action.

* @param _reserve the address of the reserve

* @param _user the address of the user performing the action

* @param _amount the underlying amount to be redeemed

**/

function redeemUnderlying(

address _reserve,

address payable _user,

uint256 _amount,

uint256 _aTokenBalanceAfterRedeem

)

external

nonReentrant

onlyOverlyingAToken(_reserve)

onlyActiveReserve(_reserve)

onlyAmountGreaterThanZero(_amount)

{

uint256 currentAvailableLiquidity = core.getReserveAvailableLiquidity(_reserve);

require(

currentAvailableLiquidity >= _amount,

"There is not enough liquidity available to redeem"

);

core.updateStateOnRedeem(_reserve, _user, _amount, _aTokenBalanceAfterRedeem == 0);

core.transferToUser(_reserve, _user, _amount);

//solium-disable-next-line

emit RedeemUnderlying(_reserve, _user, _amount, block.timestamp);

}

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-28 10:40:12

liquidation=清算

- liquidation = 清算

- 说明

- 清算通知合约允许任何外部行为者以折扣价购买部分抵押品。如果发生清算事件，最多可以清算50%的贷款，这将使健康系数恢复到1以上。

- 清算逻辑

- 清算流程图

- 逻辑

- 对于资不抵债需要清算的抵押资产，用户可以通过调用liquidationCall来进行资产清算，也就是购买清算资产，同时也会得到一些奖励。具体的逻辑是在liquidationManager中，详见liquidationManager小节

- 代码

/**

* @dev users can invoke this function to liquidate an undercollateralized position.

* @param _collateral the address of the collateral to liquidated

* @param _reserve the address of the principal reserve

* @param _user the address of the borrower

* @param _purchaseAmount the amount of principal that the liquidator wants to repay

* @param _receiveAToken true if the liquidators wants to receive the aTokens, false if

* he wants to receive the underlying asset directly

**/

function liquidationCall(

address _collateral,

address _reserve,

address _user,

uint256 _purchaseAmount,

bool _receiveAToken

) external payable nonReentrant onlyActiveReserve(_reserve) onlyActiveReserve(_collateral) {

address liquidationManager = addressesProvider.getLendingPoolLiquidationManager();

//solium-disable-next-line

(bool success, bytes memory result) = liquidationManager.delegatecall(

abi.encodeWithSignature(

"liquidationCall(address,address,address,uint256,bool)",

_collateral,

_reserve,

_user,

_purchaseAmount,

_receiveAToken

)

);

require(success, "Liquidation call failed");

(uint256 returnCode, string memory returnMessage) = abi.decode(result, (uint256, string));

if (returnCode != 0) {

//error found

revert(string(abi.encodePacked("Liquidation failed: ", returnMessage)));

}

}

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 09:38:16

健康因子Health Factor

- AAVE：健康因子=Health Factor=H(f)

- 含义：用户的资金健康程度，如果健康因子小于1，就触发清算流程

- 评价：判断用户是否面临清算的一个重要指标

- 计算公式

- 图

- 文字

- H(f )= (TotalCollateralETH ∗ L (a) (Q)) / (TotalBorrowsETH + TotalFeesETH)

- 当  H(f) < 1 ，该笔贷款被视为是抵押不足，可以被清算

- when  Hf  <  1 , a loan is considered undercollateralized and can be liquidated

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 09:49:17

Swap borrow rate mode=切换借贷利率模型

- swap = Rate swap == Swap borrow rate mode = 利率调整 = 切换借贷利率模型

- 说明

- 互换利率操作允许正在进行借款的用户在可变和稳定的借款利率之间进行互换。

- 流程

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 09:50:45

子模块

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-28 10:05:52

aToken

- aToken = Aave Token = Aave代币

- 复数：aTokens

- 是什么：AAVE计息代币

- AAVE借贷协议的协议代币，带利息的衍生代币

- 逻辑

- 概述

- 在存入时铸造，在提取时烧毁

- 代币的价值以1:1的比率与相应的存款资产挂钩

- 详解

- 当您在 Aave 协议中存款时，您会收到相应数量的 aToken，它们与基础资产 1:1 挂钩

- 当用户将资金存入协议时，他们会收到ERC -20标准协议代币（aTokens）作为交换

- 这些代币可以在任何时候交换回原始资产

- 作用

- 计息

- 此时可以加：Aave计息代币

- aTokens 直接在您的钱包中产生利息，因此您可以看到每秒余额的增长

- 您可以选择在任何以太坊地址接收此利息

- 借款时的利率转换

- 使您可以随时在稳定利率和浮动利率之间进行选择，从而始终获得最佳利率

- 例如

- 如果您最初选择的是浮动利率，但随后该利率急剧上升，则可以切换到稳定利率

- 我们还调整了利率模型，以填补浮动利率模型和稳定利率模型之间的空白，从而使新的稳定利率更具竞争力

- 更多细节

- Aave协议为流动性提供商实现了代币化策略。存款后，存款人会收到相应数量的衍生代币，称为Aave代币(简称aTokens)，它们以1:1的比例映射基础资产。每个存款人的代币余额随着时间的推移而增长，这是由于存款利息的不断增加。代币完全符合ERC20标准

- 代币本身也实现了利率重定向的概念。事实上，随着时间的推移，借款人的利率支付所累积的价值与本金价值是不同的。一旦有了atoken的余额，累积值可以重定向到任何地址，有效地分割余额和生成的利息。我们把随着时间的推移不断积累的利息流称为利息流

- 为了实现这一令牌化策略，我在aToken合约中引入了以下概念:

- User x balance index I(t)(x):是用户执行最后一个操作时的储备归一化收益I(t)(x)的值

- Principal balance B(p)：是存储在ERC20 token合约的余额映射中的余额。用户在aToken合约上执行的每个操作(存款、赎回、转移、清算、利率重定向)都会更新本金余额

- Redirection address A(r)：当用户决定将他的利息流重定向到另一个地址时，将提供一个新的重定向地址A(r)。如果不进行兴趣流重定向，则A(r) = 0

- Redirected Balance B(x)(r) ：每当用户重定向自己的利息流时，用户重定向的余额将被添加到B(r)指定地址的重定向余额B(r)中

- 定义如下

- 其中x是将利息流重定向到用户(X)的用户集合

- 每当用户x0∈X将其aToken兑换或转移给另一个没有重定向到X的用户时，重定向余额就会减少

- Current balance B(c)：是attoken合约的balanceOf()函数返回的余额

- 定义如下

- 代币化模型的局限性

- 与广泛使用的基于汇率的方法相比，所描述的代币化模型具有许多优点，但也有一些缺点，具体来说:

1. 一次转移全部余额是不可能的

2. 考虑到利率的永久累积，没有办法指定要转移的确切金额，因为即使在转账交易被确认时，利息也会继续增加。这意味着转账后的余额完全为0是不可能的，相反，执行转账的账户将留下非常小的余额(尘埃余额)。注意，本可以通过添加特定的逻辑来处理这种特殊的边缘情况来避免这种情况，但是这种情况会发生意味着在ERC20传递函数中添加非标准行为，因此我们避免了它。

3. 尽管这不是一个相关的问题，但重要的是要注意，可以通过

- 1：来完全清除剩余的余额。执行另一次转移，这很可能会转移剩余的灰尘余额，因为它太小，无法在相当短的时间内产生兴趣

- 或者2：赎回尘埃余额并转让标的资产

1. 利息流只能在有本金余额的情况下重定向

2. 这意味着只有本金余额为Bp的账户才能重定向其利息。如果用户兑换或转移所有内容，则会重置他们的利息重定向。这样做的一个副作用是，仅由重定向余额Br生成的利息不能重定向

AAVE v2

- 升级aToken

- V2的aToken有如下更新：

- 支持EIP-2612

- 在基本的aToken实现中没有利率重定向-这可能会在将来重新引入

- 从v1到v2，没有变化的定义有

- LR(asset)(t) = current Liquidity Rate

- 总体借款利率和使用率的函数

- 公式

- LI(t) = cumulated Liquidity Index

- 准备金在时间间隔∆T期间累积的利息，在发生借款、存款、偿还、赎回、交换swap、清算事件时更新

- 公式

- NI(t) = reserve Normalised Income

- 准备金累积的持续利息

- 公式

- 在V1中，每次操作后，NIt被存储为用户x索引NI(x)，对于用户x，累积的aToken余额的计算方法如下

- 在V2中，用户索引实际上作为存储变量消失，并与主体余额一起作为称为 Scaled Balance = 缩放余额 = ScB 的比率存储

- 计算用户的余额，导致每次操作的增加或减少，导致aToken的铸造或燃烧

- Deposits=存款

- 当用户在协议中存入金额m时，他的缩放余额更新如下

- Withdrawals=取款

- 当用户在协议中提取金额m时，他的缩放余额更新如下

- 在任何时间点，用户的aToken余额都可以写成

- 相关开发者文档

- aTokens | v2 | Developers (aave.com)

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 09:57:28

代币的作用

- AAVE代币持有者 管理AAVE协议 = AAVE Token Holders Govern Aave Protocol

- AAVE生态

- 概览

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 10:00:50

Governance治理

- AAVE的Governance治理

- 概述

- AAVE协议由AAVE持有者以DAO的形式进行运营以及管理，根据持有者的AAVE以及stkAAVE的余额总和的比例获得治理权重

- 持有治理Token拥有两种权利

- 提案权

- 投票权

- Token持有者可以创建提案以及对提案进行赞成或反对的投票

- 提案

- 内容

- AAVE市场风险参数的变动

- 生态系统储备基金的激励参数

- 金库资金的分配

- 资产的添加、暂停或下架

- 协议机制调整

- 类型

- 图表

- 文字

- 短执行（Short Executor）

- 短执行通常为协议参数的变更，资产列表的变更等

- 长执行（Long time lock）

- 长执行提案涉及到核心代码库的变更

- 二者之间提案所需要的时间以及票数等都不同

- 治理流程

- 图

- 文字

- 当有人想提出提案时，通常需要在社区中收集反馈来获取前期的支持，在获得社区支持后创世团队（Genesis Team）会将提案提交给创世纪治理（Genesis Governance）程序

- 创世纪治理

- 是什么：以AAVE作为唯一投票资产的治理合约

- 核心组件

- AaveProtoGovernance

- 治理的核心组件，它存储于每个提交的提案相关的状态，允许治理Token持有者投票并允许执行批准的提案。该合约将拥有执行包含 Aave 生态系统所有引导操作的提案所需的所有权

- AssetVotingWeightProvider

- 定义投票者可以对提案进行投票的权重。仅允许治理Token投票，权重为 1（1 Token = 1 票）

- 后续流程

- 当提案提交至治理合约之后，AAVE的持有者就可以对提案进行投票了，与其他协议的治理系统不同的是，AAVE允许用户使用冷钱包进行投票，用户只需要使用冷钱包签署消息并使用不同的钱包转发即可投票，这使得一些在冷钱包中持有大量AAVE的用户更加便捷参与协议的治理无需将资产取出，唯一的要求是在提案期间代表权重的AAVE需要存放在签署消息的冷钱包中

- 这种方式有个缺陷就是由于不需要锁定Token只需签署消息即可，这样就会导致用户在多个钱包中使用相同的Token进行多次投票，为了避免这种情况

- 治理程序中存在一个投票挑战程序来验证投票的真实性，验证期可在以下情况下激活：

- 达到最短投票持续时间，并且选民超过法定人数

- 尚未达到最短持续时间，但投票已超过法定人数。在这种情况下，需要手动触发挑战期。

- 在验证期间，将会对每个参与投票的地址进行质询，该挑战动作会将每个不持有投票Token的地址的投票权取消，如果提案门槛因此被超过，那么投票期将会重新开始。

- 流程图

- 评价

- 与 Maker DAO的“寡头治理”不同，AAVE的治理实现真正的 Decentralized 治理，用户不需要质押锁定AAVE也可以拥有治理权，并且AAVE的分布性使得没有一个个人或团体可以利用手中的治理权重决定任何一个提案。

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 10:05:08

Safety Module安全模块

- Safety Module

- 概述

- 保护Aave协议的主要机制是激励Aave持有者将令牌锁定到一个基于智能合约的组件中，该组件称为安全模块(SM)。在属于AAVE生态系统的流动性市场发生短缺事件时，锁定的AAVE将用作缓解工具。当出现赤字时，就会发生短缺事件。短缺事件发生的解释取决于协议治理投票，详见治理

- The primary mechanism for securing the Aave Protocol is the incentivization of AAVE holders to lock tokens into a Smart Contract-based component called the Safety Module (SM). The locked AAVE will be used as a mitigation tool in case of a Shortfall Event within the liquidity markets that belong to the Aave ecosystem. A Shortfall Event occurs when there is a deficit. The interpretation for the occurrence of a Shortfall Event is subject to the Protocol Governance vote, detailed in Governance.

- Architecture

- Safety Module In Detail

- Shortfall Events

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 10:01:05

Flash Loan闪电贷

- Flash Loan= Flash贷款=闪贷=闪电贷=闪电贷款

- 所属领域：AAVE借贷协议中的一种贷款方式

- 是什么：无需任何资金抵押就可以借款

- 无需任何抵押品也可以进行贷款且可以保障资金一定会返还

- 闪电贷款将允许用户在单笔交易中从储备中借款，只要用户返还更多的流动性。

- 原理

- 通过在一个区块内完成包含借款以及还款的操作的一个事务来实现无抵押贷款，由于区块链的特性，一个区块只有被打包出块的时候才会成为一个已经发生的“事实”，用户使用闪电贷时需要在一个区块内完成一个包含借款——交易操作——还款的操作才算一个成功的事务

- 任何一环如果操作失败了都无法完成

- 比如当用户使用闪电贷借出了一笔资金后并未作出还款的操作，那么这笔资金就会自动回滚到原来的地方，就像一切都没有发生过，因为这笔操作在一个区块中属于一个失败的事务无法变成一个“事实”

- 评价

- DeFi行业的首个无担保贷款解决方案

- Aave最突出的产品之一

- 特点

- 使用时间短 == 门槛高 ~= 多数是用代码实现

- 闪贷必须在相同的金融操作中偿还，这意味着它们只发行几分钟甚至几秒钟

- 但由于闪电贷需要在一个区块内完成所有操作，人工操作是无法实现闪电贷的，需要依靠代码来完成闪电贷的操作，使用门槛相对较高

- 只需要支付一次GAS费以及闪电贷协议费的成本

- 如果有好的套利机会闪电贷可以获得的利润是没有上限的

- 作用=用途

- （主要用于）套利

- 抵押品闪兑

- 偿还欠款

- 以避免清算罚款

- ~= 债务交换

- 举例

- DeFi Saver 可让您在一个地方管理所有 DeFi 活动。它还可以让您设置一个自动自我清算程序，用闪贷来偿还债务，释放抵押品并出售部分抵押品来偿还 Aave 协议，从而避免清算处罚

- 架构

- 逻辑图

- 流程

- 说明

- 闪贷暂时将资金转移到一个遵循IFlashLoanEnabledContract.sol接口的智能合约中。合同的地址是动作的参数。资金转移之后，在外部合约上执行executeOperation()方法。合同可以用借来的资金做任何需要做的事情。方法executeOperation()完成后，将执行检查以验证资金加上费用已经返回到LendingPool合同。然后将费用累加到储备中，并存入状态储备被更新。如果归还给准备金的资金少于所借的资金，这笔交易就被取消恢复

- 图

Flash Loan V2

- AAVE借贷协议：V2

- 闪电贷V1 = Flash Loan V1

- 流程图

- 检查资金是否已转移的步骤如下

- 在将资金转移到执行者U之前，协议对闪贷资产的余额进行快照

- 在闪电贷款结束时，检查强制执行合同余额包括闪电借款金额加上闪电贷款溢价。如果金额不正确，交易将被撤销。

- 这限制了Flash Loans在Aave中的使用，因为允许其他操作(特别是存款、还款和清算)可能会使协议暴露于重新进入的风险中。因此，这些操作通过重入保护机制进行互斥

- 闪贷是Aave V1的一项颠覆性功能，它允许创建各种工具来进行再融资、抵押品互换、套利和清算。闪贷已经成为一种强大的DeFi机制。

- 闪电贷V2=Flash Loan V2

- 概述

- 在最初的V1闪贷中，一个重要的限制是它不能在Aave中使用。Aave V2实现了一个解决方案，使Flash贷款的使用与协议的任何其他功能相结合，提供了许多新的可能性

- 押品交易

- 将风险敞口(exposure)从一个或多个抵押品更改为另一个抵押品，而无需关闭债务头寸(debt position)

- 抵押品偿还贷款

- 在协议中使用担保存款来偿还债务

- 证金交易

- 创建保证金头寸，可用于以后的交易

- 债务互换

- 将债务敞口从一种资产转换为另一种资产

- 保证金存款

- 细节

- 解释1

- V2提供了一种新颖的防止重入的保护，允许对所有的交易使用闪贷

- 具体方案：最初的实现是为特定的ETH代码路径选择的;不幸的是，ETH不支持拉支付策略(pull payment strategy.)。在这个新的版本2中，所有eth相关的代码已经被删除，导致以下变化:

1. 闪贷启动资金转移到闪贷执行人u，

2. 最后，资金从执行人那里收回，金额等于借入的资金加上费用。如果抽回资金不成功，闪贷失败;例如，当资金缺乏批准或缺乏资金来支付债务时。

- 这在技术上消除了对前后余额快照的需要，因此消除了重入检查的需要

- 此外，闪贷现在支持多种模式:闪贷调用者可以决定保持贷款开放，但要有适当的流动性来满足抵押品要求

- 解释2

- 协议内部

- 在Aave v2中，在协议本身内可以实现闪贷。事实上，它们在协议中广泛用于头寸交换和其他“交易”功能

- 批量闪贷=Batch flash loans

- 闪贷现在可以分批执行，即在同一调用中具有不同参数的多个闪贷。这将允许强大的新用例，例如通过一次闪贷交易偿还多个资产和头寸

- 闪贷模式

- 你现在可以执行一种“传统”的闪贷组合，即立即偿还，以及发生债务的闪贷(即闪贷不会立即偿还)。

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 10:35:59

稳定币GHO

- GHO

- 是什么：稳定币的一种

- AAVE新推出的稳定币

- 名称由来

- （猜测）AAVE是芬兰语的幽灵，幽灵的英文是Ghost，所以取前3个字母：GHO

- GHO的一些机制

- GHO将是Decentralized

- GHO由持续提供收益的资产进行超额抵押生成

- GHO由AAVE协议多种类型的抵押品提供支持

- GHO由AAVE社区治理

- 安全模块参与者（stkAAVE持有者）可以以折扣价格铸造GHO

- GHO引入了“促进者”（facilitator）的概念：可以无需信任生成或销毁GHO

- GHO引入门户（Portal）将为在多链世界中扩展GHO提供理想的路径

- 架构图

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 10:37:22

Credit Delegation信用委托

- Credit Delegation=信用委托=信贷委托

- 概述

- 用户可以将它在AAVE中deposit得到的信用额度转移给其他账户，而其他账户可以拿着得到的信用额度来进行贷款等

- 信用委托是一项简单的交易，Aave协议的储户将信用额度委托给他们信任的人

- 流程和逻辑

- 详解

- 在债务标记化之上，V2支持信用委托:borrow()函数支持不同地址的信用额度，而不需要抵押品，只要调用者地址被授予许可。

- 此功能是通过每个债务令牌上的approveDelegation()函数实现的。用户将能够为特定的债务模式(稳定或可变)制定他们的津贴。borrow()函数有一个onBehalfOf参数，供调用者指定用于提取贷款的地址。

- 权衡trade-off

- 信贷授权的实施需要作出一些权衡:

- 一个代理人可以将信用委托给多个实体，但一个代理人一次只能从一个代理人处提取信用。一个人不能在一次借款中把代理人的债务加起来()

- 受托人可以同时向实体委托稳定和可变信贷，但受托人不能从单一借款中提取可变和稳定信贷()

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 10:49:31

Debt Tokenization=债务代币化

- 债务代币化=Debt Tokenization

- 借款人的债务现在由代币表示，而不是内部审计，使得

- 关于协议的借用方面的代码简化

- 一些计算现在隐含在债务代币的铸造/燃烧逻辑中

- 同时借款可变和多个稳定利率

- 在V1中，借款人的贷款要么是可变的，要么是稳定的，之前的贷款会自动切换到最新的贷款利率。在V2中，用户可以同时持有多种贷款，包括可变利率和多个稳定利率头寸。多个稳定利率头寸是通过所持稳定利率贷款利率的加权平均来处理的。

- 本地信用委托

- 通过委托的概念，用户可以通过打开信用额度委托到其他地址。可以在上面开发一些有趣的工具

- 例如

- 从冷钱包中借款

- 用户可以将抵押品存放在冷钱包中，只需将其信用委托给热钱包进行借款。整个头寸可以从热钱包管理，有借款、还款和增加更多的抵押品;而资金则被放在一个安全的冷钱包里。

- 信委托安排

- 用户只要获得提供担保的其他用户的委托，就可以获得担保不足的贷款

- 自动挖矿收入

- 信贷授权使构建工具成为可能，以便在多个协议上自动打开挖矿信贷额度

- 细节实现

- 债务代币的总供应量(包括每秒累积的债务)定义如下:

- 某项资产在时刻t的总负债定义为

- 该定义取代了V1白皮书第1.2节中描述的V1的稳定或可变借款总额

- Variable Debt=可变利率债务

- 在V2中，债务代币遵循与V1中的代币相同的不断增长的逻辑。可变债务代币遵循缩放平衡方法。引入了归一化可变累计债务的概念

- ScVB(t)(x)为用户x在时刻t的缩放余额，m为交易金额，VN(t)为归一化可变债务

- Borrows借款

- 当用户x从协议中借入金额m时，缩放后的余额更新

- Repays偿还/Liquidations清算

- 当用户x偿还或清算金额m时，缩放余额更新

- 在任意时间点，用户的总可变债务余额可以写成

- 这个可变债务代币余额取代了V1白皮书第1.2节中描述的V1的用户可变借款余额

- 相关开发者文档

- Debt Tokens | v2 | Developers (aave.com)

- Stable Debt=稳定利率债务

- 对于稳定利率债务，V1定义如下

- SR (asset )(t ) =

- = overall stable rate=总体稳定利率

- 当一个稳定的借款金额SBnew按利率发行SR(t)

- 当用户x，以稳定利率SRi(x)，以金额SBi(x)，偿还稳定借款i时

- SRt存储在每个特定货币的稳定利率代币中。用户x的稳定债务代币SD(x)余额定义如下

- 在V1中，用户x的稳定利率SR(x)总是等于上次贷款的稳定利率，以前的贷款在新贷款上进行再平衡。从V2开始，每i笔稳定贷款的资产准备金计算稳定利率SR(x):

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 10:56:57

利率模型

- AAVE 借贷利率相关 == 利率模型

- 是什么：借贷协议中可用的流动性、借款需求和借款/供应利率之间的关系

- 这三个参数在功能上是相互关联的

- 增加借贷需求 -》

- 存款人收入增加

- 吸引更多存款

- 补偿存款人暂时缺乏流动性

- 同时可用的流动性减少

- 甚至可能达到用户提款延迟的程度

- 概述

- AAVE利率模型根据市场需求进行变化

- AAVE的利率模型可以使得AAVE的存款以及借贷利息随着市场供需关系而变化，当借贷的人越来越多的时候，存款利率以及贷款利息就会上升来鼓励人们存款以及降低借贷，当借贷的人越来越少的时候，存款利息和贷款利息就会下降来鼓励人们借贷

- 决定这些变化的最关键的一个指标就是资金利用率U = 资产流动性Pool中有多少资金被借出去了

- 当越来越多的人借钱导致资金利用率到达一个临界点时，资产的借贷利息以及存款利率就会开始指数型上升，高额的利润以及昂贵的利息就会吸引更多人存款以及还款，这样的机制很好的避免了出现流动性问题而导致存款人取不出资产的情况

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 10:57:43

可变利率vs稳定利率

- AAVE借贷协议中的借贷利率

- 用户借贷时可选择的利率模式：可变利率 vs 稳定利率

- 公式

- 利率对比图

- 评价

- 可变利率：适合短期借贷

- 固定利率：适合长期借贷以及喜欢预测的用户

- 可变利率

- 可变借贷利率模型

- 稳定利率 vs 可变利率 模型

- 新模型

- 模型图

- 解释1

- 三个显着差异：

- 现在的最佳点是高达 90% 的使用率：虽然这减少了系统中的可用流动性，但它将资本配置提高了 10%，这进一步增加了存款人的 APY，同时提供更具竞争力的借款利率。鉴于目前流动性最强的稳定币储备（USDT、USDC、DAI）的规模，它仍将保证 300-400K 美元的稳定币可供提款。

- 最佳点的可变借款年利率现在为 8%，而不是我们之前的 6%。这使我们能够将相同的年利率保持在 80%，同时更平滑地过渡到 90%。

- 稳定的借贷利率曲线大幅收紧，90%使用率的稳定利率仅为9.9%（而8%的浮动利率），而在80%使用率之前为13.9%。

- 解释2

- 当资金利用率U小于最佳资金利用率Uoptimal的时候，利率的变化使用的是Rslope1斜率，但当资金利用率U大于最佳资金利用率Uoptimal时，就会额外引入Rslope2斜率，这个Rslope2斜率通常会十分高使得利率会指数性增长

- 但固定利率并不是一直保持固定的，在官方最新更新的利率模型中，DAI采用的利率策略是达到90%资金利用率时利率会指数型增长，在DAI的资金使用率达到95%之前，固定利率不会被重置，但如果资金使用率超过了95%固定利率就会被重置来解决流动性短缺问题

- 旧模型

- 模型图

- 解释1

- 稳定利率模型与浮动利率模型相比如何？

- 如您所见，当前配置对于稳定速率非常保守。它始终高于可变利率，以至于在资本使用率的 80% 下，稳定利率高出 2 倍以上（6% 可变利率对 13.9% 稳定利率）。为什么？原因是稳定利率可以被认为是一种新的金融工具，因此我们非常保守地开始使用它，有两个非常重要的原因：

- 我们需要收集数据并评估用户如何使用该协议以及他们的需求是什么

- 我们希望协议中的流动性增长到稳定利率在财务上更方便的程度：可用的流动性越多，稳定利率就越有效

- 这种保守的做法反映在稳定利率与浮动利率的未偿贷款之间的比率上，其中浮动利率贷款占总额的98%。有趣的是，2%的用户选择了稳定的费率，即使一开始的费率非常高，这意味着他们仍然更喜欢可预测性，即使付出了更多的代价。

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 11:01:20

稳定利率

- AAVE的：稳定利率=Stable Rate ~= Stable Rate Model = Stable Rate Theory = 稳定利率模型 = 稳定利率理论

- 背景

- 接下来解释了如何将稳定率应用于系统以及其局限性。

- 在池上实现固定费率模型是复杂的。事实上，固定利率很难用算法来处理，因为借款成本会随着市场状况和可用流动性的变化而变化。因此，可能会出现这样的情况(突然的市场变化，银行挤兑……)，在这种情况下，处理稳定利率的借款头寸需要使用基于时间或经济约束的特定启发式方法。

- 处理固定利率的两种可能方法

- 施加时间限制

- 在时间有限的情况下，固定利率可能会非常有效。如果贷款有一个稳定的期限，它应该在极端的市场条件下生存，因为借款人必须在贷款期限结束时偿还。不幸的是，有时间限制的固定利率贷款不适合我们的开放式贷款的特定用例。这需要一定程度的用户体验摩擦，用户需要创建和处理具有不同时间限制的多个贷款。

- 施加利率限制

- 贷款开始时计算的利率可能会受到市场情况的影响，使其无法保持固定。如果汇率偏离市场太大，可以重新调整。这将不是一个纯粹的固定利率，开放定期贷款-因为利率可能在贷款期间变化-但用户将在特定时间段内体验实际的固定利率，或者当有足够的流动性可用时。这个特定的实现被选择以稳定速率的名称集成到Aave的协议中

- 相关

- Lending Rate Oracle=借贷利率预言机

- 架构图

- 解释

- 集成到协议协议中的第一个组件是贷款利率预言机Oracle，它将为合同提供其他集中式和分散式贷款平台提供的实际市场利率信息

- 稳定利率头寸的限制

- 为了避免对稳定利率贷款的滥用，对稳定利率借款模型施加了以下限制

- 1：用户不能存入比他们想借的流动性更多的抵押品。如。一个用户存了1000万DAI做抵押，想借100万DAI。

- 这是为了防止以下攻击向量:

- Given: B(s) = 18% APR, M(r) = 9% APR, R(l) = 12% APR

- 用户可能会试图通过存入大量流动性来人为地降低Bs对Mr的价值，从而导致Bs下降，然后以较低的利率从相同的流动性中借款，提取先前存入的流动性，从而导致Bs和流动性利率Rl再次上升;最后将借入的金额存入银行，以赚取先前借入资金的利息。尽管这种攻击仍然可以使用多个账户进行，但这种特殊的限制使攻击变得更加复杂，因为它需要更多的钱(和不同的抵押品货币)。这与下一阶段的利率再平衡结合起来效果很好。

- 2：借款人在当前的借款利率下，最多只能借到可用流动性的1%。因此，对于每一个特定的B(s)值，单个借款人只能获得高达Tr的流动性。这是为了避免某一特定借款人以过于竞争性的利率借入过多的可用流动性

- Rebalancing再平衡 = 稳定利率再平衡

- 稳定利率模型的最后一个、或许也是最重要的约束是利率再平衡。这是为了应对市场条件的变化或池内资金成本的增加。

- 稳定的利率再平衡将在两种具体情况下发生

- Rebalancing up

- 当用户可以通过借贷赚取利息时，用户x的稳定利率被重新平衡为最近的Bs值

- B(x)(s) < Rl with B(x)(s) the stable borrow rate of user x

- Rebalancing down

- 用户x的稳定比率被重新平衡为最近的Bs值，如果:

- B(x)(s) > Bs(1 + ∆B(s))

- ∆Bs是由治理建立的利率增量，它定义了Bs以上重新平衡利率的窗口。如果用户支付的利息超出了这个范围，利率就会被平衡下来

- 再平衡过程

- 说明

- LendingPool合约公开了一个函数

- rebalanceStableBorrowRate(address reserve, address user)

- 它允许重新平衡特定用户的稳定利率。任何人都可以调用这个函数:但是，调用者没有任何直接的动机来重新平衡特定用户的比率。出于这个原因，Aave将提供一个代理，定期监控所有稳定的利率头寸，并重新平衡那些被认为是必要的。再平衡策略将由代理在链下决定，这意味着满足再平衡条件的用户可能不会立即被重新平衡。由于这些条件取决于可用的流动性和市场状态，因此可能存在一些不需要立即重新平衡的临时情况。

- 这不会给协议增加任何中心化的元素。即使代理停止工作，任何人都可以调用LendingPool合约的rebalance函数。尽管这样做没有任何直接的动机(“我为什么要这么做?”)，但对生态系统来说有一个间接的动机。事实上，即使中介机构停止存在，存款人可能仍希望触发最低借款利率头寸的再平衡，以提高流动性率和/或迫使借款人平仓，从而增加可用的流动性。相反，在规模缩减的情况下，借款人有一个直接的动机来重新平衡他们的头寸，以降低利率。

- 下面的流程图解释了函数rebalanceStableBorrowRate()的操作顺序。在再平衡发生之前累积的复合余额不受再平衡的影响

- 流程图

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 11:03:17

各种参数

此处整理，借贷协议AAVE的借贷利率相关参数：

AAVE中的LTV

- AAVE中的LTV=Loan-To-Value=贷款价值

- ~= Collateral Factor=抵押率

- 详见：

- 抵押率 · DeFi借贷协议 (crifan.org)

- 举例

- 存入100块，能贷出多少钱

- 举例：存入100，能贷出75，就是：LTV=75%

- 借贷池参数

- 举例

Rv0=基础可变借贷利率

- R(v0) = Base Variable Borrow Rate = 基础可变借贷利率

- 常数为Bt = 0。以射线表示

- Constant for B(t)=0. Expressed in ray

- 相关代码

- baseVariableBorrowRate

Rv=可变借贷利率

- R(v) = Variable Borrow Rate =可变借贷利率

- 公式

- 此利率模型可校正主要利率:

- 当 U = 0： R(v) = R(v0)

- 当U = Uoptimal：R(v) = R(v0) + Rslope1

- 高于 Uoptimal：考虑到资金成本，利率急剧上升

Rs=稳定借贷利率

- R(s =) Stable Borrow Rate = Current Stable Borrow Rate = 稳定借贷利率

- 计算公式

- 说明

- M(r)：平均市场贷款利率

- the average market lending rate

- R(slope1)：在非最优条件下的利率，斜率随着U的增加而增加

- the interest rate slope below Uoptimal, increases the rate as U increases.

- R(slope2) ：超出非最优的利率，斜率随着U与非最优之差的增大而增大

- the interest rate slope beyond Uoptimal, increases as the difference between U and Uoptimal increases.

- U：是利用率

- is the utilization rate.

- 注意

- Rs不会影响现有的稳定利率头寸-这只适用于新开的头寸

- R(s) does NOT impact existing stable rates positions – this is applied only to new opened positions.

- 以射线表示

- Expressed in ray

Rslope1=斜率1

- R(slope1) = Interest Rate slope below U(optimal)

- 常数，当U <Uoptimal 时，表示利率与利用率的比例。以射线表示

- Constant representing the scaling of the interest rate versus the utilization, when U < U(optimal). Expressed in ray

Rslope2=斜率2

- R(slope2) = Interest Rate slope above U(optimal)

- 常数表示利率与利用率的比例，当U≥ U(optimal)。以射线表示

- Constant representing the scaling of the interest rate versus the utilization, when U ≥ U(optimal). Expressed in ray

Ro=总体借贷利率

- R(o) = Overall borrow rate=总体借贷利率

- 公式

- 说明

- 准备金的总借款率，以总可变借款Bv与总稳定借款b的加权平均值计算

- Overall borrow rate of the reserve, calculated as the weighted average between the total variable borrows Bv and the total stable borrows Bs

Mr=平均市场借贷利率

- Mr=平均市场借贷利率=average Market lending rate

- 公式

- 参数说明

- i：平台个数

- M(r：)平均市场借贷利率

- P(r)(i)：借贷利率=贷款利率

- P(i)(v)：借贷量

- 含义解释

- 基本稳定借款利率，以射线表示

- 市场价格将每日更新，最初由Aave

Rsa=平均稳定借贷利率

- Rsa = Average Stable rate borrow rate=平均稳定借贷利率

- 公式

- 说明

- 详见函数

- decreaseTotalBorrowsStableAndUpdateAverageRate()

- increaseTotalBorrowsStableAndUpdateAverageRate()

- 以射线表示

- Expressed in ray

Rl=当前流动性比例

- R(l)=current Liquidity rate=当前流动性比例

- 公式

- 说明

- 总借款利率R(O)与利用率U的函数

- Function of the overall borrow rate RO and the utilization rate U

Bx=PB=用户本金借款余额

- User Principal borrow Balance=用户本金借款余额

- 旧=AAVE V1

- 变量：B(x)

- 说明

- 当用户打开借贷头寸时存储的余额。在多次借款的情况下，复利每次累积，它成为新的本金借款余额

- Balance stored when a user opens a borrow position. In case of multiple borrows, the compounded interest is cumulated each time and it becomes the new principal borrow balance

- 新=AAVE V2

- 变量：PB(x)

- 说明

- 当用户打开借贷头寸时存储的余额。在多次借款的情况下，复利每次累积，它成为新的本金借款余额。

Bvcx=VI=用户累计浮动借款指数

- B(t)(vcx)=user Cumulated Variable borrow indeX=用户累计可变利率借款指数 = 用户借款累积指数=用户累计浮动借款指数

- 旧=AAVE V1

- 公式

- 说明

- 特定用户的变量借款指数，在用户打开（新增？）变量借款头寸时存储

- Variable borrow index of the specific user, stored when a user opens a variable borrow position

- 新=AAVE V2

- 公式

- 说明

- 特定用户的可变借款指数，在用户新开可变借款头寸时存储

Bvc=VIt=累计可变利率借款指数

- B(t)(vc)=Cumulated Variable Borrow index=累计可变利率借款指数 = 借款累积指数=累计浮动借款指数

- 旧=AAVE V1

- 公式

- 说明

- 由变量借款Bv按利率Rv累积的利息，在借款、存款、偿还、赎回、切换利率、清算事件发生时更新

- 新=AAVE V2

- 含义

- 从池子首次发生用户操作时，累计到现在，每单位借款债务，共变成多少债务

- 变量借款VB在一段时间∆T内以可变利率V R累计的利息

- 公式

- 说明

- 在发生借款、存款、偿还、赎回、掉期、清算事件时更新

- 这里使用复利公式计算利息，每次存钱、取钱、借钱、赎回、清算操作等动作

- 因为在链上计算成本高，AAVE使用了泰勒展开式模拟这个公式，为了避免昂贵的求幂，使用二项式近似进行计算。

- 参考链接

- https://github.com/aave/protocol-v2/blob/ce53c4a8c8620125063168620eba0a8a92854eb8/contracts/protocol/libraries/math/MathUtils.sol#L45

- 不举例子了

- 任务每次计算复利的时候，VIt都会大一点点，跟流动性累计指数相似。

- 注意这里的复利周期是每秒计算的

- 代码

- CoreLibrary

- 储备和用户数据的数据结构

struct UserReserveData {

//principal amount borrowed by the user.

uint256 principalBorrowBalance;

//cumulated variable borrow index for the user. Expressed in ray

uint256 lastVariableBorrowCumulativeIndex;

//origination fee cumulated by the user

uint256 originationFee;

// stable borrow rate at which the user has borrowed. Expressed in ray

uint256 stableBorrowRate;

uint40 lastUpdateTimestamp;

//defines if a specific deposit should or not be used as a collateral in borrows

bool useAsCollateral;

}

struct ReserveData {

/**

* @dev refer to the whitepaper, section 1.1 basic concepts for a formal description of these properties.

**/

//the liquidity index. Expressed in ray

uint256 lastLiquidityCumulativeIndex;

//the current supply rate. Expressed in ray

uint256 currentLiquidityRate;

//the total borrows of the reserve at a stable rate. Expressed in the currency decimals

uint256 totalBorrowsStable;

//the total borrows of the reserve at a variable rate. Expressed in the currency decimals

uint256 totalBorrowsVariable;

//the current variable borrow rate. Expressed in ray

uint256 currentVariableBorrowRate;

//the current stable borrow rate. Expressed in ray

uint256 currentStableBorrowRate;

//the current average stable borrow rate (weighted average of all the different stable rate loans). Expressed in ray

uint256 currentAverageStableBorrowRate;

//variable borrow index. Expressed in ray

uint256 lastVariableBorrowCumulativeIndex;

//the ltv of the reserve. Expressed in percentage (0-100)

uint256 baseLTVasCollateral;

//the liquidation threshold of the reserve. Expressed in percentage (0-100)

uint256 liquidationThreshold;

//the liquidation bonus of the reserve. Expressed in percentage

uint256 liquidationBonus;

//the decimals of the reserve asset

uint256 decimals;

/**

* @dev address of the aToken representing the asset

**/

address aTokenAddress;

/**

* @dev address of the interest rate strategy contract

**/

address interestRateStrategyAddress;

uint40 lastUpdateTimestamp;

// borrowingEnabled = true means users can borrow from this reserve

bool borrowingEnabled;

// usageAsCollateralEnabled = true means users can use this reserve as collateral

bool usageAsCollateralEnabled;

// isStableBorrowRateEnabled = true means users can borrow at a stable rate

bool isStableBorrowRateEnabled;

// isActive = true means the reserve has been activated and properly configured

bool isActive;

// isFreezed = true means the reserve only allows repays and redeems, but not deposits, new borrowings or rate swap

bool isFreezed;

}

- 更新

- 与v1版本不同的是，在更新储备状态时会将一部分产生的利息收入存入金库（treasury）中，具体的比例由储备的reserveFactor（configuration字段的一个值）来确定

/**

* @dev Updates the liquidity cumulative index and the variable borrow index.

* @param reserve the reserve object

**/

function updateState(DataTypes.ReserveData storage reserve) internal {

uint256 scaledVariableDebt =

IVariableDebtToken(reserve.variableDebtTokenAddress).scaledTotalSupply();

uint256 previousVariableBorrowIndex = reserve.variableBorrowIndex;

uint256 previousLiquidityIndex = reserve.liquidityIndex;

uint40 lastUpdatedTimestamp = reserve.lastUpdateTimestamp;

(uint256 newLiquidityIndex, uint256 newVariableBorrowIndex) =

_updateIndexes(

reserve,

scaledVariableDebt,

previousLiquidityIndex,

previousVariableBorrowIndex,

lastUpdatedTimestamp

);

_mintToTreasury(

reserve,

scaledVariableDebt,

previousVariableBorrowIndex,

newLiquidityIndex,

newVariableBorrowIndex,

lastUpdatedTimestamp

);

}

Bxc=用户复利借款余额

- B(x)(c)=user Compounded borrow Balance=用户复利借款余额

- 旧=AAVE V1

- 公式

- 说明

- 本金Bx加上累计利息

- Principal Bx plus the cumulated interests

- 新=AAVE V2

- 代码

struct RepayLocalVars {

uint256 principalBorrowBalance;

uint256 compoundedBorrowBalance;

uint256 borrowBalanceIncrease;

bool isETH;

uint256 paybackAmount;

uint256 paybackAmountMinusFees;

uint256 currentStableRate;

uint256 originationFee;

}

function repay(address _reserve, uint256 _amount, address payable _onBehalfOf)

external

payable

nonReentrant

onlyActiveReserve(_reserve)

onlyAmountGreaterThanZero(_amount)

{

// Usage of a memory struct of vars to avoid "Stack too deep" errors due to local variables

RepayLocalVars memory vars;

(

vars.principalBorrowBalance,

vars.compoundedBorrowBalance,

vars.borrowBalanceIncrease

) = core.getUserBorrowBalances(_reserve, _onBehalfOf);

...

Dassett=债务总额

- D(asset)(t = )Total Debt=债务总额

- 公式

- 说明

- 借入的流动资金总额

- Total amount of liquidity borrowed

VDassett=可变债务代币总额

- VD(asset)(t = )Total Variable Debt Tokens=可变债务代币总额

- 说明

- 以债务代币表示的可变利率借入的流动性总额

- Total amount of liquidity borrowed at a variable rate represented in debt tokens

SDassett=稳定债务代币总额

- SD(asset)(t = )Total Stable Debt Token=稳定债务代币总额

- 说明

- 以债务代币表示的稳定利率借入的流动性总额

- Total amount of liquidity borrowed at a stable rate represented in debt tokens

Lassett=资产的总流动性

- L(asset)(t = )Total Liquidity of an asset=资产的总流动性

- 说明

- 资产准备金中可用的流动资金总额。该值的小数取决于货币的小数

- Total amount of liquidity available in the assets reserve. The decimals of this value depend on the decimals of the currency

Ci=LIt=流动性累计指数

- C(t)(i)=Cumulated liquidity Index=流动性累计指数

- 旧=AAVE v1

- 公式

- 说明

- 准备金在时间间隔∆T期间累积的利息，在发生借款、存款、偿还、赎回、掉期、清算事件时更新。

- Interest cumulated by the reserve during the time interval ∆T , updated whenever a borrow, deposit, repay, redeem, swap, liquidation event occurs

- 新=AAVE v2

- 公式

- 说明

- 从池子首次发生用户操作时，累计到现在，每单位存款本金，变成多少本金（含利息收入）

- 存储

struct ReserveData {

//the liquidity index. Expressed in ray

uint128 liquidityIndex;

}

- 更新

function _updateIndexes(

DataTypes.ReserveData storage reserve,

uint256 scaledVariableDebt,

uint256 liquidityIndex,

uint256 variableBorrowIndex,

uint40 timestamp

) internal returns (uint256, uint256) {

uint256 currentLiquidityRate = reserve.currentLiquidityRate;

uint256 newLiquidityIndex = liquidityIndex;

//only cumulating if there is any income being produced

if (currentLiquidityRate > 0) {

uint256 cumulatedLiquidityInterest =

MathUtils.calculateLinearInterest(currentLiquidityRate, timestamp);

newLiquidityIndex = cumulatedLiquidityInterest.rayMul(liquidityIndex);

require(newLiquidityIndex <= type(uint128).max, Errors.RL_LIQUIDITY_INDEX_OVERFLOW);

reserve.liquidityIndex = uint128(newLiquidityIndex);

}

reserve.lastUpdateTimestamp = uint40(block.timestamp);

}

}

Itn=NIt=归一化收入

- I(t)(n)=reserve Normalized Income=归一化收入

- 含义：每单位存款本金，未来将变成多少本金（含利息收入）

- 旧=AAVE V1

- 公式

- 说明

- 准备金累积的持续利息

- Ongoing interest cumulated by the reserve

- 新=AAVE V2

- 公式

- 代码

- getNormalizedIncome

/**

* @dev Returns the ongoing normalized income for the reserve

* A value of 1e27 means there is no income. As time passes, the income is accrued

* A value of 2*1e27 means for each unit of asset one unit of income has been accrued

* @param reserve The reserve object

* @return the normalized income. expressed in ray

**/

function getNormalizedIncome(DataTypes.ReserveData storage reserve)

internal

view

returns (uint256)

{

uint40 timestamp = reserve.lastUpdateTimestamp;

//solium-disable-next-line

if (timestamp == uint40(block.timestamp)) {

//if the index was updated in the same block, no need to perform any calculation

return reserve.liquidityIndex;

}

uint256 cumulated =

MathUtils.calculateLinearInterest(reserve.currentLiquidityRate, timestamp).rayMul(

reserve.liquidityIndex

);

return cumulated;

}

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 10:11:17

版本

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-28 10:05:52

AAVE v1

- AAVE借贷协议 v1

- Aave Protocol=AAVE协议 基本逻辑

- 之前是：ETHLend

- P2P点对点的去中心化的借贷策略

- 直接在lenders和borrowers直接撮合贷款

- 现在是：基于资金池的策略

- 同一个资金池

- lenders=放款人：存入加密货币=提供流动性，进入资金池

- Borrowers=借款人：从资金池中借款

- 但先要提供抵押物 = 存入加密货币

- 注意

- 和传统的P2P借贷不同，无需每个放款人和借款人的信息完全单独匹配

- 主要依赖于资金池

- 架构图

- V3

- 包含内容

- Borrowers=借款人=借方

- Depositors=存款人=贷方

- Price Oracle=价格预言机

- Collateral Liquidators=抵押品清算人

- Integrated Applications=集成的应用

- 借贷

- 借贷流程图

- borrow position

- 资金池=Pool = Reserve=保留资金？

- 每个资金池有自己的

- 清算阈值

- 借款的利率有2种

- stable rate=稳定利率

- variable rate=可变利率

- 主要智能合约

- LendingPool

- 核心流程

- LendingPoolCore

- 持有所有储备金和所有存款资产的状态

- holds the state of every reserve and all the assets deposited

- 处理基本逻辑(指数的累积，利率的计算…)

- handles the basic logic (cumulation of the indexes, calculation of the interest rates...)

- LendingPoolDataProvider

- 功能

- 在比LendingPoolCore更高的抽象层上执行计算，并为LendingPool提供数据

- performs calculations on a higher layer of abstraction than the LendingPoolCore and provides data for the LendingPool

- 包括

- 计算用户余额(借款余额、抵押品余额、流动性余额)的ETH等价物，以评估允许用户借多少钱和健康因素

- Calculates the ETH equivalent a user’s balances (Borrow Balance, Collateral Balance, Liquidity Balance) to assess how much a user is allowed to borrow and the health factor

- 聚合来自LendingPoolCore的数据，为LendingPool提供高级信息

- Aggregates data from the LendingPoolCore to provide high level information to the LendingPool

- 平均贷款价值比和平均清算比率的计算

- Calculate of the Average Loan to Value and Average Liquidation Ratio

- LendingPoolConfigurator

- 解释

- 提供LendingPool和LendingPoolCore的主要配置功能

- provides main configuration functions for LendingPool and LendingPoolCore

- LendingPoolConfigurator合约将被集成到Aave协议治理中

- The LendingPoolConfigurator contract will be integrated in Aave Protocol governance

- 包括

- 储备的初始化 Reserve initialization

- 储备配置 Reserve configuration

- 启用/禁用储备金借款 Enable/disable borrowing on a reserve

- 启用/禁用特定准备金作为抵押品的使用 Enable/disable the usage of a specific reserve as collateral

- InterestRateStrategy

- interstratestrategy合约保存更新特定准备金利率所需的信息并实现了利率的更新。每个储备都有一个特定的interstrategy契约。

- 具体来说，在基本策略契约DefaultReserveInterestRateStrategy中定义了以下内容:

- 基本可变借款利率Rv0

- Base variable borrow rate Rv0

- 利率斜率低于最佳利用率Rslope1

- Interest rate slope below optimal utilisation Rslope1

- 超出最佳利用的利率斜率Rslope2

- Interest rate slope beyond optimal utilisation Rslope2

- Governance=治理

- 协议的权限由LEND令牌控制。最初，Aave协议将与基于DAOStack框架的去中心化链上治理，将发展成为完全自主的协议。链上意味着所有的投票都是有约束力的:投票后的操作是硬编码的，必须执行

- 要理解治理的范围，重要的是要做出区分:

- Aave Protocol=AAVE协议

- Aave协议必然会发展，并将允许创建多个隔离的贷款池流动性、参数、权限和资产类型。

- Aave Lending Pool=AAVE借贷池

- 在池工厂更新发布之前，Aave借贷池是Aave协议的第一个池，且任何人都可以创建自己的池。

- 在Aave协议中，治理将在两个级别上进行

- Protocol’s Governance=协议的治理

- 协议的治理投票由LEND对与协议参数和相关的决策进行加权智能合约的升级。它可以与MakerDAO的治理进行比较，由利益相关者投票决定协议的当前和未来参数。

- Pool’s Governance=借贷池的治理

- 在池的治理中，你的投票是根据你在池流动性中所占的份额来加权的aTokens。投票涵盖了资产池的具体参数，如用作抵押品或借款的资产。在协议的治理的框架下，每个池都有自己的治理。

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 11:21:46

AAVE v2

- AAVE 白皮书v2= WhitePaper v2

- 背景介绍

- Aave协议标志着从分散的P2P借贷策略(贷方和借款人之间的直接贷款关系，如ETHLend)到基于池的策略的转变。贷款不需要单独匹配，而是依赖于汇集的资金、借款金额及其抵押品。这使得基于池状态的特征的即时贷款成为可能

- 开发Aave V2的主要动力是改进V1中实现的次优解决方案，具体如下:

- 无法升级aToken

- Gas效率低

- 简化架构

- 有利于通过模糊测试器和正式验证工具进行自动化测试

- 代码简化

- 目前在V1中实施的一些解决方案是在以太坊网络明显不同的时候设计和开发的。DeFi的指数级增长使交易数量增加了一倍，而以太坊的Istanbul伊斯坦布尔的发布，给Gas成本增加带来了进一步的压力

- V1升级到V2 主要升级点=改进点

- 功能点=升级点 概述

- 固定利率存款

- 稳定借贷率

- 信用委托

- 变更抵押品

- 批处理闪电贷

- 债务代币化

- 社区治理

- 详解

- 固定利率存款

- 稳定借贷率

- Borrowing=借款

- 信用委托=Credit Delegation

- 当用户在协议中存入抵押品时，他们可以通过调用相关债务令牌上的approveDelegation()轻松地将信用委托给任何地址

- Debt Tokens | v2 | Developers (aave.com)

- 请参阅信用委托指南了解更多细节

- Credit Delegation | v2 | Developers (aave.com)

- 变更抵押品

- 批处理闪电贷 = Flash Loans V2

- 详见：Flash Loan闪电贷

- Tokenization

- 债务代币化=Debt Tokenization

- 跟踪用户头寸

- 在Aave v2中，所有头寸都被标记。因此，要计算用户拥有的债务，您只需要为该用户的相关债务令牌调用balanceOf()

- 有关更多信息，请参阅aTokens和Debt Tokens部分

- aTokens | v2 | Developers (aave.com)

- Debt Tokens | v2 | Developers (aave.com)

- 批准ERC20/EIP20代币:LendingPool vs LendingPoolCore

- 去掉：LendingPoolCore，新增：LendingPool

- 在Aave v2中，去掉了，保存了所有协议的资产的，LendingPoolCore合约。资产直接在相关的aToken合约中持有，LendingPool是协议的“核心”合约。

- 支持WETH

- 在Aave v2中，为了确保整个协议的一致性，我们现在使用WETH(而不是像v1中那样使用ETH和占位符保留值)。因此，要使用ETH作为资产调用函数，请使用WETH地址

- Main market | v2 | Developers (aave.com)

- 当在协议中使用ETH时，还有一个ETH助手合约可以帮助包装/解包装ETH

- 社区治理

- 结构变化

- 地址提供程序注册表=Addresses Provider Registry

- 在多个市场中，将会有多个AddressesProviders。AddressesProviderRegistry将维护所有Aave市场地址提供程序的注册表

- 取代LendingPoolCore

- LendingPoolCore不再使用。只使用了LendingPool，这简化了在Aave v2上的集成和构建

- 细节

- Deposit=存款

- 通过LendingPool赎回和取款，而不是通过aToken

- 在Aave v2中，几乎所有的操作都应该通过LendingPool合约执行。这与v1不同，在v1中，需要在aToken合约中调用aToken的赎回/提取

- 在v2中，你只需要在LendingPool合约上调用withdraw

- LendingPool | v2 | Developers (aave.com)

- 删除了利息重定向功能

- 在Aave v2的初始版本中，不支持利息重定向。然而，该特性有可能在稍后通过治理过程添加回来

- aToken

- Collateral trading=抵押物交易

- Aave协议V2提供了一种交换存储资产的方式，无论是否用作抵押品。这是通过以下方式利用v2闪贷实现的:

- flashLoan()函数由用户调用，传递接收方合同的地址作为参数，实现IFlashLoanReceiver接口，这是一个不可信的合同，应该由用户提前验证;要交换的基础资产列表，这些资产的数量列表和一个包含要交换的资产的额外参数以及用户选择的最大滑动量，都是编码的。

- 然后，接收方合同将使用收到的资金将其交换到目标资产，代表用户再次存入，并提取用户的Flash货币存款，以偿还Flash Loan。

- 举个例子：

- (i)用户在协议中存入了100个LINK和20个UNI，债务为100 USDC。他想把他的存款LINK和UNI都换成AAVE，而不需要在一次交易中偿还任何债务。

- (ii)用户调用flashLoan()函数，将包含执行操作的逻辑的接收者合约的地址、LINK和UNI的地址作为参数传递;100和200作为金额，并编码为要交换的资产地址(AAVE)， 2%作为交易的最大滑点。

- (iii)接收方合同将使用去中心化交易所将指定数量的LINK和UNI交换到AAVE。

- (iii)接收方合同将代表用户在AAVE协议中存放由此产生的AAVE。

- (iv)接收方合同将从用户那里以aLINK和aUNI的形式转移等值的闪现金额，将其赎回给LINK和UNI，并将批准池在闪贷结束时提取这些资金以偿还。

- Repay with collateral=以抵押物偿还

- 该功能也通过使用Flash Loans v2构建，允许用户将一个或多个资产作为协议中的抵押品，使用它们来部分或全部偿还其债务/头寸。与交换流动性和基于Flash贷款的所有功能一样，抵押品还款使用flashLoan()函数和接收者合约，实现IFlashLoanReceiver接口。向这个接收方传递一个要闪现并用于交换和偿还的抵押资产列表、这些资产的金额列表，以及要偿还债务的资产列表、要偿还的债务金额列表和每个债务资产的借贷模式(稳定或可变)列表。值得注意的是，在这种情况下，接收方合约将期望收到需要偿还的确切金额，这与互换流动性不同，互换流动性的预期金额是互换的确切抵押品。这个功能的流程是:

- (i)用户在协议中存入100 AAVE，并以可变利率支付200 USDC的债务。由于他目前没有可用的USDC资金来偿还贷款，他想将他的部分AAVE抵押品交换给USDC并用它来偿还贷款。

- (ii)用户调用flashLoan()函数作为参数传递:包含执行操作逻辑的接收者合约的地址，AAVE的地址，7作为交换的抵押品金额(估计AAVE需要覆盖200 USDC债务)，200作为偿还的债务金额，变量作为使用的借款模式。

- (iii)接收方合同将使用去中心化交易所将7 AAVE交换给USDC。

- (iv)接收方合约将使用掉期产生的USDC来代表用户偿还协议中的USDC债务。

- (iv)一旦债务被偿还，接收方将转移从用户那里归还闪现的AAVE所需的aAAVE金额，将其赎回为AAVE，并将批准池在闪贷交易结束时提取这些资金。

- (v)如果最终由于交换而有任何剩余的7 AAVE，这些资金将代表用户存入协议中或直接发送到他的钱包。

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 11:33:04

Gas优化和改进

- AAVE V2

- Gas优化和改进=Gas optimisation and improvements

- pow函数实现

- 在最初的版本中，复利的计算依赖于使用Babylonian巴比伦方法实现的指数公式，导致更耗时和昂贵的执行。

- V2版本通过使用二项式展开(binomial expansion)近似该指数公式来优化执行成本，这在小基数下工作得很好。实现使用了如下的二项式展开

- 函数calculateCompoundedInterest(MathUtils.sol, 第46行)实现了前三个扩展，给出了长达5年贷款期限的复利的良好近似值。这就导致了天然气优化带来的收益抵消了轻微的支付不足。

- 需要注意的是，对于可变和稳定借款，这种行为略有不同

- 对于可变借款，对任何借款人的任何动作都应计算利息

- 对于稳定借款，只有当特定借款人执行某项操作时才应计算利息，从而增加了近似的影响。不过，考虑到交易成本的节省，这种差异似乎是合理的

- 从WadRayMath和PercentageMath中移除SafeMath

- V1 WadRayMathlibrary在内部使用SafeMath来保证操作的完整性。经过深入分析，SafeMath在协议的关键领域产生了大量高成本，每次调用都要支付30的gas费用。这支持重构WadRayMath以删除SafeMath，这在某些操作上节省了10-15k的gas

- 用位掩码映射用户的贷款/存款

- 在最初的V1版本中，协议循环遍历所有有效的资产，以识别用户存款和贷款。这将导致高gas消耗和降低可扩展性——因为随着协议上列出的资产越来越多，提取/借款/偿还/清算资产的成本将会增加。考虑了两个改进的想法:

1. 对于每个用户，保留一个用作抵押品/借款的资产列表，每当用户存款/取款/借款/还款时更新。在计算整个系统担保时，而不是循环遍历所有支持的资产，函数calculateUserAccountData()可以针对特定用户的资产。

2. 这种解决方案没有任何限制，尽管它更耗Gas——当考虑从列表中删除项目的成本时，检查每个aToken余额、稳定利率或可变利率的债务、用户是在存款、借贷还是两者兼而有之……

1. 创建结构如图4所示的位掩码

2. Users Collaterals/Borrows Bitmask Structure

3. 位掩码有256位大小，它被分成对的位，每个资产一个。这对的第一个比特表示资产是否被用户用作抵押品，第二个比特表示资产是否被用户借入。这个实现施加了约束:

- 只能支持128个资产，要增加更多，需要使用另一个uint256。

- 对于账户数据的计算，协议仍然需要查询所有列出的资产。

4. 与基于列表的解决方案相比，它具有以下优点:

- 额外的资产只需要花费5k gas，而不是写在清单上的2万gas

- 极其廉价地验证用户的资产借款(0xAAAAA…!=0)或存款(配置=0)

- 通过获取代币/债务代币余额，立即访问正在存入/借入/两者的资产

- 在calculateUserAccountData()中，配置可以在开始时缓存并用于执行所有计算，从而大大节省了SLOAD

- 两种解决方案都进行了实施和测试，第二种解决方案更受青睐，因为128个资产限制提供了增长空间，而且考虑到Aave的多市场。

- 使用位掩码保留配置

- 还引入了一个位掩码来存储备用配置，如图5所示

- Reserve Bitmask Structure

- 类似的封装可以通过使用uint32和布尔值来实现，位掩码受益于更高的gas效率，并且在一次更新多个配置时更加如此

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 11:27:18

AAVE v3

- AAVE V3

- 去中心化

- 治理：Controlled by Aave governance

- 存储：an IPFS-deployed

- 前端：open-sourced frontend

- 关键特性

- aToken

- choice of stable or variable interest rates

- credit delegation

- 等等

- AAVE V3的主要改进

- 概述

- improving user experience while offering increased capital efficiency with out sacrificing security

- 包括

- 资产利用率Capital efficiency

- 为流动性提供者产生更多收益

- Aave协议在多个网络中的总流动性接近200亿美元。目前，大部分流动性都闲置在协议的智能合约中，通过借款活动产生收益。尽管这种收益是稳定且安全的，但通过实施新的面向用户的功能，重复使用闲置资本而不增加偿债风险，可以增加收益。（请注意，这不包括将资产重新分配到其他协议进行“收益农场” yield farming——这通常会带来相当大的智能合约风险，并且不符合Aave作为一个0层DeFi协议的定位——其他协议经常将其资产分配出去以提高其收益。）

- 优化借款能力

- 在Aave协议的之前版本中，由于池模型内任何抵押品都可以用来借入任何“可借”资产，借款人在某些情况下面临着最大化其借款能力的挑战。因此，借款交易的风险参数设定得相当保守。

- 低效的底层网络

- 大部分供给到Aave协议的资产位于以太坊L1网络，该网络已饱和，并导致了高交易费用和用户体验的痛点。网络的低效也影响了预言机提交准确价格的能力以及响应时间的缩短。

- 聚合流动性方法

- 在Aave协议中，用户的总抵押品价值是通过聚合所有存入的抵押品的价值，并将总值规范化为某一基础货币（通常是ETH）来计算的。然后使用总抵押品价值来计算平均借款能力，该借款能力是所有单个资产的借款能力的加权平均值（更多详细信息请参见Aave白皮书，第5节）。资产的风险配置反映了总抵押品价值和总借入价值可能波动的事实，因此，设置得相当保守。这在许多情况下限制了借款人从其抵押品中获得的能力。例如，一个用户在提供稳定币的同时借入稳定币，其抵押品与借入资产之间的相对波动性较低，因此应该享有更高的抵押能力。

- 减少流动性隔离

- 新的流动性协议已经寻求通过启用独立池或独立对来提高抵押能力同时降低风险。尽管这可以提高某些资产的抵押能力，但实际上这促使了更多的流动性隔离（流动性提供者被迫在多个对/池中部署资产以匹配他们的风险偏好）和用户体验问题（借款人可能被迫将其抵押品分配到不同的池/对，以便借到他们需要的东西）。第2节更详细地分析了一些当前的方法和改进领域。新的流动性协议已经寻求通过启用独立池或独立对来提高抵押能力同时降低风险。尽管这可以提高某些资产的抵押能力，但实际上这促使了更多的流动性隔离（流动性提供者被迫在多个对/池中部署资产以匹配他们的风险偏好）和用户体验问题（借款人可能被迫将其抵押品分配到不同的池/对，以便借到他们需要的东西），并更详细地分析了当前方法及其缺陷。

- 协议安全Protocol safety

- 风险管理对于流动性协议至关重要，需要缓解智能合约风险和流动性风险。对于智能合约风险，需要仔细审查并审核任何代码更新和治理提案的审计过程。这主要是一个线下/协调问题，管理这种风险通常涉及在处理代码/智能合约升级时保持关键任务文化。流动性风险更为微妙，涉及仔细评估市场条件以调整参数配置，以及对社区提出的资产上市提案进行适当的尽职调查（Aave社区开发并维护了Aave风险框架）。

- 当前Aave协议迭代中的风险配置不幸地受到限制。尽管可以即时调整借款能力（LTV）和维护保证金（清算门槛），但协议可以从增加防御措施中受益，以防止无限制增发或操纵预言机等可能的攻击。

- 去中心化Decentralization

- 协议管理完全去中心化，因此由AAVE代币持有者（“Aave治理”）控制。Aave治理在协议配置的某些方面扮演着守门人的角色（例如，上市新资产）。虽然这对于确保协议的安全性很重要，但对于希望通过上市代币来获取Aave协议流动性的团队和项目来说，这在某种程度上是限制性的。

- 用户体验User experience

- 在一个多链和多个汇总网络的世界中，允许流动性在不同链之间无缝流动变得越来越重要。虽然Aave协议目前已部署在多个具有重要总锁定价值（TVL）的网络上，但用户没有无缝的方式将流动性从一个网络上的Aave实例移动到另一个网络上的Aave实例。

- 具体方案

- 独立流动性对=Isolated liquidity pairs

- 这种方法使用了通常定义为“独立对”的方式——在这种对中，借款人只能使用特定的抵押品借入一种资产。与Aave V2的聚合池方法相比，这有一些优势：

- 减少了gas费用

- 总体而言，交互的gas足迹减少了，因为状态管理较少，且不需要迭代用户借入和提供的所有资产。

- 无需许可的上市新资产

- 任何资产都可以在非常有限的风险管理下被上市。

- 然而，这种设计也影响了协议扩展能力的能力。

- 极端的流动性隔离

- 流动性现在严格按抵押品隔离，这意味着供应商可能被迫将他们的资本分散到多个池中以追求最高的收益。尽管通过在协议之上构建的工具可以聚合提供的加密资产，这减少了用户微调其风险档案的能力，至少部分地使这种方法的一个主要优势失效。这也意味着，对于每个新对，都需要为借款人建立流动性，以便他们能够借入新上市的资产。

- 借款人的糟糕用户体验

- 在Aave协议中，借款的行为是直接的，因为提供的抵押品和借入的加密资产都被聚合了。这提供了非常简单的用户体验：借款人只要提供所需的过度抵押，就可以立即借入任何资产，而只需要管理一个位置。使用独立对时，如果借款人想借入多种资产，即使使用单一形式的抵押品，也必须同时与多个对进行交互。这导致必须同时管理许多位置。这可以通过在协议之上构建解决方案来缓解，但它减少了流动性隔离的影响，并且也使得主要优势之一（燃气成本）失效。流动性隔离通常也意味着更高的平均借款利率。

- 倾向于更高风险的资产

- 通常，使用风险资产作为抵押品的借款人（在其他流动性协议上）愿意支付比使用更安全资产的借款人更多的费用。这种用户行为可能允许在允许无许可资产上市且没有任何债务上限的协议中进行潜在的攻击。例如，用户可能不当地向一个新创建的池供应稳定币，该池中有一个波动性或其他不稳定的资产，通过人为地借用该资产，增加了质押者的吸引力。

- 独立流动性池=Isolated liquidity pools

- 孤立池定义了一种本质上是Aave和孤立对之间的混合体的架构，例如，一个无需许可的协议，用于创建带有特定资产和自定义风险管理配置的独立市场。这种方法类似于Aave在2020年开创的首个Uniswap池，用于借入Uniswap V1 LP资产。拥有多个市场使用户能够将风险分散到资产群中，减少潜在资产失败的影响，而不牺牲用户体验，并在流动性隔离方面作出一些妥协。

- 由于其特定架构，这种方法遭受一些与孤立对相同的问题。虽然不那么严重，但流动性隔离仍然很重要——许多池子难以吸引流动性。总锁定价值（TVL）也通常偏向于更高风险的资产。

- AAVE V3概览

- 概述

- Aave V3的设计源于对该协议及其生态系统发展的深思熟虑的分析。V3增强的功能为新的使用案例提供了可能，这将激发用户和开发者的创新浪潮。Aave V3在所有前述类别中进行了改进——资本效率、安全性、去中心化、用户体验——同时提供新的功能，以利用卷积技术和竞争激烈的L1生态系统的发展。

- 资金效率和用户体验改进

- Portal

- E-Mode

- Isolation Mode

- Risk Management

- 去中心化

- Aave V3 引入了资产上市管理员（Asset Listing Admins）。上市管理员是一个特定的角色，可以通过 Aave 治理授予，允许采用除了在 Aave V2 中看到的链上投票之外的不同资产上市策略。这将允许开发者创建定制的资产上市策略，旨在实现真正的无需许可的资产上市

- Aave V3引入了一个新的系统角色——ASSET_LISTING_ADMIN_ROLE——它可以被Aave治理授予，允许管理员为每个资产列表创建和设置自定义的资产列表策略。

- Multiple Rewards and Claim

- 其他特性

- 涉及代币转移的所有功能（供应、还款）现在支持 EIP 2612 许可（这对 L2 尤其重要）。

- EIP 712 签名用于信用授权（合约不再需要请求用户交易）。

- 使用 aTokens 还款：允许借款人使用 aTokens 而不是基础资产进行还款。

- 闪电贷的许可列表：治理可以允许实体访问免费的即时流动性（免除闪电贷溢价）。

- 清算的协议费（可配置）。

- 即时流动性的协议费（可配置）。

- 简化的闪电贷：新的 flashloanSimple() 函数能够减少高达 20% 的气体消耗，与标准的即时流动性功能相比（仍然可用）。

- 价格预言机逻辑重构，以推广基础资产的计算（不再仅限于 ETH）。

- Gas优化：尽管增加了所有新功能，所有功能的气体成本平均下降了约 20 * 25%。

- 代码重组，更加模块化。

- 智能合约重构大大减小了代码体积（未来更改的余地更大）→ 高达 100K 的优化器运行次数！

- 新的利率策略优化了稳定利率的计算（不再需要平均稳定借款利率的预言机）

- 详见：https://governance.aave.com/t/base-stable-rate-oracle-update-and-improvements-in-aave-v2/1879 的第 4.4 节

- 移除稳定利率预言机

- 新的利率策略实施了一种算法方式来管理稳定利率，如治理论坛上所讨论的那样。当前的实施方案取消了借贷利率预言机，转而优化稳定利率与某个确定的最优稳定/变动债务比率相对应，该比率由利率策略定义，并将最小稳定债务年化利率设定为slope(v,1) + offset(base)。

- 例如，对于一个稳定偏移为2%的资产，在其90%的最优利用率下达到4%的变动利率，最小稳定利率将为6%。然后使用斜率slope(s,1)和slope(s,2)计算利率，并且如果稳定/变动债务超出最优，还会进一步以offset(excess)为上限进行偏移。

- 要计算稳定利率，设O(util)和O(ratio)分别为最优利用率和最优稳定至总债务比率常数，然后按下述方式计算稳定利率：

- Aave接口

- Aave接口以分散的方式托管在IPFS上。Aave将以下DNS名称映射到Cloudflare IPFS网关:

- https://app.aave.com

- 将始终指向禁用测试网络的最新主IPFS哈希值

- https://staging.aave.com

- 将始终指向所有网络启用时最新的主IPFS哈希值

- L2层优化

- L2上的主要交易成本来自于calldata。为了尽量减少这一成本，Aave V3在Arbitrum和Optimism上使用了略有不同的L2合约，这些合约压缩了传递给Pool方法的信息。

- 以下是为L2优化引入的合约：

- L2Pool：一个为L2优化的用户面向方法的合约，接受字节编码的输入参数。

- CalldataLogic：用于解码传递给L2Pool的byte32参数的库合约。

- L2Encoder：一个辅助合约，拥有视图方法，用于编码数据以传递给L2Pool。

- 在L2Pool.sol中未公开的Pool方法（如flashLoan, setUserEMode等）在L2上与协议的其他版本相同

- 详见

- https://docs.aave.com/developers/core-contracts/pool

- https://docs.aave.com/developers/getting-started/l2-optimization/l2pool

- https://docs.aave.com/developers/getting-started/l2-optimization/l2encoder

- 从v2迁移到v3

- 为了将您的资产从V2市场转移到V3市场，您可以使用迁移工具，该工具可以帮助并指导您在V2仪表板上的单个交易中迁移您的头寸。要找到迁移按钮，请前往您拥有资产的任何V3版本V2市场中的仪表板，并单击市场名称右侧的“Migrate To V3”。

- 你所需要做的就是:

- 选择要迁移的供应和借款账户

- 点击“预览tx并迁移”

- 签署批准每个职位

- 提交迁移事务

- 如果您有新开账户，迁移工具将通知您V2和V3上的新健康因子。请注意这一新的健康因素，以减轻清算风险。

- 每个供应位置都需要批准迁移合同才能转让aToken，每个借款位置都需要批准信用委托，以便迁移合同代表您在V3中执行借款。这两种审批都可以通过签名消息或审批事务执行。如果您在V2中有大量的借存资产，建议您分批迁移。建议在单个迁移事务中迁移不超过5个资产。没有必要将资产从V2迁移到V3, V2契约将继续运行并保持可访问性。迁移工具使用信用委托和闪贷的组合来迁移头寸。该工具使用闪贷和信用委托，在V2上偿还债务，在V3上代表用户借入相同的头寸和金额，将用户债务留在V3上。

- 如果您想查看技术实现，您可以在这里找到迁移工具契约。

- https://github.com/bgd-labs/V2-V3-migration-helpers/blob/main/src/contracts/MigrationHelper.sol

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 10:12:35

E-Mode

- AAVE协议V3： E-Mode  =  eMode  =  Efficiency Mode  =  High Efficiency Mode  =  高效率模式

- 背景

- 高效模式功能旨在在抵押品和借入资产价格相关联时，尤其是当两者都是同一基础资产的衍生品时，最大化资本效率。稳定币通常锚定于特定的基础资产（例如，一美元），而严重脱锚的情况很少见。以太坊及其衍生品（如 stETH、sETH、alETH 等）的表现与其基础资产（ETH）类似。在这些情况下，有可能授予非常高的抵押权力。

- 在 Aave 协议的原始设计中，抵押品价值和借入资产通常被标准化为基础货币（ETH 或 USD），并且链上无法知道哪些抵押品支持哪些借入资产，这使得提高抵押效率变得非常困难。

- E-模式引入了一种资产分类，将 Aave 协议上所有列出的资产放在一个特定的类别中；同一类别的资产通常在价格上高度相关。正确的分类不能在链上强制执行，需要由管理协议的实体（通常是 Aave 治理）维护。

- eMode还提供了为特定类别引入特定价格的可能性

- 用户可以有意选择借入一个特定的类别，并且当使用属于同一类别的抵押品时，可以运用高额的抵押权力。

- E-模式还提供了为特定类别引入特定价格预言机的可能性。例如，对于只定义了 renBTC 和 WBTC 的类别，当用户处于 BTC E-模式时，可以为它们两者使用 BTC/USD 预言机。这将进一步减少不希望的清算风险，因为它消除了预言机的不同步性（例如，在 BTC 价格急剧下跌的情况下，WBTC/USD 和 renBTC/USD 预言机可能会在略微不同的时间更新，因为它们是异步的；这可能导致不希望的清算）。特定类别的预言机为协议引入了更多风险，因为如果其中一个资产未能保持其价值（例如由于协议黑客攻击或特定衍生品的底层问题），可能会导致资不抵债。Aave 治理需要仔细评估每个资产和每个类别的情况，决定是否使用特定类别的预言机。基于上述所有原因，E-模式更适合更快的网络（尤其是 rollups），在这些网络中，预言机可以更高效，且不会因高交易成本而引发清算。

- 概述

- 高效率模式（E-Mode）允许借款人从他们的抵押品中获取最高的借款能力

- 当提供的资产和借入的资产价格相关时，特别是当两者都是同一基础资产的衍生品时，高效模式或eMode允许借款人从抵押品中提取最高的借款能力，与美元挂钩的稳定币)

- 目的

- 旨在当抵押品和借入资产的价格相关时，实现资本效率最大化

- 效果=用途

- 高杠杆外汇交易=High leverage forex trading

- 高效收益农业(例如，存入ETH投资衍生品以借入ETH) =Highly efficient yield farming (for example, deposit ETH staking derivatives to borrow ETH)

- 多元化风险管理=Diversified risk management

- category类别

- 由Aave Governance设置的RISK_ADMINS和POOL_ADMIN，最多可以配置255个eMode类别：EModeCategory

- 每个分类（EModeCategory）具有以下风险管理参数

- LTV=贷款价值比

- 清算阈值=Liquidation threshold

- 清算奖金=Liquidation bonus

- 自定义价格预言机（可选）

- 细节

- 在Aave V3上列出的所有资产都可以通过RISK_ADMINS或POOL_ADMIN设置为任何预先配置的eModeCategory

- E-Mode 允许借款人限制自己只借入属于某一特定类别的资产（例如，稳定币）。当这种情况发生时，如果用户提供同一类别的资产作为抵押，借款能力（LTV）和维持保证金（清算门槛）将被 E-Mode 类别配置重写，以提高资本效率。请参见图1，其中有多个类别的示意图。

- 在V3中，Aave协议可以支持最多255个E-Mode类别，使得如下新的使用案例成为可能：

- 高效的收益农场（例如，存入ETH抵押衍生品来借入ETH）

- 多样化的风险管理

- 举例

- Aave 协议定义了 E-Mode 类别 1（稳定币）为：97% 的贷款价值比（LTV），98% 的清算门槛，以及2% 的清算奖励，不需要自定义价格预言机。

1. 用户选择 E-Mode 类别 1（稳定币）

2. 图1：展示三个 E-Mode 类别（稳定币，以太坊，比特币）的插图

1. 用户提供 DAI（通常具有 75% 的 LTV）

1. 用户现在被允许借入其他稳定币（包括 DAI），借款能力由 E-Mode 类别定义（97%）。因此，用户的资本效率提高了22%。请注意，用户仍然被允许提供其他资产并将它们用作抵押品，但只有属于用户选择的相同 E-Mode 类别的抵押品将拥有增强的风险参数。

- 不变量Invariants

- 类别0

- 类别 0 被保留为默认的非 eMode类别。在Aave V3中列出的所有资产，默认都是类别0(这表示标准操作模式)

- 进入E-模式

- 用户只有在所有借入的资产都在选定的类别中时，才能进入 E-模式（类别 != 0）。

- 退出E-模式

- 用户只有在退出 E-模式不会使其头寸资不抵债（HF ≥ 1）时，才能退出 E-模式（设置类别为 0）。

- 用户借款

- 在 E-模式下的用户只能借入选定类别的资产。用户可以使用任何资产作为抵押，但只有同一 E-模式类别的资产才能享受更高的抵押率。

- 资产添加

- 只有在 E-模式类别的贷款价值比（LTV）和清算门槛高于资产的默认非 E-模式风险参数时，授权实体（风险或资金池管理员）才能将资产添加到 E-模式。

- 资产移除

- 授权实体（风险或资金池管理员）可以将资产从 E-模式中移除。这可能会导致一些用户的资金状况不足，进而发生不希望的清算（参见第 4.7 节）。按设计，借用已从 E-模式类别中移除的资产的用户不会受到影响。那些仍在 E-模式中的用户在移除后将无法再借用该资产

- 工作原理

- 如果用户向协议提供了流动性，则默认将用户的eMode类别设置为0。

- 该协议允许用户将用户eMode类别设置为PoolConfigurator配置的任何eModeCategories，前提是以下条件成立:

- 用户的所有借款资产都在所选类别中。

- 改变eMode不会让用户的位置没有担保

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-29 11:33:24

Isolation Mode

- AAVE协议V3：Isolation Mode=隔离模式

- 背景

- 在包括 Aave V2 在内的当前代流动性协议中，当一个新资产被上市时，整个流动性池将对其暴露，这意味着使用新抵押资产的用户可能能够借用全部可用流动性。这极大地限制了向 Aave 协议添加新资产的能力，因为每一个新资产都会增加流动性和偿债能力风险。隔离模式为此问题提供了解决方案。

- 当 Aave 管理层在 Aave 协议上列出一项资产时，使用它作为抵押品的借款人立即可以访问整个协议的流动性。这使得列出新资产变得复杂，并降低了借款人的资本效率。因此，V3 引入了隔离模式，其灵感来自 MakerDAO 的风险暴露管理方法。

- 概述

- 隔离模式是一个新的风险管理参数，允许协议限制用作抵押品的新资产的风险。在隔离模式下，V3上列出的新资产只能借用已被允许借用的稳定币。

- 隔离模式允许将新资产列为隔离资产，该资产具有特定的债务上限，并且只能用于借入已被Aave治理配置为可在隔离模式下借入的稳定币。独立代表的债务上限是可以以抵押品为抵押借入的最大美元金额。

- 细节

- 现在，资产可以（如果 Aave 管理层投票同意）被列为“隔离”。提供隔离资产作为抵押品的借款人不能提供其他资产作为抵押（尽管他们仍然可以提供以获得收益）。只有被 Aave 管理层允许在隔离模式中借入的稳定币可以被使用隔离抵押的用户借用，直到指定的债务上限。

- 隔离模式允许协议将资产列为隔离资产；隔离资产有特定的债务上限（代表可以针对抵押品借入的最大美元金额，精确到小数点后两位）。使用隔离资产作为抵押的借款人只能使用该特定资产作为抵押，不能启用任何其他资产（包括其他隔离资产）。使用隔离资产的用户仍然可以提供其他资产以产生收益。

- 在隔离模式中可以借用的资产由标志“BORROWABLE IN ISOLATION”指示，并且应该是美元稳定币，尽管设计允许选择任何计价单位的资产用于隔离借用。在隔离模式中可借用的资产需要属于同一家族，否则债务上限的计算将不一致；这种一致性无法在智能合约级别强制执行，当允许资产在隔离中被借用时，治理者应该小心谨慎。

- 新的资产可以在Aave协议V3中被列为隔离资产。提供单独资产作为抵押品的借款人不能提供其他资产作为抵押品(尽管他们仍然可以提供以获取收益)。使用隔离抵押品的借款人只能借到由Aave治理配置为可在隔离模式下借款的稳定币，上限不超过指定的债务上限。

- 在实时仪表板上查看债务上限和可借款隔离模式参数。

- 举例

- 图2：用户以 $Token2 作为抵押品并借入稳定币的示意图

- 在图2中，用户正在提供 $TOKEN2 作为抵押品。$TOKEN2 是一种隔离资产，最大债务上限为1000万美元。因此，用户将被允许借入高达1000万美元的 USDT、DAI 和 USDC（在这个例子中，这是隔离模式中允许借入的唯一三种资产），并且不被允许激活任何其他资产作为抵押品（用户仍然可以供应以太坊，例如，用于产生收益）。用户可以随时通过禁用 $TOKEN2 作为抵押品（只要它不导致清算）来退出隔离模式。当 Aave 管理层决定移除债务上限时，$TOKEN2 可以退出隔离模式。这将来允许真正无需许可的列名，具备风险管理。

- 不变量Invariants

- 隔离资产

- 任何债务上限大于 0 的资产都是隔离资产。

- 添加隔离资产

- 当没有提供流动性时（通过 checkNoSuppliers() 强制执行），资产才能被配置为隔离资产。

- 隔离抵押

- 用户提供隔离资产作为抵押将只被允许使用该资产作为抵押；在其他任何情况（供应、转移、清算、设置为抵押）中，都不应该可能启用非隔离资产作为抵押。

- 供应隔离资产

- 供应其他资产并将其用作抵押的用户仍然可以供应隔离资产以产生收益。当用户已经供应了其他非隔离资产并已将这些资产启用为抵押时，绝不应该可能启用隔离资产作为抵押。

- 退出隔离模式

- 用户可以通过禁用隔离资产作为抵押来退出隔离模式。鉴于隔离资产的性质，这只能在用户没有借款的情况下发生。

- 从隔离模式中移除资产

- 授权实体可以在任何时候将资产从隔离模式中移除。

- 债务上限

- 当达到隔离债务上限时，应禁止用户借款（债务上限不包括随时间累积的利息，仅包括借入的本金）。

- 供应隔离资产 = 如何进入隔离模式?

- 用户可以像使用池中的supply()方法提供任何其他资产一样提供隔离资产。但是，在提供隔离资产时的默认行为可能会根据以下条件而变化

- 如果用户启用了其他资产作为抵押品，他们仍然可以提供隔离资产以获取收益，但不能将其用作抵押品

- 隔离模式仅对治理投票通过的某些资产启用。不能使用非隔离资产作为抵押品进入隔离模式。在成功进入资产隔离模式后，您只能在一定的债务上限内借入稳定币。

- 隔离模式中借贷

- 使用隔离资产作为抵押品的借款人只能使用该特定资产作为抵押品，并且只能借用在隔离模式下可借贷的资产，即在储备配置中设置BORROWABLE_IN_ISOLATION_MASK位。

- 隔离模式下的借款人不能启用任何其他资产，包括其他被隔离的资产作为抵押品

- 退出隔离模式 = 如何退出隔离模式?

- 若要退出隔离模式，您需要禁用已提供的担保隔离资产。

- 用户可以通过禁用隔离资产作为附属来关闭隔离模式。只有在用户没有未偿债务的情况下才能这样做。用户必须在Pool中使用return()方法。他们必须在退出隔离模式前还清所有债务

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:27:48

Portal

- AAVE协议V3：Portal = 门户

- 作用：资产跨链（AAVE的不同的市场Market）流动

- 概述

- 允许用户在不同区块链网络上的各种V3部署之间无缝移动资产。这意味着用户提供的流动性可以从一个网络转移到另一个网络，只需在源网络(例如以太坊)上燃烧aToken，同时在目标网络(例如Polygon)上铸造它们

- Aave协议V3允许经过批准的网桥在源网络上烧掉aToken，同时在目标网络上立即铸造aToken。然后，可以将基础资产以延迟的方式提供给目标网络上的Aave，方法是在资产通过桥接器移动后将其传递到池中

- 相关角色

- approved BRIDGE=授权的桥

- Bridging protocol具体实现

- Connext

- Hop Protocol

- Anyswap

- xPollinate

- 附加特性

- 为了支持Portal，协议需要以下三个附加特性:

- 铸造无担保令牌

- 允许具有BRIDGE角色权限的地址将无担保令牌铸造到onBehalfOf地址。

- 支持无担保代币

- 允许具有BRIDGE角色权限的合约以一定数量的基础资产支持当前无担保的代币并支付费用。

- 白名单桥

- 允许桥角色管理员添加/删除BRIDGE_ROLE的地址

- 详解

- Portal功能可用于允许提供的资产在不同网络上的Aave市场之间无缝流动。

- Portal 代表了一组新的核心功能，可用于允许供应的资产在不同网络的 Aave 市场之间无缝流动。在高层次上，这个功能非常简单：协议利用 aTokens 的独特锚定设计，在源网络上销毁 aTokens 同时在目的网络上铸造它们。这使得以一种延迟的方式供应资产成为可能，其中底层加密资产在通过规范链桥后被供应到 Aave 协议。

- Portal 代表一组核心功能，这些功能可以用来允许提供的资产在不同网络的 Aave 实例之间无缝流动。从高层次来看，这个功能本身非常简单：

- Aave 协议利用 aTokens 的独特设计，在源网络上销毁 aTokens，同时在目的网络上立即生成它们。然后，底层资产可以通过桥梁移动后延迟提供给目的网络上的 Aave，传递给池子。这对目的网络上市场的利率计算和总体安全性有多种影响。

- 从设计上看，协议级别几乎不需要任何功能就可以支持多种非常不同的门户实现。

- 协议只需要三个额外功能

- i) 铸造无担保的 aTokens

- ii) 为无担保的 aTokens 提供担保

- iii) 对希望使用这些功能的合同实施白名单机制。

- 除了这些功能外，还需要对每个储备的无担保金额进行额外的内部核算，以及对利率计算的更新。

- 请注意，铸造无担保的 aTokens 不会影响借款人的使用率，因为没有提供额外的流动性（util(V2) = util(borrow)），然而，必须在供应使用中考虑这一点，因为无担保的 aTokens 正在累积利息。为了适应这种情况，我们分别计算借款和供应两侧的使用率如下：

- 如方程 6 中所示，增加无担保价值将降低供应利用率，从而降低流动性提供者所赚取的利息，因为他们被铸造的代币稀释了。为了抵消这种利息稀释，无担保资产的支持支付了一笔累积到流动性指数的费用。这个费用应该覆盖由铸造代币所赚取的利息（注意，累积到流动性指数的利息也将一部分利息重定向到铸造的代币），因此，为了抵消在一定金额上所赚取的利息，它应满足：

- 虽然利率计算是核心协议的一部分，但为了覆盖无担保金额和费用所需的协议费用的计算来自核心协议之外。由于在协议级别不强制执行延期供应（通过 backUnbacked）和费用计算，管理者在批准桥接（端口）访问 Portal 功能时应谨慎。为了防止过度铸造无担保 aTokens 的潜在风险，可以为每个资产指定一个 unbackedMintCap。

- 举例

- 考虑这样一个场景:用户想要将资金从以太坊转移到L2或另一条链上(例如 Arbitrum, Avalanche):

- 用户将 bridge tx 提交给经过验证的桥接协议(例如Connext)，并在tx被挖掘后立即访问目标链上的资金

- 在幕后，桥接协议:

- 在目标链上将无担保的aToken铸币到中间合约，然后立即提取并将基础资产转移给用户。

- 批量处理多个桥tx，并实际将基础资产移动到L2

- 之后，一旦L2上的资金可用，L2上的桥接合约(即在Aave V3上具有BRIDGE权限)将基础资产和费用提供给Aave池，以支持先前制造的无支持的aToken代币

- 利用这个特性有3个部分:

- 批准BRIDGE角色的合同

- function addBridge (bridge)

- 由于只有添加到BRIDGE角色成员列表中的合约(地址)才能跨Aave V3市场移动提供的流动性，因此Aave治理必须通过ACLManager向经过验证的桥接合约授予所需的权限/角色。

- 利率计算是核心协议的一部分，但计算延迟供应以覆盖无担保金额和协议费用并不是核心协议强制执行的。因此，政府在批准这些桥梁时必须谨慎行事。

- 在目的地网络上立即获得流动性

- function mintUnbacked (asset, amount, onBehalfOf, referralCode)

- 具有BRIDGE角色的契约可以通过调用Pool.sol中的mintUnbacked立即跨网络访问Aave V3中提供的资产。onBehalfOf指定的地址将访问相应数量的token。

- 为了防止过度铸造无担保代币的潜在风险，每个资产都指定了一个unbackedMintCap

- 通过桥后移动资金的流动性

- function backUnbacked (asset, amount, fee)

- 一旦基础资产通过跨链桥转移到目标网络，就可以通过调用pool.sol中的backUnbacked将其与费用一起提供给目标网络上的Aave V3池。

- 支付给协议的金额和费用由BRIDGE角色的治理投票决定。

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:30:58

Risk Management

- AAVE协议V3：风险管理=Risk Management

- Aave V3 引入了更复杂的风险参数和功能，为协议提供高水平的潜在破产保护。

- Aave V3带来了极大改进的风险参数集和新功能，以保护协议免于破产。

- 供应和借款上限=Supply and Borrow Caps

- 概述

- Aave治理现在可以配置借款上限和供应上限

- Aave 治理可以任命 RISK_ADMIN 和 POOL_ADMIN，他们有权配置各个储备金的借贷和供应上限。

- 可以在实时仪表板上查看供应和借款等参数

- 借款上限

- 类似于其他流动性协议中实施的，允许协议调节每种资产可以借出的数量

- 允许调节每种资产的可借贷量，以降低破产风险。

- 默认情况下，一个资产的借贷上限为0，表示无上限。任何通过 ACLManager 获得 RISK_ADMIN 或 POOL_ADMIN 角色的人都可以调用 PoolConfigurator 中的 setBorrowCap 方法，更新给定储备的最大总借贷量（固定+可变）。

- 如果储备的 借贷上限 设定低于当前的 总债务，现有的借款人不会受到影响，但该储备将不能启动更多的借款（固定或可变）。

- 供应上限

- 允许限制向 Aave 协议供应某种资产的数量。这有助于减少对某一资产的风险敞口，并减轻无限挖矿或价格预言机操纵等攻击的风险。

- 默认情况下，一个资产的供应上限为0，表示无上限。任何通过 ACLManager 获得 RISK_ADMIN 或 POOL_ADMIN 角色的人都可以调用 PoolConfigurator 中的 setSupplyCap 方法，更新给定储备的流动性供应。

- 如果储备的供应上限设定低于该储备的当前流动性，现有的供应者不会受到影响，但不能再向该储备提供更多流动性。

- 精细的借款能力控制

- 风险管理员

- Aave V3 引入了 Aave 管理层赋予权限给实体（例如，RiskDAO或自动化代理）的能力，使其能够在不需要治理投票的情况下更改风险参数。这些实体可以在此功能之上构建，以在某些不变性被打破时自动做出反应。

- Aave V3引入了Aave治理的能力，通过对每个更改进行治理投票，授予实体更新风险参数的权限。这些实体可以是dao或自动代理(例如。RiskDAO, Gauntlet)可以在此功能的基础上构建，以便在发生意外事件时自动做出反应。

- Aave治理将能够撤销对现有风险管理员的访问权限或添加新的风险管理员。

- Price Oracle Sentinel

- 可变清算关闭因子

- 在 Aave V2 中，清算在任何时候只能清算一半的头寸。这在许多情况下被证明是低效的，尤其是在交易费用高和/或头寸小的情况下。

- 在 V3 中，这种机制已经得到改进，允许当头寸接近破产（健康因子 < 0.95）时完全清算头寸

- 在V3中，清算机制得到了改进，允许头寸在接近破产时完全清算，即HF < 0.95(以前在任何时候只能清算一半的头寸)。

- Siloed Borrowing

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:31:59

Granular borrowing power control

- AAVE协议V3：精细的借款能力控制 = Granular borrowing power control

- 概述

- 目前，各种流动性协议不允许在不最终导致清算的情况下减少资产的借款能力。当某个资产的风险轮廓发生变化时，这种限制尤其明显——例如，变得不可能在不清算先前借款人的情况下降低对该资产的暴露。

- 在 Aave V3 中，通过精细的借款能力控制，Aave治理可以将任何资产的借款能力降低至 0%，而不影响现有借款人（尽管如果被认为必要，仍然可以清算现有用户）。

- 在Aave V3中，可以将任何资产的借款能力降低到0%，而不会对现有借款人产生任何影响(如果认为有必要，仍然可以使用旧方法——清算现有用户)。

- 详解

- 粒度借贷能力控制设计包括将大多数流动性协议中通常使用的抵押品因素分为贷款价值比（LTV，定义了新借款的借贷能力）和清算阈值（定义了维持保证金，或换句话说，被视为抵押不足且因此受到清算的抵押品/债务比率）。这种能力，即独立于维持保证金设置借贷能力，允许更精细地控制与特定资产相关的风险，同时避免影响现有用户。在Aave V2中，这一功能已经实现，但主要被视为对借款人借款至维持保证金上限并因此立即被清算的一种软保护。

- 举例

- Alice希望使用具有0贷款价值比（LTV）和清算门槛大于0的资产进行借款。按常理这是不可能的，但Alice可以这样做：

1. 存入一个 LTV>0 的资产（例如，使用闪电贷）

2. 提供一个 LTV=0 的资产

3. 借款

4. 取出一个 LTV>0 的资产

- 这将使协议处于一个起始时担保资产LTV为0的位置

- Aave V3引入了更严格的LTV规则，因此现在可以实施实际的0借款能力，同时防止上述情况发生。这种保护要求使用多个资产作为抵押的借款人——其中一个或多个的LTV等于0，必须首先提取这些资产，因此不能提取LTV大于0的资产。在上述例子中，在V3中，Alice将不被允许执行最后一步。Alice将被要求首先取出LTV等于0的资产。因此，V3完全防止了这种情况。总的来说，细致的借款能力控制规定：

- 只要资产的LTV大于0且清算门槛大于0，用户可以借款。

- 如果某个资产的LTV被重设为0，用户不应再被允许对该资产进行借款。

- 使用多个资产作为抵押的借款人如果希望提取资产，必须在提取其他资产之前先提取所有LTV为0的资产。这适用于提取和转移。尽管如此，对于LTV不为0的资产仍然允许进行清算。

- 对于希望提高借款能力（接近清算门槛）的借款人，使用上述示例中解释的程序仍然是可以接受的。LTV与清算门槛之间的差值为借款人提供了一种柔性保护，是一种平均降低清算风险的方式，但清算门槛仍然被认为对协议是安全的。

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:35:08

Price Oracle Sentinel

- AAVE协议V3：Price Oracle Sentinel = 价格预言机哨兵

- 概述

- Sentinel 功能被设计用于 L2，以处理顺序器的最终停机（但未来可以扩展到处理 L1 的其他情况）。它引入了一个宽限期，以在特定情况下禁用借款和处理清算

- 哨兵功能为清算引入了宽限期，并在特定情况下禁止借款。

- 这个特性是专门为L2s设计的，用于处理序列器的最终停机(但将来可以扩展到处理其他情况，甚至在L1s上)。

- 详解

- Aave V3引入了一个价格预言机哨兵来缓解在第二层网络中可能出现的一些用户体验问题。

- 简要介绍L2

- 今天大多数第二层网络（乐观optimistic和有效性汇总validity rollups）使用一个中心化的区块生成器（排序器）以及分布式验证（欺诈或有效性证明）来增加吞吐量。

- 总的来说，这些架构支持两个待处理交易队列：

- 一个是链上的（需要L1交易）

- 另一个是由排序器操作的链下队列

- 虽然排序器可以使用来自两个队列的交易构建下一个L2-"区块"（这里未涵盖L1的一些排序限制），但L1待处理交易的包含通常可以被推迟到某个截止日期，之后用户可以强制采取行动，无论是包含还是zk-sync的退出模式。当排序器遇到停机时，这会导致“网络”不再推进状态——不会产生新的区块。尽管仍然可以向待处理交易队列（链上或链下）发送交易，但短期内不会发生任何事情，链下交易甚至可能因排序器架构和停机性质而被拒绝或丢弃。

- 请注意，即使交易被添加到L1的交易队列中，在交易被包含在对规范交易历史的承诺中之前（无论是由排序器还是强制包含），L2的规范状态仍然未知。

- 对于Aave协议和其他使用预言机价格提供的系统，这意味着在排序器停机时，提供的价格不会更新（毕竟它们使用交易）。本质上，在停机期间发生的整个价格变动将在排序器重新启动时应用。这种不确定性以及“慢速闪崩”的可能性，加上大多数普通用户无法直接在L1排队L2交易的事实，促使Aave V3在这些确切情况下引入了清算宽限期。只要头寸不是严重抵押不足（0.95 < HF < 1），它将有一个从排序器启动时开始到可以被清算的宽限期。如果头寸低于0.95，它可以像在L1上那样被完全清算。请注意，这个宽限期只有在排序器停机时才会被激活。在宽限期间，用户也将不被允许借款。

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:33:28

Siloed Borrowing

- AAVE协议V3：Siloed Borrowing=孤立借贷=单独借贷=筒仓式借贷

- 概述

- 孤立借贷允许具有潜在可操纵的资产(例如非流动性的Uni V3对)在Aave上作为单一借贷资产列出。这意味着，如果一个资产被配置为孤立的，它就不能与其他资产同时在一个位置上被借用。这有助于降低与此类资产相关的风险，避免影响协议的整体偿付能力

- 详解

- 此功能允许具有潜在可操作的预言机的资产(例如非流动性的Uni V3对)在Aave上作为单一借款资产列出。这意味着，如果一个资产被配置为孤立的，它就不能与其他资产同时在一个位置上被借用。这有助于降低与此类资产相关的风险，避免影响协议的整体偿付能力。

- 孤立借贷可以被认为是孤立模式Isolation Mode对抵押品的补充特征:其中一个表明资产是否需要是头寸中唯一借入的资产(孤立)，另一个表明抵押品是否可以是头寸中唯一受健康因素影响的抵押品(孤立抵押品)。

- 由Aave Governance选择的风险管理或池管理可以调用setSiloedBorrowing以在Siloed Borrowing模式下设置资产。

- 供应孤立资产

- 用户可以像使用pool中的supply()方法提供任何其他资产一样提供Siloed资产。但是，资产将不能用作抵押品，即提供的金额不会添加到用户的总抵押品余额中。

- 借入孤立资产

- 借用孤立资产的用户不能在借用其他资产的同时借用处于某个位置的孤立资产。

- 用户可以使用池中的borrow()方法借用竖井资产。索尔，只有当:

- 这是首先借用代的地址

- 或

- 现有用户债务属于同样的孤立资产。

- 要检查用户是否处于孤岛借用状态，您可以使用AaveProtocolDataProvider.sol上的getSiloedBorrowing()方法查看用户借用的基础资产是否处于孤岛。

- 检查是否为单独借贷保留

- 代码

import {AaveProtocolDataProvider} from '@aave/core-v3/contracts/misc/AaveProtocolDataProvider.sol';

AaveProtocolDataProvider poolDataProvider = AaveProtocolDataProvider(provider.getPoolDataProvider());

// address of the underlying asset

address asset = "0x...";

protocolDataProvider.getSiloedBorrowing(asset);

- 常见问题

- 用户如何进入孤立借贷状态?

- 用户在首次成功借用孤立资产时自动进入孤立借贷状态。

- 用户如何退出孤立借贷状态?

- 用户必须偿还所有债务才能退出孤立借贷状态。

- 目前在Aave V3市场中是否有资产被孤立?

- 目前，在任何V3市场中都没有标记孤立的资产。如果需要，风险或资产池管理员可以根据市场情况将已列出的资产设置为孤岛。此功能可用于风险较高的新资产上市。

- 相关代码

- aave-v3-core/contracts/protocol/libraries/logic/ValidationLogic.sol at master · aave/aave-v3-core (github.com)

- uint256 maxLoanSizeStable = vars.availableLiquidity.percentMul(params.maxStableLoanPercent);

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:35:49

权限和角色管理

- AAVE协议V3：System roles, responsibilities and threat model

- 概述

- Aave 协议实现了一个访问控制列表，用于区分可以分配给协议上不同实体的权限和/或利益。这些角色和持有者由 ACLManager 合约管理。ACLManager 跟踪各个角色及其持有者，并允许角色管理员管理角色。角色管理员本身也是一个由DEFAULT_ADMIN_ROLE 管理的角色。

- 管理协议各个组成部分的合约，包括 ACLManager 和 Pool 的是 PoolAddressesProvider。地址提供者跟踪各种协议模块，并且有能力更新指针（例如，更新 ACLManager 合约）或更新代理合约的实现（例如，更新 Pool 实现）。PoolAddressesProvider 由 Aave Governance 拥有，并指定DEFAULT_ADMIN_ROLE的初始持有者。在以太坊以外的网络中，要么使用跨链治理桥（https://github.com/aave/governance-crosschain-bridges），要么使用社区多签来管理 PoolAddressesProvider。

- 详解

- 角色的权力和责任

- 下面我们概述了各个角色的权力和责任。FLASH_BORROWER 和 BRIDGE 的直接责任较少，主要可以访问协议的特定功能，而管理员角色则拥有处理风险或配置参数的权力和责任。

- FLASH_BORROWER

- 闪贷者这个角色的持有人将有闪贷的溢价豁免(不包括简单的闪贷)。

- BRIDGE

- holder可以执行mintUnbacked()和backUnbacked()。

- ASSET_LISTING_ADMIN = 资产列表管理员

- 此角色的持有者可以:

- 更新资产oracle源和备份oracle。

- 向Aave市场添加新资产。

- RISK ADMIN=风险管理

- 此角色的持有者可以:

- 更新预言机哨兵的宽限期。

- 更新准备金参数，如准备金系数、上限、E-Mode门类别、借款开启、允许稳定借款、冻结/解冻、LTV、流动性清算阈值、清算奖金(不能暂停/取消暂停或激活激活/停用准备金)。

- 创建新的和更新现有的电子模式类别(不是类别0)。

- 更新无担保的铸币厂上限和清算协议费用。

- ACL_ADMIN

- 在ACLManager中管理角色admins

- EMERGENCY_ADMIN

- 该角色的持有者可以暂停和取消暂停池或者个人储备。

- POOL_ADMIN

- 此角色的持有者可以更新令牌实现，删除，(暂停)和(取消)激活储备，更新保费以及所有资产清单管理员和风险管理员可以做的事情

- Threat Model=威胁模型

- Malicious Actors=恶意行为者

- 下面概述了恶意参与者可能造成的潜在危害，如果该参与者扮演这些角色之一

- ORACLES

- 恶意预言机可能提供无效的价格，使其能够借入超过应有的金额，或者基于无效价格进行清算。

- SEQUENCER

- 如4.6节所述，序列器在滚动中的排序上具有重大影响力，使其能够在资产价格大幅下跌时，从Aave的用户中提取大量价值。这可以通过拒绝供应和还款行为，并清算HF低于1的用户来实现，有效地剥夺用户在崩盘中保护自己免于清算的能力。

- FLASH_BORROWER

- 如果该地址是一个代理，它可以允许任何人通过它调用闪电贷以免除所有费用。这将导致闪电贷的流动性提供者没有溢价。

- BRIDGE

- 如果担任此角色的合约/地址变得恶意（或存在缺陷），它可能会增发至不受支持的上限，并永不支持，实际上允许它从流动性提供者那里窃取未支持的资金。

- ASSET_LISTING_ADMIN

- 攻击者可以升级预言机源，使协议处于与恶意预言机相同的状态。或者，攻击者可以列出一个具有恶意aToken（或债务令牌debttoken）实现的资产，允许他们提取存放在该资产中的任何资金。

- RISK_ADMIN

- 攻击者可以将清算门槛降至0并清算用户。这可以在同一交易或捆绑中原子化完成。

- EMERGENCY_ADMIN

- 攻击者可以暂停池，或解除暂停不安全的池。与市场崩溃同时发生时，攻击者可以关闭池，然后原子化地执行序列（开启 清算 关闭），使他成为唯一的清算人。

- POOL_ADMIN

- 攻击者可能执行RISK_ADMIN或ASSET_LISTING_ADMIN的攻击，或更换现有代币实现为只能由攻击者调用的rug()函数的新实现。

- ACL_ADMIN

- 攻击者可以给自己授予其他角色，然后执行其他管理员的攻击。

- ADDRESSES_PROVIDER

- 如果地址提供者的所有者是恶意的，那么治理已经崩溃，游戏结束。

- 上述潜在恶意攻击者的“攻击”的缓解措施应由Aave治理处理。当治理为特定行为者分配角色时，应使用中间件合约限制行为者使用该角色可以执行的操作，例如，对于ASSET LISTING ADMIN拒绝现有预言机提要的更新，仅允许添加。

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:36:32

协议特性

- AAVE v3：协议特性=Protocol Features

- 概述

- Aave协议提供的功能可能仅在选定的网络或市场中可用。下面的指南给出了所有Aave Protocol部署中每个特性可用性的细分。

- Network网络特性

- Market市场特性

- 以抵押品偿还

- 概述

- 抵押偿还功能允许借款人使用协议内提供的流动性偿还其借入的资产。

- 该特性是通过ParaSwapRepayAdapter启用的。用户必须首先批准合同才能提取attoken以成功偿还抵押品。

- https://github.com/aave/aave-v3-periphery/blob/master/contracts/adapters/paraswap/ParaSwapRepayAdapter.sol

- 支持的市场

- V2 Ethereum Main

- V2 Polygon

- V2 Avalanche

- V3 Polygon

- V3 Avalanche

- V3 Fantom

- 抵押物切换

- 概述

- 抵押物切换功能允许用户将一种资产类型的供应流动性切换到另一种资产类型，而无需单独的提取和供应交易(例如，在单个交易中将aUSDC切换到aDAI)。

- 附属开关特性是通过ParaSwapLiquiditySwapAdapter.启用的。用户必须批准合约才能提取attoken，以便成功切换流动性。

- https://github.com/aave/aave-v3-periphery/blob/master/contracts/adapters/paraswap/ParaSwapLiquiditySwapAdapter.sol

- 支持的市场

- AAVE V3的所有的市场

- 用ATokens偿还

- 概述

- 用ATokens偿还是一个新的Aave协议V3原生功能

- 它允许用户用池中相同资产类型的流动性来偿还借来的资产

- 允许用户在基础借款资产被锁定在Aave流动性池的情况下用attoken偿还。

- 示例

- 用户拥有稳定的DAI债务并持有aDAI令牌

- 用aUSDC偿还借来的USDC

- 在这种情况下，用户可以使用aDAI在单笔交易中偿还DAI债务，而无需任何批准，或者必须使用repayWithATokens功能将其提供的流动性撤回到池中。

- 相关代码

import { Contract, utils } from "ethers";

const poolAbi = require("./abis/pool.json");

const pool = new Contract(POOL_ADDRESS, poolAbi, signer);

// repay amount of DAI debt using aDAI tokens

pool.repayWithATokens(DAI.address, amount, 2);

// User must hold aDAI >= amount being repaid

- 支持的市场

- AAVE V3的所有的主网和测试网

- V3 Polygon

- V3 Avalanche

- V3 Fantom

- V3 Harmony

- V3 Optimism

- V3 Arbitrum

- 质押

- 注：现有ave治理V2，已有此功能

- 概述

- AAVE或ABPT持有者可以将其AAVE或ABPT押注在安全模块中，以增强协议偿付能力并获得安全激励。一旦出现短缺事件，最多可以削减30%的代币持有者的股份以弥补赤字，为协议提供额外的风险缓解机制。

- ABPT=Aave Balancer Pool Token

- https://pools.balancer.exchange/#/pool/0xc697051d1c6296c24ae3bcef39aca743861d9a81/about

- 押注选项仅在以太坊主网上可用

- 更多关于质押风险的信息详见

- https://docs.aave.com/faq/migration-and-staking

- 快照投票

- 注：现有ave治理V2，已有此功能

- 概述

- Aave快照空间是一个指定的地方，供选民评估社区对链上投票的情绪，并决定链下提案。对快照提案的投票是通过无气签名完成的，并且与各种资产和链兼容。

- https://snapshot.org/#/aave.eth

- 可以在这里查看可用投票策略的列表

- https://docs.aave.com/developers/getting-started/protocol-feature-summary#network-feature-summary

- 也可以通过此GraphQL端点实时查询

- GraphQL端点

- 链上治理

- 注：现有ave治理V2，已有此功能

- 概述

- Aave治理允许Aave或stkAAVE的持有者投票并提出对协议和治理的更改和/或升级

- 这里更详细地描述了治理过程。

- https://docs.aave.com/governance/

- Aave治理仅在以太坊主网上启用

- 跨链治理桥

- 概述

- 在支持跨链消息传递的链上集成了相对较新的功能。

- 所有对Aave治理提案的投票都在以太坊主网上进行。治理桥可用于将以太坊主网上的提案投票结果用于在其他链上执行提案。

- 这个repo包含了跨链桥的技术实现。

- https://github.com/aave/governance-crosschain-bridges

- 交叉链桥目前在Polygon网络上可用。

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:38:50

Multiple Rewards and Claim

- AAVE协议V3：Multiple Rewards and Claim=多重奖励令牌

- 概述

- Aave协议V3提供了每个令牌有多个奖励的选项。现在，资产列表可以启用以本地协议令牌计价的额外激励。用户也可以在单笔交易中为每个资产申请多种奖励类型。

- 详解

- 在 Aave Protocol V2 中，Aave 治理通过社区提案激活了流动性挖矿奖励。尽管每种资产的奖励发放量不同，但所有奖励均以 stkAave 代币形式发放。Aave Protocol V3 提供了为每种代币设定多种奖励的选项。现在，资产上线可以启用以其协议代币计价的额外激励奖励。

- V3 还允许用户将奖励领取到另一个账户，以及自己的账户，并且在单个交易tx中领取多种类型的资产奖励。

- RewardsController 合约是用户用来领取其头寸奖励的主要合约。用户可以在每笔交易中领取所有奖励或单个奖励，多种功能提供了更细致的领奖选项。

- 相关代码

- RewardsController | v3 | Developers (aave.com)

- https://docs.aave.com/developers/periphery-contracts/rewardscontroller

- 集成指南

- Multiple Rewards and Claim | v3 | Developers (aave.com)

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:40:20

对比

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-28 10:05:52

AAVE vs Compound

- 借贷协议：AAVE对比Compound

- 体量=资金量

- Aave ~= 2.6 倍的 Compound

- Compound：虽是首个提出资金池模式借贷的协议，但是因团队比较保守，业务拓展滞后而导致后续发展乏力

- AAVE：Aave 则是抓住了多链发展的机会，团队具有创新意识进而后来者居上

- 当前 DeFi 借贷领域规模最大的协议

- 去中心化程度

- Compound：不太高

- 创始团队和投资者仍然拥有近 50% 的代币

- AAVE：高很多

- 持有 AAVE 的最大个人地址包含超过 250,000 个代币，占可用供应量的 1.6%。这个极低的百分比确保了真正的民主投票，这意味着没有一个单一的持有者（甚至是持有者群体）可以迅速达到多数来执行他们的意愿

- 风险隔离措施 = 项目安全性

- Compound：更为激进

- 直接降低协议的复杂性，根据基础资产的不同将各个资产池隔离开来

- 意味着 Compound 放弃了部分山寨币作为基础资产的市场份额

- AAVE：更倾向于做大而全的通用借贷协议

- 占更多的市场份额，将新资产与核心资产池隔离，降低新资产作为抵押品的潜在风险

- 风控措施

- 相同：都有储备金

- 作为协议出现债务亏损时的补救手段

- 区别

- Aave：内置安全模块

- 由代币质押者为整个协议安全兜底，不仅为协议代币赋能，且锁住一部分代币的流动性，减少市场通胀

- 代币发行量和流动量

- 发行量

- 相同点：都比较低

- 代币抛压对二级市场的价格影响较小

- 流通量

- Aave：90.5%

- 上线比较早的协议

- 不过安全模块锁住了部分代币的流动性

- Compound：68.6%

- 首创流动性挖矿先河，但是这种方式带来的流动性在参与者获得可观收益时会立即抛售代币，对协议影响较大

- 因此 Compound 改变了流动性激励措施，将代币分发至真实用户手中

- 收入来源

- AAVE：多样化

- 稳定币 GHO 的借款利息也全部归国库所有

- 从财库收入趋势可以看到，自上轮牛市过后，Aave 协议收入锐减，不过当前协议收入是能够覆盖协议支出的

- Aave 协议收入是 Compound 的 4 倍左右

- Compound：单一化 = 来源比较单一

- Compound 仍然需由 COMP 代币奖励补贴

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:40:48

开发相关

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-28 10:05:52

核心的类和代码

- AAVE协议的核心类和代码

- Smart Contract - Aave v3

- Smart Contract - Aave v3 PoolAddressesProvider

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/configuration/PoolAddressesProvider.sol

- Smart Contract - Aave v3 ACLManager

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/configuration/ACLManager.sol

- Smart Contract - Aave v3 Pool

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/pool/Pool.sol

- Smart Contract - Aave v3 L2Pool

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/pool/L2Pool.sol

- Smart Contract - Aave v3 Pool Configurator

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/pool/PoolConfigurator.sol

- Smart Contract - Aave v3 DefaultReserveInterestRateStrategy

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/pool/DefaultReserveInterestRateStrategy.sol

- Smart Contract - Aave v3 Upgradability - BaseImmutableAdminUpgradeabilityProxy

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/aave-upgradeability/BaseImmutableAdminUpgradeabilityProxy.sol

- Smart Contract - Aave v3 Upgradability - InitializableImmutableAdminUpgradabilityProxy

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/aave-upgradeability/InitializableImmutableAdminUpgradeabilityProxy.sol

- Smart Contract - Aave v3 Upgradability - VersionedInitializable

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/aave-upgradeability/VersionedInitializable.sol

- Smart Contract - Aave v3 Global configurations - Reserve Configuration

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/configuration/ReserveConfiguration.sol

- Smart Contract - Aave v3 Global configurations - User Configuration

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/configuration/UserConfiguration.sol

- Logic Libraries

- Smart Contract - Aave v3 Logic Libraries - Borrow Logic

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/logic/BorrowLogic.sol

- Smart Contract - Aave v3 Logic Libraries - Bridge Logic

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/logic/BridgeLogic.sol

- Smart Contract - Aave v3 Logic Libraries - Calldata Logic

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/logic/CalldataLogic.sol

- Smart Contract - Aave v3 Logic Libraries - Configurator Logic

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/logic/ConfiguratorLogic.sol

- Smart Contract - Aave v3 Logic Libraries - EMode Logic

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/logic/EModeLogic.sol

- Smart Contract - Aave v3 Logic Libraries - Flash Loan Logic

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/logic/FlashLoanLogic.sol

- Smart Contract - Aave v3 Logic Libraries - Generic Logic

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/logic/GenericLogic.sol

- Smart Contract - Aave v3 Logic Libraries - Isolation Mode Logic

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/logic/IsolationModeLogic.sol

- Smart Contract - Aave v3 Logic Libraries - Liquidation Logic

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/logic/LiquidationLogic.sol

- Smart Contract - Aave v3 Logic Libraries - Pool Logic

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/logic/PoolLogic.sol

- Smart Contract - Aave v3 Logic Libraries - Reserve Logic

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/logic/ReserveLogic.sol

- Smart Contract - Aave v3 Logic Libraries - Supply Logic

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/logic/SupplyLogic.sol

- Smart Contract - Aave v3 Logic Libraries - Validation Logic

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/logic/ValidationLogic.sol

- Math Libraries

- Smart Contract - Aave v3 Math Libraries - Math Utils

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/math/MathUtils.sol

- Smart Contract - Aave v3 Math Libraries - Percentage Math

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/math/PercentageMath.sol

- Smart Contract - Aave v3 Math Libraries - WadRayMath

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/math/WadRayMath.sol

- Smart Contract - Aave v3 AToken

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/tokenization/AToken.sol

- Smart Contract - Aave v3 VariableDebtToken

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/tokenization/VariableDebtToken.sol

- Smart Contract - Aave v3 StableDebtToken

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/tokenization/StableDebtToken.sol

- Smart Contract - Aave v3 AaveOracle

- https://github.com/aave/aave-v3-core/blob/master/contracts/misc/AaveOracle.sol

- Smart Contract - Aave v3 L2Encoder

- https://github.com/aave/aave-v3-core/blob/master/contracts/misc/L2Encoder.sol

- Smart Contract - Aave v3 Price Oracle Sentinel

- https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/configuration/PriceOracleSentinel.sol

- Smart Contract - Aave v3 Periphery - Rewards Controller

- https://github.com/aave/aave-v3-periphery/blob/master/contracts/rewards/RewardsController.sol

- Smart Contract - Aave v3 Emission Manager

- https://github.com/aave/aave-v3-periphery/blob/master/contracts/rewards/EmissionManager.sol

- Smart Contract - Aave v3 Collector

- https://github.com/bgd-labs/aave-collector-unification/blob/main/src/contracts/Collector.sol

- Smart Contract - Aave v3 GhoOracle

- https://github.com/aave/gho-core/blob/27a86dfe0bcbbef2a1809d2b8eaee7a7ca1a37d5/src/contracts/facilitators/aave/oracle/GhoOracle.sol

- Smart Contract - Aave v3 GhoAToken

- https://github.com/aave/gho-core/blob/27a86dfe0bcbbef2a1809d2b8eaee7a7ca1a37d5/src/contracts/facilitators/aave/tokens/GhoAToken.sol

- Smart Contract - Aave v3 GhoVariableDebtToken

- https://github.com/aave/gho-core/blob/main/src/contracts/facilitators/aave/tokens/GhoVariableDebtToken.sol

- Smart Contract - Aave v3 GhoStableDebtToken

- https://github.com/aave/gho-core/blob/27a86dfe0bcbbef2a1809d2b8eaee7a7ca1a37d5/src/contracts/facilitators/aave/tokens/GhoStableDebtToken.sol

- Smart Contract - Aave v3 GhoInterestRateStrategy

- https://github.com/aave/gho-core/blob/27a86dfe0bcbbef2a1809d2b8eaee7a7ca1a37d5/src/contracts/facilitators/aave/interestStrategy/GhoInterestRateStrategy.sol

- Smart Contract - Aave v3 GhoDiscountRateStrategy

- https://github.com/aave/gho-core/blob/27a86dfe0bcbbef2a1809d2b8eaee7a7ca1a37d5/src/contracts/facilitators/aave/interestStrategy/GhoDiscountRateStrategy.sol

- Smart Contract - Aave Safety Module Staked Aave v3

- https://github.com/bgd-labs/aave-stk-v1-5/blob/main/src/contracts/StakedAaveV3.sol

- Smart Contract - Aave v2

- Smart Contract - Aave v2 LendingPoolAddressProvider

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/configuration/LendingPoolAddressesProvider.sol

- Smart Contract - Aave v2 LendingPool

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/lendingpool/LendingPool.sol

- Smart Contract - Aave v2 LendingPoolCollateralManager

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/lendingpool/LendingPoolCollateralManager.sol

- Smart Contract - Aave v2 DefaultReserveInterestRateStrategy

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/lendingpool/DefaultReserveInterestRateStrategy.sol

- Smart Contract - Aave v2 LendingPoolConfigurator

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/lendingpool/LendingPoolConfigurator.sol

- Smart Contract - Aave v2 BaseImmutableAdminUpgradeabilityProxy

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/libraries/aave-upgradeability/BaseImmutableAdminUpgradeabilityProxy.sol

- Smart Contract - Aave v2 InitializableImmutableAdminUpgradeabilityProxy

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/libraries/aave-upgradeability/InitializableImmutableAdminUpgradeabilityProxy.sol

- Smart Contract - Aave v2 VersionedInitializable

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/libraries/aave-upgradeability/VersionedInitializable.sol

- Smart Contract - Aave v2 Global configurations - Reserve Configuration

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/libraries/configuration/ReserveConfiguration.sol

- Smart Contract - Aave v2 Global configurations - User Configuration

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/libraries/configuration/UserConfiguration.sol

- Smart Contract - Aave v2 Logic libraries - GenericLogic

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/libraries/logic/GenericLogic.sol

- Smart Contract - Aave v2 Logic libraries - ReserveLogic

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/libraries/logic/ReserveLogic.sol

- Smart Contract - Aave v2 Logic libraries - ValidationLogic

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/libraries/logic/ValidationLogic.sol

- Smart Contract - Aave v2 Math libraries - MathUtils

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/libraries/math/MathUtils.sol

- Smart Contract - Aave v2 Math libraries - PercentageMath

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/libraries/math/PercentageMath.sol

- Smart Contract - Aave v2 Math libraries - WadRayMath

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/libraries/math/WadRayMath.sol

- Smart Contract - Aave v2 AToken

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/tokenization/AToken.sol

- Smart Contract - Aave v2 VariableDebtToken

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/tokenization/VariableDebtToken.sol

- Smart Contract - Aave v2 StableDebtToken

- https://github.com/aave/protocol-v2/blob/master/contracts/protocol/tokenization/StableDebtToken.sol

- Smart Contract - Aave v2 Aave Oracle

- https://github.com/aave/protocol-v2/blob/master/contracts/misc/AaveOracle.sol

- Smart Contract - Aave v2 Lending Rate Oracle

- https://etherscan.io/address/0x8A32f49FFbA88aba6EFF96F45D8BD1D4b3f35c7D

- Smart Contract - Aave v2 WrappedTokenGatewayV2

- https://etherscan.io/address/0xEFFC18fC3b7eb8E676dac549E0c693ad50D1Ce31

- Smart Contract - Aave v2 Collector

- https://etherscan.io/address/0x464C71f6c2F760DdA6093dCB91C24c39e5d6e18c

- 其他

- Smart Contract - new Aave Safety Module (stkABPT and stkGHO)

- https://github.com/bgd-labs/stake-token/blob/main/src/contracts/StakeToken.sol

- Smart Contract - GSM

- https://github.com/aave/gho-core/blob/c351f895b4eadde317157c4e456690689c2a4a79/src/contracts/facilitators/gsm/Gsm.sol

- Smart Contract - FixedPriceStrategy

- https://github.com/aave/gho-core/blob/c351f895b4eadde317157c4e456690689c2a4a79/src/contracts/facilitators/gsm/priceStrategy/FixedPriceStrategy.sol

- Smart Contract - FixedFeeStrategy

- https://github.com/aave/gho-core/blob/c351f895b4eadde317157c4e456690689c2a4a79/src/contracts/facilitators/gsm/feeStrategy/FixedFeeStrategy.sol

- Smart Contract - TransparentUpgradeableProxy

- https://github.com/bgd-labs/solidity-utils/blob/7a7548c1d01f011febdb1c0d47e52c7ec6c30f9d/src/contracts/transparent-proxy/TransparentUpgradeableProxy.sol

- Smart Contract - Governance

- https://github.com/bgd-labs/aave-governance-v3/blob/main/src/contracts/Governance.sol

- Smart Contract - VotingStrategy

- https://github.com/bgd-labs/aave-governance-v3/blob/main/src/contracts/voting/VotingStrategy.sol

- Smart Contract - GovernancePowerStrategy

- https://github.com/bgd-labs/aave-governance-v3/blob/main/src/contracts/GovernancePowerStrategy.sol

- Smart Contract - VotingMachine

- https://github.com/bgd-labs/aave-governance-v3/blob/main/src/contracts/voting/VotingMachine.sol

- Smart Contract - DataWarehouse

- https://github.com/bgd-labs/aave-governance-v3/blob/main/src/contracts/voting/DataWarehouse.sol

- Smart Contract - Executor

- https://github.com/bgd-labs/aave-governance-v3/blob/main/src/contracts/payloads/Executor.sol

- Smart Contract - PayloadsController

- https://github.com/bgd-labs/aave-governance-v3/blob/main/src/contracts/payloads/PayloadsController.sol

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:42:40

AAVE V3合约概览

- AAVE协议V3：Contracts Overview=合约概览

- AAVE V3，主要有2个仓库

- aave-v3-core

- 托管核心协议V3合约，其中包含供应，借贷，清算，闪贷，a/s/v令牌，门户portal，pool池配置，预言机和利率策略的逻辑。

- aave-v3-periphery

- 奖励、UI数据提供商、激励数据提供商、钱包余额提供商、WETH网关。

- aave-v3-core 协议合约

- 配置=Configuration

- ACLManager == Access Control List Manager

- Aave协议V3实现了访问控制列表，以隔离可以分配给协议上不同实体的权力和/或利益。角色和持有者在ACLManager中进行管理。它跟踪各个角色及其持有者。

- 详见：https://docs.aave.com/developers/core-contracts/aclmanager

- PoolAddressesProvider

- 协议的主地址寄存器，包含核心协议合约地址和ACL管理地址。它充当代理工厂并管理这些代理。本合同的所有人有权设置/更新可升级合同的执行情况。应该通过进行适当的调用从该合同中检索最新的合同地址。

- 详见：https://docs.aave.com/developers/core-contracts/pooladdressesprovider

- PoolAddressesProviderRegistry

- 包含针对不同市场的活动PoolAddressProvider地址列表。它用于索引所有Aave协议的市场。

- 详见：https://docs.aave.com/developers/core-contracts/pooladdressesproviderregistry

- PriceOracleSentinel

- Oracle Sentinel根据PriceOracle运行状况验证是否允许操作。一旦PriceOracle在中断/停机后重新启动，用户可以在宽限期内保持其头寸健康。

- 详见：https://docs.aave.com/developers/core-contracts/priceoraclesentinel

- 池的逻辑=Pool logic

- DefaultReserveInterestRateStrategy

- 根据储备状态实现利率的计算。本合约包含计算和更新与特定流动性池相关的收益率所需的信息。

- 每个合约使用每个资产的相应参数存储优化的基本曲线。这意味着有一个数学函数决定每个流动性池的收益率，收益率根据借入资金的数量和池的总流动性(即利用率)而变化。

- Pool

- 进入Aave协议的主要入口点。大多数用户与Aave协议的交互都是通过Pool合约进行的。池由特定市场的PoolAddressesProvider拥有。所有管理函数都可以由PoolConfigurator合约调用，该合约在PoolAddressesProvider中定义。

- 详见：https://docs.aave.com/developers/core-contracts/pool

- PoolConfigurator

- 池配置的提供程序配置方法。该合约的写方法只能由ACLManager管理的具有相应权限的系统角色的地址调用。

- 详见：https://docs.aave.com/developers/core-contracts/poolconfigurator

- Tokenization=代币化

- AToken

- 产生收益的代币，在供应和撤回资产时被铸造和燃烧到拥有池

- 详见：https://docs.aave.com/developers/tokens/atoken

- DelegationAwareAToken

- 一种特殊类型的代币，在具有与之相关的投票权(可以委托)的资产的供应和撤回时被铸造和燃烧。

- 详见：https://docs.aave.com/developers/tokens/delegationawareatoken

- StableDebtToken

- 不可转让的计息、稳定利率的代币化借款。

- 详见：https://docs.aave.com/developers/tokens/debttoken

- VariableDebtToken

- 不可转让的计息、可变利率的代币化借款。

- 详见：https://docs.aave.com/developers/tokens/debttoken

- Misc=其他

- AaveOracle

- 合同获取资产价格，管理价格来源并更新备用oracle。

- 详见：https://docs.aave.com/developers/core-contracts/aaveoracle

- AaveProtocolDataProvider

- 外围设备负责从池中收集和预处理信息。

- 详见：https://docs.aave.com/developers/core-contracts/aaveprotocoldataprovider

- aave-v3-periphery 协议合约

- Rewards

- RewardsController

- 该合约负责配置不同的奖励和索赔流程。

- 详见：https://docs.aave.com/developers/getting-started/contracts-overview#rewardscontroller

- Transfer Strategies=转移策略

- 这些是管理索赔时奖励转移程序的孤立合同。这允许RewardsController支持任何自定义奖励，如Staked Aave, 普通的ERC20甚至NFT。

- Misc

- UiIncentiveDataProviderV3

- 获取激励数据的助手合同。它被Aave UI用于奖励余额信息。

- 详见：https://docs.aave.com/developers/getting-started/contracts-overview#uiincentivedataproviderv3

- UiPoolDataProviderV3

- 辅助合约，由Aave UI使用，获取池数据，如储备列表，所有储备数据，如流动性，令牌地址，利率策略等。

- 详见：https://docs.aave.com/developers/getting-started/contracts-overview#uipooldataproviderv3

- WETHGateway

- 只有ERC20令牌可以从Aave协议V3池中提供和借用。为了方便使用链上的原生代币(如以太坊上的ETH或多边形上的Matic)，使用辅助合约来支持单个tx的供应，借贷，偿还和提取。

- 详见：https://docs.aave.com/developers/getting-started/contracts-overview#wethgateway

- WalletBalanceProvider

- 用于获取一个用户地址的多个令牌余额。该合约由Aave后端使用，以减少获取用户余额的区块链调用数量。

- 详见：https://docs.aave.com/developers/getting-started/contracts-overview#walletbalanceprovider

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:44:18

审计报告

- AAVE的审计报告

- AAVE Protocol

- V3.0.1 and V3.0.2

- https://github.com/aave/aave-v3-core/blob/master/audits/23-12-2022_SigmaPrime_AaveV3-0-1.pdf

- https://github.com/aave/aave-v3-core/blob/master/certora/Aave_V3.0.1_Formal_Verification_Report_Dec2022.pdf

- https://github.com/aave/aave-v3-core/blob/master/audits/09-12-2022_PeckShield_AaveV3-0-1.pdf

- https://github.com/bgd-labs/proposal-3.0.2-upgrade/blob/main/audits/19-04-2023_SigmaPrime_AaveV3-0-2.pdf

- V3.0.0

- https://github.com/aave/aave-v3-core/blob/master/audits/27-01-2022_ABDK_AaveV3.pdf

- https://github.com/aave/aave-v3-core/blob/master/audits/27-01-2022_SigmaPrime_AaveV3.pdf

- https://github.com/aave/aave-v3-core/blob/master/certora/Aave_V3_Formal_Verification_Report_Jan2022.pdf

- https://github.com/aave/aave-v3-core/blob/master/audits/14-01-2022_PeckShield_AaveV3.pdf

- https://github.com/aave/aave-v3-core/blob/master/audits/07-01-2022_TrailOfBits_AaveV3.pdf

- https://github.com/aave/aave-v3-core/blob/master/audits/01-11-2021_OpenZeppelin_AaveV3.pdf

- V2

- https://github.com/aave/protocol-v2/tree/master/audits

- Aave Governance

- Governance V3

- https://github.com/bgd-labs/aave-governance-v3/tree/main/security/sp

- https://github.com/bgd-labs/aave-governance-v3/tree/main/security/certora/reports

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:44:50

漏洞赏金

- AAVE 漏洞赏金

- 之前：放Github上的

- aave/bug-bounty (github.com)

- 最新：专业站点

- AAVE Bug Bounties | Immunefi

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:47:20

附录

下面列出相关参考资料。

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-28 09:57:58

名词和术语

名词

含义

备注

reserve=准备金=储备

principal=本金

balance=余额

repayment=偿还（借款）

price fluctuation=价格波动

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:50:33

AAVE资料

- 主页

- Aave - Open Source Liquidity Protocol

- https://aave.com

- Github

- Aave Labs (github.com)

- https://github.com/aave

- 最重要的

- core

- https://github.com/aave/aave-v3-core

- aave/aave-v3-core: This repository contains the core smart contracts of the Aave V3 protocol. (github.com)

- periphery

- https://github.com/aave/aave-v3-periphery

- aave/aave-v3-periphery (github.com)

- 文档

- 总入口

- https://docs.aave.com

- Aave Document Hub

- Aave FAQ

- https://docs.aave.com/faq/

- GHO FAQ

- https://docs.gho.xyz/concepts/faq

- Community Discord

- https://aave.com/discord

- https://discord.com/invite/aave

- GOVERNANCE

- Aavenomics

- https://docs.aave.com/aavenomics/

- Governance Forum

- https://governance.aave.com/

- Governance Guide

- https://docs.aave.com/governance/

- Developer

- Aave Developer Docs

- https://docs.aave.com/developers/

- GHO Developer Docs

- https://docs.gho.xyz/

- Risk

- 入口

- Aave Risk Framework

- https://docs.aave.com/risk/

- Asset Risk

- https://docs.aave.com/risk/asset-risk/introduction

- Interest Rate Model

- https://docs.aave.com/risk/liquidity-risk/borrow-interest-rate

- Liquidity Risk

- https://docs.aave.com/risk/liquidity-risk/introduction

- AAVE 白皮书whitepaper/doc文档技术手册

- Aave_Protocol_Whitepaper_v1_0.pdf

- https://github.com/aave/aave-protocol/blob/master/docs/Aave_Protocol_Whitepaper_v1_0.pdf

- aave-v2-whitepaper.pdf

- https://github.com/aave/protocol-v2/blob/master/aave-v2-whitepaper.pdf

- Aave_V3_Technical_Paper.pdf

- https://github.com/aave/aave-v3-core/blob/master/techpaper/Aave_V3_Technical_Paper.pdf

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:51:41

AAVE发展进化历史

参考这里

贴出内容，供参考：

Aave 拥有超过 56 亿美元的锁定总价值，是 DeFi 最主要的参与者之一。它的野心远远超出了借贷的范围，稳定币和社交媒体也在它的视野之内。

可行性见解

如果你只有几分钟的时间，下面是投资者、经营者和创始人应该了解的 Aave 的情况。

- DeFi 界的领先贷款人。Aave 是去中心化借贷领域事实上的领导者。即使在加密货币低迷的情况下，其完全稀释的市值也在 10 亿美元以上。Aave 拥有 56 亿美元的总价值锁定（TVL），并有望产生 1680 万美元的年化收入。

- 由社区提供动力。Aave 最值得注意的特征之一是其强大的社区。创始人 Stani Kulechov 从一开始就把这个问题放在首位，它投入了大量时间来培养基层支持。这一基础帮助 Aave 从其竞争对手中脱颖而出。

- 一个坚持不懈的创新者。Aave 不是一个坐以待毙的项目。自 2017 年成立以来，它不断增加新的资产、生态系统和产品系列。其结果是一个具有无与伦比的范围和灵活性的综合金融平台。

- 在扩张与专注之间取得平衡。该组织在未来几年的最大挑战可能是弄清楚如何保持专注。今年，Aave 已经宣布了在社交媒体和稳定币领域的两项重要的新举措。虽然很有希望，但它们将是资源密集型的，并带来新的风险赛道。

比尔 - 盖茨曾经说过：「银行业务是必要的，而银行则不是」。Aave 的创始人 Stani Kulechov 可能会同意。他的金融协议也许是加密货币对这种情绪最清晰的表达。自 2017 年成立以来，Aave 已经发展到支持超过 56 亿美元的总价值锁定（TVL），这是一个类似于管理资产的指标。在去年的牛市中，TVL 接近 200 亿美元（即使还有一些没有纳入母公司的较新项目）。Aave 通过构建类似于无银行的银行系统来实现这些数字，这是一个建立在协议上的金融帝国，并由一个热情的社区来推动。

Aave 的雄心壮志与它的资产规模相当。在过去的一年里，Kulechov 的团队提出了一些倡议，暗示了贷款之外的广阔未来，包括过度抵押的稳定币和去中心化的社交图谱。这些项目，以及未来几年出现的其他项目，将在「Aave 公司」的保护伞下，与它最知名的流动性协议一起生存。只有时间会告诉我们，这些企业是分散注意力，还是让 Aave 成为更伟大的东西：一个微型的 Alphabet，一个家庭式的加密货币集团。

在今天的文章中，我们将讨论：

Aave 的演变。从外表上看，Stani Kulechov 看起来是一个不太可能的企业家。这位前法律系学生将一个小型点对点贷款机构转变为 DeFi 的蓝筹项目之一。

关键的教训。Aave 的成功提供了关于 Web3 创业、DeFi 的制度化和活跃社区的力量的教训。

未来会怎样。Aave 正进入其第二步。在解决链上借贷问题后，Kulechov 将目光投向了加密货币的两个最大问题：建立一个可靠的稳定币和解决去中心化的身份。

演变：Aave 的崛起

在其生命的大部分时间里，Aave 是在相对默默无闻的情况下运作的。它的成功在很大程度上归功于 Kulechov 的胆识、项目的创新产品和活跃的支持者基础。

起源

2017 年，一名芬兰法律学生决定进行一次实验。几个月前，在学习争议解决和合同法时，Stani Kulechov 了解了以太坊。当他发现它有可能创建自我执行和强制执行的合同时，他被其中的含义惊呆了。Kulechov 后来回忆说：「这几乎让我大吃一惊」。

Kulechov 被以太坊的可能性所吸引，决定成立一个专注于借贷的小型副业项目。这个想法是，借款人可以把加密货币作为抵押品，然后与贷款人配对。这个点对点（P2P）的过程是建立在以太坊上的，利用其智能合约。Kulechov 称其为 ETHLend。

这并不是 Kulechov 的第一次创业努力。在十几岁的时候，他就表现出令人钦佩的好学精神，在业余时间打造金融技术应用。最引人注目的是为游戏制作者提供的收入融资产品。开发者无需等待 30 至 45 天就能从 App Store 收到付款，而是可以立即得到付款，使他们能够支付成本并发展自己的业务。虽然这是一个很有前途的概念，但 Kulechov 的这个项目失败了。

他预计 ETHLend 也会遵循类似的轨迹。他说：「我从来没有想过要成为一个创业公司创始人，或者做类似的东西。当时我还在大学里学习。」

起初，看起来 Kulechov 会实现他的愿望。在 Reddit 上分享了这个想法后，Kulechov 指出「这个想法本身被完全扼杀了」。很少有人看到像他提出的这种服务的必要性，也没有对它的渴望。然而，不久之后，潮流开始改变。尽管 ETHLend 努力吸引用户使用其服务，但它开始吸引一个爱好者社区。这主要是由于 Kulechov 愿意与加密货币新人接触。他说：「出于某种原因，我虽然不知道为什么，但我感觉它会成为一个更大的项目」。到 2017 年底，ETHLend 进行了首次代币发行（ICO），获得了约 1620 万美元的资金。事后看来，它是在 ICO 热潮中出现的少数几个项目之一，这显示出了它真正的持久力。

ETHLend 的资本注入是在有意义的牵引力之前。鉴于加密货币金融的不成熟性，通过 P2P 程序匹配贷款人和借款人是一个挑战。一位加密货币投资者总结了当时的状况。「最大的挑战是加密货币用户和 DeFi 用户太少，真的很难解决这个鸡生蛋蛋生鸡的问题」。ETHLend 并没有因为加密货币冬天的加深而冻结了对该领域的兴趣。

熊市被证明是 ETHLend 的福音。该项目重新命名为 Aave，并从 P2P 模式转变为集合方式。他们不是直接匹配贷款人和借款人，而是简单地增加或从一个公共池子中添加或提取。Aave 在 2018 年和 2019 年开发了这一战略，在 2020 年初推出了这一池子战略的「V1」。

正是在这个时候，Stani Kulechov 考虑进行一轮风险投资。虽然 ETHLend 已经通过 ICO 筹集了资金，但该项目需要时间来引进正式的合作伙伴。一位投资者回忆说，他对 Kulechov 和他所创建的组织的创造力印象深刻。他们说：「我对 Stani 作为一个企业家有信心。很明显，他们正在以真正明确的方式进行创新。」

虽然 Aave 刚刚开始进入硅谷的生态系统，但其最接近的竞争对手已经锁定了一些最负盛名的名字。2018 年，前 Postmates 产品经理 Robert Leshner 推出了 Compound。与 Aave 一样，Leshner 的创作为链上借贷提供便利。它在 2018 年吸引了 820 万美元的种子资金，并在之后一年获得了 2500 万美元的 A 轮融资。Andreessen Horowitz 参与了这两轮融资，Polychain 和 Bain Capital Ventures 也有贡献。一位消息人士称，由于这些关系，他们被称为该领域的「800 磅大猩猩」。

2020 年，Aave 发展了它的名册，引入了 Standard Crypto、Parafi、Framework、Blockchain Capital 和命运多舛的 Three Arrows Capital。这并不是 Kulechov 当年收到的唯一好消息：12 月，Aave 被加入 Coinbase，为该项目带来了动力。

在此后的几年里，Aave 已经成为 DeFi 市值领先的借贷项目。它目前的市值在 10 亿美元以上，尽管它在 2021 年接近 80 亿美元。对于一个 Kulechov 预计不过是一个 「实验」的项目来说，这样的数字代表了一个了不起的结果。

核心产品

在其最基本的层面上，Aave 是一个简单的产品。在纠结的功能和怪癖之下，Aave 提供了一种简单的借贷方式。它的服务既模仿又颠覆了传统的金融体系。

基本上，它是这样运作的。想象一下，你很幸运地参与了以太坊的 ICO，并拥有 100 个 ETH 供你支配。现在，你可以决定不理会这些资产，希望 ETH 的价格随着时间的推移而升值。不过，理想的情况是，你能从这些 ETH 上赚取利息。

这就是 Aave 的作用。与其让你的资产闲置，你可以把它们存入 Kulechov 的平台，让它们赚取利息。Aave 通过将你的 ETH 出借给借款人来产生这些收益。这种利息以「aTokens」的形式发行，如果你存入 ETH，你将获得 aETH；如果你存入 DAI，你将获得 aDAI。

借款人方面的情况也同样简单明了。想象一下，你想用你的 100ETH 作为抵押品来借入资金。你不会把它放到 Aave 的借贷池中，而是把它作为抵押品提出来。一旦在平台上承诺，你可以随后提取抵押品价值的 80%（在这种情况下相当于 80ETH）。你可以用这些 ETH 来买车，支付房屋的首付，或者进行投资，同时保持你原来的 100ETH 抵押品不动，并随着时间的推移偿还贷款。Aave 围绕还款时间表的灵活性提供固定利率和浮动利率贷款。

你可能会想，为什么有人愿意存入更多资金，只是为了借一个较小的金额。为什么要把 100 个 ETH 作为抵押品，只为了获得相当于 80 个 ETH 的 USDC？其中一个原因是为了保留增长型资产的上升空间。如果你卖掉你的 ETH，你就不能从任何价格升值中获益。通过贷款，你可以获得短期的流动性，但仍然可以从上涨中受益。

使用像 Aave 这样的服务的另一个原因是为了增加自己的杠杆率。投资者可以在抵押品中存入 100ETH，收到 80ETH，在抵押品中存入 80ETH，收到 64ETH，在抵押品中存入 64ETH…以此类推。其结果将是对 ETH 价格的超杠杆投注。在暴涨的情况下，投资者将看到丰厚的回报，但下跌将导致严重的痛苦。

试图与传统金融机构进行任何这些互动将是困难的，甚至是不可能的。许多机构不具备接受加密货币资产作为抵押品的条件；少数机构会要求提供更多的前期信息，并提供更严格的贷款产品。Aave 让任何拥有资产的人都有能力在世界各地近乎即时地进行借贷。

创新之处

Aave 已经成长为 DeFi 贷款的领导者，这在很大程度上要归功于它的创新能力。一些消息来源强调，这是该项目决定性的特征之一，也是它能够从竞争对手中脱颖而出的关键原因。加密货币投资者Étienne Brunet 指出：「Aave 以更快的发货速度超越了 Compound」。他强调了该项目的创新。

回顾 Aave 的工作，它显然是通过将现有的解决方案带到新的领域和开发新的产品而获得成功。今天，Aave 接受七个生态系统的 30 种资产，包括 Fantom、Optimism 和 Avalanche。除了典型的代币，Aave 还提供与「真实世界资产」（RWA）挂钩的资金池。Aave 的 RWA 市场与 Centrifuge（一个将 DeFi 与传统经济联系起来的参与者）共同开发，提供房地产、货运代理、消费者贷款、库存融资等方面的贷款池。

除了扩大其服务的资产和生态系统的范围，Aave 还创造了创新的贷款产品。「闪电贷」也许是最好的例子。通过这个产品，用户可以借到数百万美元的资产，只要他们在同一笔以太坊交易中在几秒钟之内偿还。这听起来可能是一个对客户和供应商都是灾难性的提议，在创纪录的时间内提供灾难，但它有实际用途。一些人依靠闪电贷款来利用交易所之间的代币价格差异赚钱。

其他人则利用在单笔交易中交易抵押品和债务的能力，以避免财务损失或改善贷款条件。例如，设想一个用户存入 ETH 并提取 Tether。如果 ETH 的价格开始暴跌，他们的头寸就会有清算的风险。使用闪电贷，他们可以将他们的抵押品换成 DAI，避免进一步的下跌。同样，如果 Tether 的利率上升，用户可以将他们的债务转换为 DAI，以避免支付更多。Aave 既是这种产品的先驱，也已成为这种互动的事实目的地。

Aave Arc 是一个较新的举措，为机构客户提供「许可的」流动性资金池。与 Aave 的主打服务不同，Arc 的资金池遵守 AML 和 KYC 规则，使其成为大型机构可行的资本目的地。当 Arc 在今年早些时候宣布时，Aave 分享说它已经支持了三十个基金，包括 Bluefire Capital、CoinShares、GSR、Hidden Road 和 Ribbit Capital。

正如我们稍后将讨论的那样，该项目最近的创新已经超越了金融领域，并展示了「Aave 公司」可能成为什么样的一瞥。

牵引力

Aave 不仅拥有高额的市值。Kulechov 和公司已经建立了一个吸引资本和用户的项目。

如前所述，Aave 的总锁定价值被认为是 56 亿美元（虽然从早期的高点下降，但仍足以使其成为 DeFi 的第四大项目），按该指标计算。只有 Maker、Lido 和 Curve 在其智能合约中拥有更多资产。 尽管近几个月 TVL 有所下降，但 Aave 继续扩大活跃用户。该协议在 8 月创下了 36000 人的历史新高，其每年增长 360%。按照 Web2 的标准，这些都是小数字；很多科技化的贷款机构的客户数量达到了数百万。然而，对于加密货币来说，这表明了有形的用户基础。作为比较，Lido（其管理的资产更多）在过去一年中达到了 11400 个用户。Aave 的代币持有者数量也在稳步攀升，在 8 月接近 12 万。一年前，该数字略高于 9 万。

Aave 通过收取贷款费用来赚钱，对使用该项目自身代币的人给予优惠条件。这种商业模式产生了巨大的收入。2021 年 10 月，Aave 产生了 5940 万美元的收入，其中协议拿走了 620 万美元。总收入包括借款人支付的利息，而协议收入则反映了 AAVE 代币持有人所获得的金额。随着交易量在这个加密货币的冬天下降，这些数字已经大大下降。8 月份，Aave 的总收入为 1230 万美元，协议收入为 140 万美元，同比下降了 62.5% 和 57.5%。在更广泛的市场背景下，这样的数字并不令人惊讶。

在这些数字的背景下判断 Aave 的估值是很棘手的。你是关注该项目最初的急剧增长和显著的高峰？还是看它最近的数据？对于一个在 2021 年 1 月至 10 月期间总收入增长超过 2600%，年化收入达到 7.128 亿美元的项目来说，12.3 亿美元的全面摊薄市值看起来很有吸引力。对于一个急剧下降，现在跟踪的总收入为 1680 万美元的项目来说，这听起来很昂贵。

真相介于这两种描述之间，无论人们的最终评价如何，很明显，Aave 是一个真正使用的产品，有能力产生八位数的收入。

教训：Aave 的重要性

Aave 的影响说明了加密货币生态系统的有趣动态。特别是，它显示了企业家在该领域获胜的不同方式，强大社区的超级力量，以及 DeFi 对消费者和企业的吸引力。

不同的获胜方式

在 2020 年，很少有人会押注 Aave 成为 DeFi 的主要贷款人。Compound 被认为是领跑者，它拥有一个更传统的技术领袖掌舵，并拥有一批高知名度的投资者。相比之下，Aave 是由一个欧洲团队创立的，其背景没有那么传统，与硅谷 VC 的联系也很少。

这种并列的情况在整个加密货币生态系统中反复出现。通常情况下，每一个天选之子硅谷玩家，都有一个潦倒的、社区驱动的外来者。Compound 和 Aave 只是这种二元结构的两个例子。Uniswap 和 Sushiswap 也很容易算成这些角色。

Aave 向我们展示了两者都可以发挥作用。进入硅谷并不是成功的先决条件，即使面对拥有这种关系的竞争者。虽然这反映了技术占领世界的超级趋势，但它也揭示了一些关于加密货币的动态。通过向散户开放投资，并提供参与增长和治理的途径，科技权力中心之外的项目可以产生草根动力。

这并不是说更传统的方法不能发挥作用，Uniswap 是加密货币领先的去中心化交易所，尽管 Compound 在市值和 TVL 方面落后于 Aave，但它无疑是一个成功。它目前完全摊薄的市值为 6.25 亿美元，TVL 为 22.5 亿美元。总的年化收入被认为是 2300 万美元。在 2021 年 4 月，即它的高点，Compound 带来了 4680 万美元或 5.616 亿美元的年化收入。虽然它没有跟上 Aave 的步伐，但它是一个能够提出大数字的项目，并拥有自己的优势。例如，一个消息来源强调，Aave 可以从 Compound 的用户体验中学习。此外，尽管 Aave 有更多的活跃用户，但 Compound 有更多的代币持有者，以 19.7 万比 12 万击败了 Aave。

Kulechov 和 Leshner 都创建了令人印象深刻的项目，应该在 DeFi 的发展中发挥重要作用。他们的项目采取了不同的路径来达到这一点。

社区的力量

我们已经谈到了 Aave 的力量是如何来自其社区的，至少是部分。但它是如何发展这种力量的呢？

它似乎在某种程度上源于 Kulechov 的个性和优先事项。在我们的互动中，Kulechov 将自己描述为「热衷于聚集那些想制造对社会产生积极影响的产品的人」。Aave 的强大社区似乎源于这种兴趣。在之前的采访中，Kulechov 指出，他不断与社区打交道。他说：「我每天花无数个小时与人交谈」。在 Aave 的早期，他将带领用户了解加密货币的基本知识，解释什么是钱包，如何购买 ETH。

这些积累的互动帮助他创造了一个不同寻常的参与和热情的运动。AAVE 的治理方法对此有帮助。AAVE 代币的持有者有权提交提案并进行投票，为项目的发展做出切实的贡献。

Aave 最有趣的社区活动之一是 Raave–一系列在世界各地出现的舞蹈派对。上个月，Raavers 可能在波哥大集会；下个月，他们会在柏林。许多人将其描述为他们曾经参加过的最令人印象深刻、最令人愉快的狂欢。如果一家科技公司在娱乐方面花费如此巨大，可能会显得很浪费。然而，对于一个依赖社区参与的项目来说，投资于欢乐的时刻是有道理的。

除了拥有一个参与的社区的直接优势，Aave 还间接受益，特别是在招聘方面。Brunet 形容 Kulechov 是一个「真正有远见的人，能够雇用有使命感的员工」。他补充说，Aave 已经「能够雇用和留住顶级女性人才」——这在加密货币中是罕见的。对于一个追随者不那么热心、足迹较小的项目来说，这种奉献和多样性会更难实现。

与其他领域不同的是，加密货币项目必须播种、发展并不断地吸引社区。如果做得好，它可以成为一种复合的竞争优势。

DeFi 的吸引力和发展

虽然 DeFi 经常与不可持续的产量耕作计划和其他金融诡计联系在一起，但 Aave 说明了其好处。拥有加密货币资产的消费者可以在任何有互联网连接的地方赚取利息和借钱。

贷款是金融系统中的一个重要组成部分。对于消费者和企业来说，获得贷款使许多人能够承担生产性风险，或进行重要的采购，否则他们可能无法做到。对于投资者来说，Aave 创造了一种有吸引力的产品，能提供高收益和可消化的风险。与传统的金融服务相比，Aave 的速度更快，难度更小，也更灵活。

Aave Arc 和 RWA Markets 的出现和发展表明，DeFi 的步调变化可能来自于此。给予机构投资者所需的保障，将有意义的资源委托给生态系统，可以释放出一波资本，让更保守的市场参与者对加密货币越来越放心。当然，这个机会不会没有人争夺。Compound 有一个很好的鲸鱼和机构名册，而像 Maple Finance 这样较新的产品通过专注于这个客户群而滚雪球。与传统金融一样，这是一个有空间容纳多个大赢家的市场，但 Aave 将需要确保它保持其存储借贷速度，以避免落后。

像货运融资这样的「现实世界资产」的循环提供了另一个巨大的增长途径。许多这样的贷款机会很难获得，被昏昏欲睡的现有供应商所主导，而且在财务上具有吸引力。Aave 在这里的举动说明了该行业可能的发展方向，以及加密货币是如何将自己融入到 Web2 行业的。

如果 Aave 能够拥有这些演变（至少在很大程度上）我们完全有理由相信贷款人能够比其最后的高峰期大几个数量级。

未来：一个企业集团的形成

Stani Kulechov 并不满足于仅仅建立世界上最好的借贷平台。他最近的举动显示，他渴望解决加密货币最重要的问题，并逐一解决这些问题。这样做正在改变 Aave 的基本面貌，将其从一套集中的借贷产品转变为更接近于一个企业集团的东西。事实上，当我问 Kulechov，外界对 Aave 的理解往往不到位时，他指出了他的工作范围：

人们往往不知道 Aave 公司（为 Web3 开发软件产品的技术公司）和 Aave 协议之间有什么区别，Aave 协议现在已经去中心化，由 Aave DAO 管理和维护。

越来越多的人认为，「Aave 公司」将成为几个不同计划的母公司。Kulechov 的团队已经挑选了两个新的计划来处理：一个是 Web3 社交图谱，一个是稳定币。

Lens 协议

今年 2 月，一个名为 Lens Protocol 的新账户在推特上发布了一条信息：「有些东西正在绽放….」

Aave 公司「曾称其在下一个大棋」：一个去中心化的社交图。对于一家贷款企业来说，这听起来可能是一个令人惊讶的举动，但那些关注 Kulechov 兴趣的人并不感到震惊。一段时间以来，这位 Aave 创始人已经表达了对社交媒体的兴趣。今年早些时候，Kulechov 因为在推特上发了一个自称是其新的临时 CEO 的笑话而被禁止进入推特。事实上，许多加密货币领域的人认为这很有趣，因为它似乎并不太牵强。 虽然其他玩家也试图建立一个去中心化的社交图谱，但 Lens 是最引人注目的。它在一个加密货币原生框架中复制了现有的传统社交媒体原素和行为。这样一来，新的行为就被解锁了。

Lens 的运作是围绕着 NFT 进行的。当你注册时，你可以创建一个个人资料 NFT。事实上，每个钱包地址都可以拥有几个，并能够将个人资料的管理交给一个小组。这对 DAO 来说特别方便。

Following 某人也会产生一个 NFT。由于每个 NFT 都是独一无二的，它们携带着你何时关注某人的信息，为档案奖励早期支持者或通过这一维度调节内容的可见度提供了可能性。

Lens 支持发布丰富的媒体，包括文章、照片和视频。用户可以购买这些内容，将其添加到「收藏」中，以展示他们的兴趣。对于创作者来说，这代表了一个新的收入来源。这种赞助和自我表达的形式有多受欢迎，还有待观察。

Lens 的转发版本是「 mirror」。这放大了内容，并让放大的账户在其上风口上曝光。那些转发分享另一个账户的帖子的人，在这些帖子被购买时可以获得一定比例的费用。

最后，由于 Lens 是去中心化的，用户可以将他们的社交图谱从一个应用程序移植到另一个。用户真正拥有自己的社交网络，而不是从那些可能在某一天禁止他们使用或人气下降的平台上借用。

到目前为止，Lens 似乎已经有了一个良好的开端。一位 Web3 的联系人说，它是黑客大会上最广泛使用的协议之一，成为任何需要社交图谱的产品的事实选择。新的应用已经出现，包括 Lenster、Refract、Phaver 和 Alps Finance。最近的一篇文章指出，有 65,000 份资料和 300,000 个帖子是用 Lens 制作的。

Lens 也从治理的角度得到了发展。本周早些时候，Kulechov 宣布创建 CultivatorDAO，一个专注于信任和用户安全的集体。该 DAO 旨在透明地和有条件地采取行动。用户和开发者可以决定他们是否希望「打开」Cultivator 的策划和管理。我们的想法是，激活 Cultivator 可以改善你的社交体验，去除机器人和垃圾账户。它可以被其他社区分叉，并根据其需求进行定制。

虽然这对 Lens 是一个有趣的补充，但 CultivatorDAO 提醒我们 Aave 公司正在接受多么大的挑战。Kulechov 不仅希望为社交媒体创建一个新的技术框架，他和他的团队也在建立人力基础设施。他们将如何设法在这两个方面全力以赴地执行？

投资者Étienne Brunet 将此作为 Aave 的风险之一。他指出：「 Aave 有一大堆东西要建，而且有点难以看到 Aave 和 Lens 之间的联系」。Kulechov 将需要确保像 Lens 这样的「登月计划」不会分散 Aave 的核心协议提供的机会。

GHO 稳定币

GHO 与 Aave 的借贷服务的联系是立即可见的。GHO 于今年 7 月提出，是一种与美元挂钩的过度抵押稳定币，在 Aave 协议的范围内运作。

一旦实施，用户将能够通过存入抵押品来铸造 GHO。与 Aave 的其他贷款一样，铸造的 GHO 数量将是所存资产价值的一小部分。当用户收回他们的抵押品或被清算时，他们持有的 GHO 将被烧毁。

涉足稳定币世界是一个危险的提议。Terra 的倒闭吸引了相当多的监管审查，Aave 将希望避免这种情况。这也促使人们对这些资产的设计决策产生了健康的怀疑，这可能需要时间来解决。与 Lens 公司一样，GHO 可能会分散人们的注意力，使 Aave 偏离更直接的增长。

这似乎是一个值得一试的赌注。就其所有的动荡而言，稳定币代表了一个具有相当大上升空间的巨大资产类别。由于 Aave 打算将借入 GHO 所赚取的所有利息导向其 DAO 库房，它也提供了一个新的收入来源。我们也有理由认为这是一个优雅的选择。毕竟，Aave 已经建立了一个巨大的抵押品基础和分布。在这方面，GHO 感觉是 Aave 赢得的力量的自然延伸。在这里获得有意义的份额可以将 Kulechov 的新兴企业集团推进到一定高度。

十年或二十年后的 Aave 会是什么样子？一位消息人士表示，Stani Kulechov 的最终目标可能是建立一个不亚于加密货币版本 Alphabet 的庞大公司。

这种比较一开始没有什么意义，但你越想就越觉得有意义。从产品角度来看，Aave 和 Alphabet 没有任何共同之处。他们不仅在不同的市场，而且在不同的范式中运作。然而，重新审视 Alphabet 的 S-1 文件，可以发现更多基本的相似之处。

拉里 - 佩奇和谢尔盖 - 布林在他们的介绍信中写道：「谷歌不是一家传统的公司。我们不打算成为这样的公司。如果我们在与我们目前的业务相比显得非常投机甚至奇怪的领域下小赌注，请不要惊讶。」

人们可以想象 Stani Kulechov 做出同样的宣称。像 Lens Protocol 这样的举措可能与它的核心业务并不完全一致，但愿意试验、冒险和失败是一个富有创造力的组织的标志。

就目前而言，Aave 公司离 Alphabet 的高度还有一段距离。然而，它显示出许多有希望的特征，表明它可能是一个长期的复合型企业。Aave 不是一个传统的贷款机构。它也并不打算成为一个这样的公司。

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:56:26

参考资料

- 【整理】DeFi借贷协议：AAVE

- 【整理】AAVE借贷协议：核心逻辑和架构

- 【整理】AAVE借贷协议：核心内容和流程

- 【记录】搞懂AAVE借贷协议核心流程

- 【记录】AAVE借贷协议：学习参考

- 【整理】AAVE借贷协议：协议架构概述

- 【整理】AAVE借贷逻辑：deposit=存款

- 【整理】AAVE借贷逻辑：borrow=借款

- 【整理】AAVE借贷逻辑：repay=偿还

- 【整理】AAVE借贷逻辑：redeem=赎回

- 【整理】AAVE借贷逻辑：liquidation=清算

- 【整理】借贷协议AAVE：清算流程

- 【整理】AAVE利率模型：Health Factor=健康因子

- 【整理】AAVE借贷逻辑：Swap borrow rate mode=切换借贷利率模型

- 【整理】AAVE借贷协议：aToken

- 【整理】AAVE借贷协议V2：升级aToken

- 【整理】AAVE借贷协议：代币的作用

- 【整理】AAVE借贷协议：Governance治理

- 【整理】AAVE借贷协议：代币的质押

- 【整理】AAVE借贷协议：Safety Module=安全模块

- 【整理】AAVE借贷协议：Flash Loan=闪电贷

- 【整理】AAVE借贷协议V2：Flash Loan V2

- 【整理】借贷协议AAVE：稳定币GHO

- 【整理】AAVE借贷协议V2：Credit Delegation=信用委托

- 【整理】AAVE借贷协议V2：Debt Tokenization=债务代币化

- 【整理】借贷协议AAVE：利率模型

- 【整理】AAVE利率模型：可变利率vs稳定利率

- 【整理】AAVE利率模型：稳定利率

- 【整理】借贷协议AAVE：Rv0=基础可变借贷利率

- 【整理】AAVE利率模型：Rv=可变借贷利率

- 【整理】AAVE利率模型：Rs=稳定借贷利率

- 【整理】借贷协议AAVE：Rslope1=斜率1

- 【整理】借贷协议AAVE：Rslope2=斜率2

- 【整理】AAVE利率模型：Ro=总体借贷利率

- 【整理】AAVE利率模型：Rsa=平均稳定借贷利率

- 【整理】AAVE利率模型：Rl=当前流动性比例

- 【整理】AAVE利率模型：Bx=PB=用户本金借款余额

- 【整理】AAVE利率模型：Bvcx=VI=用户累计浮动借款指数

- 【整理】AAVE利率模型：Bvc=VIt=累计可变利率借款指数

- 【整理】AAVE利率模型：Dassett=债务总额

- 【整理】AAVE利率模型：VDassett=可变债务代币总额

- 【整理】AAVE利率模型：SDassett=稳定债务代币总额

- 【整理】AAVE利率模型：Lassett=资产的总流动性

- 【整理】AAVE利率模型：Ci=LIt=流动性累计指数

- 【整理】AAVE利率模型：Mr=平均市场借贷利率

- 【整理】AAVE利率模型：Itn=NIt=归一化收入

- 【整理】AAVE借贷协议：LTV=贷款价值

- 【整理】AAVE借贷协议V2：Gas优化和改进

- 【整理】AAVE借贷协议：学习AAVE v3

- 【整理】AAVE协议V3：E-Mode

- 【整理】AAVE协议V3：Isolation Mode

- 【整理】AAVE协议V3：Portal

- 【整理】AAVE协议V3：Risk Management

- 【整理】AAVE协议V3：精细的借款能力控制

- 【整理】AAVE协议V3：Price Oracle Sentinel

- 【整理】AAVE协议V3：Siloed Borrowing

- 【整理】AAVE协议V3：权限和角色管理

- 【整理】AAVE协议V3：协议特性

- 【整理】AAVE协议V3：Multiple Rewards and Claim

- 【整理】借贷协议：AAVE对比Compound

- 【整理】AAVE协议：核心的类和代码

- 【整理】AAVE协议V3：合约概览

- 【整理】AAVE协议：审计报告

- 【整理】AAVE协议：漏洞赏金

- 【整理】AAVE借贷协议 相关资料

- 【记录】AAVE借贷协议：发展进化历史

- 【整理】AAVE借贷协议：白皮书v1

- 【整理】AAVE借贷协议：白皮书v2

- Introduction to Aave * FAQ

- 什么是AAVE？及这个DeFi借贷协议的轻松简介Aave加密_贷款 (sohu.com)

- Aave Document Hub | Hub

- Decentralizing Aave | Aavenomics

- 1inch的AAVE流动性协议 | 1inch Network * DEX市场的领先者

- 干货：蓝筹借贷协议 AAVE 一文讲清楚 * Foresight News

- 2024 年最佳 DeFi 加密货币 (plisio.net)

- Aave * Open Source Liquidity Protocol

- 一文读懂 AAVE——链上借贷的王者 * Foresight News

- Aave (LEND) 价格、走势、市值、市场、交易所、LEND到USD汇率换算 | $1.22 (coinpaprika.com)

- DeFi科普系列之（五）没有中介机构的短期借贷市场：Compound protocol | by Olivia | Cortex Labs | Medium

- 三分钟了解DeFi借贷协议Aave_资讯-odaily

- Aave研究报告（上） — Sk8er (mirror.xyz)

- Dapp-Learning/defi/Aave/contract/readme.md at main · Dapp-Learning-DAO/Dapp-Learning (github.com)

- aave-protocol/docs/Aave_Protocol_Whitepaper_v1_0.pdf at master · aave/aave-protocol (github.com)

- aave-v2-whitepaper.pdf

- Protocol Overview | v2 | Developers (aave.com)

- Introduction | v2 | Developers (aave.com)

- V3 Overview | v3 | Developers (aave.com)

- aave/aave-v3-core: This repository contains the core smart contracts of the Aave V3 protocol. (github.com)

- aave-v3-core/techpaper/Aave_V3_Technical_Paper.pdf at master · aave/aave-v3-core (github.com)

- DeFi基本概念|贷款|抵押物|贷方|借方_网易订阅 (163.com)

- IOSG：DeFi 信用评级协议，让 DeFi 大规模爆发？ - Foresight News

- 借贷新范式—Silo Finance. Silo 是一个新型的 permission-less &… | by Paco | Perpetual Engineering（中文） | Medium

- Security & Audits - Developers (aave.com)

- Introduction to Aave - FAQ

- Aave - Governance Forum

- Aave V3 - Risk

- Introduction - Risk (aave.com)

- Gauntlet

- V3 Overview - Developers (aave.com)

- Glossary - Developers (aave.com)

- 三分钟了解DeFi借贷协议Aave_资讯-odaily

- 什么是AAVE？及这个DeFi借贷协议的轻松简介Aave加密_贷款 (sohu.com)

- Aave 56 亿美元的野心：DeFi、社交与稳定币 - Foresight News

- Aave调研报告 - s3cunda's blog

- Dapp-Learning/defi/Aave/contract/9-LendingPool.md at main · Dapp-Learning-DAO/Dapp-Learning (github.com)

- aave-protocol/docs/Aave_Protocol_Whitepaper_v1_0.pdf at master · aave/aave-protocol (github.com)

- 一文读懂AAVE——“去中心化银行” - PANews (panewslab.com)

- aTokens | v2 | Developers (aave.com)

- 1inch的AAVE流动性协议 | 1inch Network * DEX市场的领先者

- https://github.com/aave/protocol-v2/blob/master/aave-v2-whitepaper.pdf

- protocol-v2/contracts/protocol/tokenization/AToken.sol at ice/mainnet-deployment-03-12-2020 · aave/protocol-v2 (github.com)

- Decentralizing Aave | Aavenomics

- Ecosystem Overview | Aavenomics

- Terminology | Aavenomics

- Safety Module | Aavenomics

- Flash Loans | v2 | Developers (aave.com)

- AAVE v2 * white paper | 登链社区 | 区块链技术社区 (learnblockchain.cn)

- Changes from v1 to v2 | v2 | Developers (aave.com)

- 一文读懂 AAVE——链上借贷的王者 * Foresight News

- Aave Borrowing Rates Upgraded. The Aavengineers have made some sweet… | by Emilio Frangella | Aave Blog | Medium

- Aave 借款利率上调。Aavengineers 做了一些甜蜜的... |由 Emilio Frangella |Aave 博客 |中等 (medium.com)

- The Aave Protocol V2. It’s the moment we’ve all been waiting… | by Stani Kulechov | Aave Blog | Medium

- Borrow Interest Rate | Aave V3 | Risk

- AAVE v2白皮书 | 登链社区 | 区块链技术社区 (learnblockchain.cn)

- AAVE V2 学习笔记 * ripwu's blog (godorz.info)

- 加密货币借贷协议中的清算机制|抵押品_网易订阅 (163.com)

- Introduction | v2 | Developers (aave.com)

- Aave AAVE whitepapers * whitepaper.io

- protocol-v2/aave-v2-whitepaper.pdf at master · aave/protocol-v2 (github.com)

- DeFi 主流借贷的多功能「扩张」 资讯 博链财经 (qianba.com)

- LendingPool | v2 | Developers (aave.com)

- Base stable rate oracle update and improvements in Aave V2 Risk Aave

- AAVE V3 | Fundamentals & Overview | Messari

- Aave V3 (Lending) | Exponential DeFi

- aave-v3-core/audits/09-12-2022_PeckShield_AaveV3-0-1.pdf at master · aave/aave-v3-core (github.com)

- Aave V3 Features | FAQ

- V3 Overview | v3 | Developers (aave.com)

- Efficiency Mode (eMode) | v3 | Developers (aave.com)

- aave-v3-core/techpaper/Aave_V3_Technical_Paper.pdf at master · aave/aave-v3-core (github.com)

- Isolation Mode | v3 | Developers (aave.com)

- Portal | v3 | Developers (aave.com)

- Supply Borrow Caps | v3 | Developers (aave.com)

- Siloed Borrowing | v3 | Developers (aave.com)

- Protocol Features Summary | v3 | Developers (aave.com)

- Repay With aTokens | v3 | Developers (aave.com)

- Multiple Rewards and Claim | v3 | Developers (aave.com)

- 蓝筹 DeFi 新叙事：数据解读 Aave 和 Compound的借贷业务、代币排放与协议收支 * 深潮TechFlow (techflowpost.com)

- 干货：蓝筹借贷协议 AAVE 一文讲清楚 * Foresight News

- AAVE Bug Bounties | Immunefi

- Contracts Overview | v3 | Developers (aave.com)

- BGD. Bug bounties proposal - Governance - Aave

- Aave Proposal: Aave Bug Bounty Program on Immunefi (snapshot.org)

- aave/bug-bounty (github.com)

- bgdlabs (@bgdlabs) / X (twitter.com)

- Aave Protocol (@aaveaave) / X (twitter.com)

- Aave Labs (@aave) / X (twitter.com)

- Aave 56 亿美元的野心：DeFi、社交与稳定币 - Foresight News

crifan.org，使用署名4.0国际(CC BY 4.0)协议发布 all right reserved，powered by Gitbook最后更新： 2024-09-30 09:58:08

Table of Contents

前言

AAVE借贷协议概述

核心逻辑和架构

借贷逻辑

deposit=存款

borrow=借款

repay=偿还

redeem=赎回

liquidation=清算

健康因子Health Factor

Swap borrow rate mode=切换借贷利率模型

子模块

aToken

代币的作用

Governance治理

Safety Module安全模块

Flash Loan闪电贷

稳定币GHO

Credit Delegation信用委托

Debt Tokenization=债务代币化

利率模型

可变利率vs稳定利率

稳定利率

各种参数

版本

AAVE v1

AAVE v2

Gas优化和改进

AAVE v3

E-Mode

Isolation Mode

Portal

Risk Management

权限和角色管理

协议特性

Multiple Rewards and Claim

对比

AAVE vs Compound

开发相关

核心的类和代码

AAVE V3合约概览

审计报告

漏洞赏金

附录

名词和术语

AAVE资料

AAVE发展进化历史

参考资料