AAVE 具有久经考验的治理系统，该治理系统可以充分保障基金的资产安全。

撰文：shew

AAVE 架构

利率计算

AAVE 内使用了借贷协议内最常使用的与资金利用率相关的二阶段的利率曲线模型：

此处的 Utilization Rate 一般会使用 U 字母表示，其计算公式如下:

其中，参数含义如下:

• Total borrowed 该资产总借出数量
• Total supplied 该资产总存入数量

该参数代表当前所有 AAVE 存款的流动性利用率。AAVE 为不同的资金设置了不同的 OptimalUtilization，该利用率代表 AAVE 官方认为当前资产最合适的流动性利用率，我们一般使用 Uoptimal 代表该比率。

当流动性利用率 U<Uoptimal 的情况，具体计算公式如下:

各参数含义如下:

• Rt 当前利用率
• Ut 下的贷款利率
• R0 初始利率
• Ut 当前流动性池利用率
• Uoptimal 最佳利用率
• Rslope1 预设参数

在 U>Uoptimal 的情况下，计算公式如下:

其中，Rslope2 为预设参数。简单来说，二阶段利率模型具有一个特殊性质：在达成流动性池最佳利用率 Optimal 后，借贷利率会迅速上升以避免流动性枯竭。

下图显示了 AAVE V3 中的 DAI 所使用的利率模型：

在 U<92% 的情况下，DAI 的利率受流动性利用率的影响较低。当 U>92% 后，DAI 的利率会快速上升。上述利率计算获得的结果会被直接用于借款，但是存款人无法获得所有的利息。由于 AAVE 存在治理协议，治理协议会拿走一部分存款利率。在 DAI 市场内，AAVE 治理协议会拿走 25% 的利息收入：

这也是 AAVE 给出的 DAI 的存款利率和借款利率不同的原因。

另外，AAVE 在实际利率计算时会进行自动复利，使用的公式如下:

此处 secsperyear 含义为每年的秒数，该数值等 31536000。利率模型计算出的 Rt 经过上述公式计算后就可以获得真实的利率。AAVE 在代币详情页中给出的利率就是复利后的结果，所以在 AAVE 内存入资产并不需要进行复利操作。

清算

虽然只存入资产并不会涉及到清算问题，但考虑到一旦清算出现穿仓是可能影响存款的安全性的，所以本节将简单介绍 AAVE 内的清算机制。

当用户在 AAVE 内借出资产时，我们可以使用以下方法计算该用户的 Health factor:

各参数含义如下:

• Hf 健康因子，即 Health factor
• Collaterali in USD 资产 i 以 USD 计价的价值
• Liquidation Thresholdi 资产 i 对应的清算阈值
• Total Borrows 用户借出的总资产价值 ( 以 USD 计价 )

上述计算公式内的 Liquidation Thresholdi 也可以直接在 AAVE 的资产界面内部获得。

此处在计算资产的美元价值时会使用不同的预言机，几乎所有资产的价格都来自 Chainlink 预言机。

当借款人的 Health factor 小于 1 时，清算会被启动。清算人会首先帮助借款人还款，还款后会获得借款人的担保品。清算的具体规则如下:

1. 当贷款的 Health factor 小于 1 时，清算启动，但此时清算人只能最多清算 50% 的借款
2. 当贷款的 Health factor 小于 0.95 时，清算人可以清算贷款人 100% 的借款

我们可以使用以下数学公式表示:

其中，各参数含义如下:

• debtToCover 代表可偿还贷款金额
• userDebt 代表被清算人的浮动利率贷款金额
• Hf 健康因子，即 Health factor

清算者在一次清算过程中，清算者需要首先选择要清算的担保品，然后可以通过以下公式计算最大可清算担保品的数量:

其中，各参数含义如下:

• maxAmountOfCollateralToLiquidate 最大可清算质押品数量
• debtAssetPrice 贷出资产的价值
• debtToCover 可偿还贷款金额
• liquidationBonus 等于 1 - Liquidation penalty
• collateralPrice 担保品的价值

经过简单的数学推导，我们可以得到清算人在清算过程中获得清算奖励:

与其他协议相比，AAVE 作为以太坊内部最大的借贷协议，拥有最多的专业清算者。下图数据来自 MEV 数据统计平台 Eigenphi（https://eigenphi.io/mev/ethereum/liquidation）。

治理

作为一个强治理的借贷协议，我们需要额外关注 AAVE 的治理情况。和其他协议类似，AAVE 有一个用于治理的论坛、链下投票和链上投票三部分构成。治理流程如下:

众所周知，借贷协议内加入新资产是一个危险行为。AAVE 为此专门资助了两家风险评估机构为所有的新资产加入服务。这些机构包括

• ChaosLabs
• LlamaRisk

ChaosLabs 是 AAVE 的最重要的风险评估机构，该机构会对代币的情况进行分析并且给出相关的 AAVE 配置参数。下图就是 ChaosLabs 对 weETH 的参数推荐:

而 LlamaRisk 是 最近 加入 AAVE 进行风险评估工作的，该组织擅长稳定币、 LST 代币和 LSR 代币的风险评估。

除此外，AAVE 社区内存在 ACI 组织给出了 ACI Skyward 方案帮助用户参与 AAVE 的治理。该方案会全流程帮助用户参与治理提案并最终实现链上投票。

当然，上述治理最终还是需要投票进行链上执行。下图展示了链上治理的全流程:

每一个提案都有对应的 Payload 合约，该合约内部会编写该提案所进行的链上操作。AAVE 的合作伙伴 BGDLabs 会在 aave-proposals-v3 仓库内为提案编写相应的代码。

当 Payload 合约编写完成后，提案人会调用 AAVE 内的 PayloadsController 将 Payload 合约注册到 AAVE 治理系统内部。Payload 的注册是无许可的，任何人都可以创建 Payload。至此就完成了提案创建的所有准备工作。上图中的 Payload was created 就是 Payload 的注册步骤。

当 Payload 注册完成后，我们可以使用 Payload 创建提案，使用 Payload 创建提案的过程并不是无许可，提案创建者被要求具有一定的治理权。在 AAVE 内，AAVE 代币、stkAAVE（质押在协议安全模块中的 AAVE）代币和 aAAVE（代表提供给以太坊 V3 市场的 AAVE）代币持有者都有与其在以太坊主网上的余额总和成正比的治理权力。该治理权被分为：

• 用于创建提案的提案权 (proposal power)
• 用于投票赞成或者否决提案的投票权 (voting power)

代币持有者可以将自己的提案权和投票权一起或者分开委托给其他用户。

在提案创建时，AAVE 要求提案创建者自身的 proposal power 满足一定条件。提案创建完成后，等待 coolDownBeforeVotingStart ( 目前为 1 天 ) 长度的时间后，提案会进入激活状态，此时提案就可以被投票。

假如存在恶意提案，在 coolDownBeforeVotingStart 期间内，Governance Emergency Guardian 是可以直接取消提案的。目前，Governance Emergency Guardian 是一个 5 of 9 multi-signature wallet。

AAVE 目前并不会在以太坊主网内对提案进行投票，而是会在另一条链内进行投票，一般为 Polygon。选择在非主网的网络进行投票的目的是为了降低投票的 gas 消耗。目前，AAVE 治理协议选择使用 Layerzero 激活不同网络内的提案。上图中的 Proposal #233 was activated for voting 和 Voting started for proposal #233 就是 Layerzero 在两条链触发的提案激活。

由于提案会在其他网络内被投票，所以我们也需要将以太坊内部的投票权信息跨链发送到 Polygon 网络。此处 AAVE 开发者选择了 storage proof 的技术方案。该技术方案的本质是将以太坊的状态根 (state root) 快照后发送到 Polygon 网络。投票者自己使用快照的 state root 生成投票权的 merkle 树证明。下图中的 votingBalanceProofs.proof 就是当前投票者为本次投票提供的 Merkle 树包含性证明。

Dune 内的 Aave DAO Governance v3 Delegations 展示了当前 AAVE 系统内的投票委托情况。

当 Polygon 内部的投票结束后，Layerzero 合约会将投票结果发送回 AAVE 部署在主网内的合约，该合约会根据是否满足最小赞同票数的阈值以及赞成和反对之间的票数差异确定提案是否通过。

上图显示了 AAVE 投票时所使用的技术基础设施。该设施包括 a.DI 用于跨链，目前使用的是基于 Layerzero 的方案，其他的合约主要用于票数权重计算等工作。

假如提案被投票通过，AAVE 主网内的治理合约会将该提案对应的 Payload 转发给 PayloadsController 合约。但是 Payload 不会立即执行而是处于时间锁状态。此处假如发现 Payload 存在问题，Governance Emergency Guardian 也可以取消提案的执行。

在上文内，我们没有介绍提案的等级问题，在真实的 AAVE 治理系统内存在 2 种等级的提案，这些提案对应的操作范围不同。

当 Payload 的锁定期结束后，任何用户都可以调用函数执行 Payload 内的合约。

下图展示了 AAVE 内部的提案的完整生命周期：

更加详细的关于 AAVE 治理的技术细节，可以参考 AAVE 治理系统的开发者 BgdLabs 编写的 文档