更新内容接下来对更新内容进行详细介绍Isolation ModeAAVE V3 的 Isolation Mode隔离模式 是 V3 版本引入的风险管理功能主要用于安全引入新资产、波动性较大或风险较高的资产作为抵押品同时限制其对整个协议的系统性风险。当一个资产被设置为 Isolated Collateral Asset隔离抵押资产 时它将受到以下约束只能作为唯一抵押品用户一旦启用该资产作为抵押品就不能同时启用其他资产作为抵押品。其他资产仍可 Supply 赚取利息但不能用于借贷了。借贷限制只能借出特定的币种比如稳定币。债务上限整个协议针对该隔离资产有全局债务上限控制风险敞口达到上限后就无法再借更多。举例假设将 PEPE 设为 Isolation Mode 抵押品债务上限为 100 万 USD。用户 Alice 存入 PEPE 后只能借 USDC/USDT 等白名单资产。且当全池 PEPE 孤立债务触及上限后协议不再接受任何以 PEPE 作为抵押品的新借款。在新版本中移除了 Isolation Mode 模块删除IsolationModeLogic库及全部调用点、删除dropReserve/resetIsolationModeTotalDebt两个管理函数、废弃ReserveData.isolationModeTotalDebt存储字段、废弃ReserveConfigurationMap中 4 个相关位域。原有的 Isolation Mode 模块功能整合到 E-Mode 中进行实现在 eMode Category 新增了isolated标志用来表示该类资产是隔离资产。本次更新被移除的变量E-ModeE-ModeEfficiency Mode是 AAVE V3 的资产分类系统将相关性高的资产如稳定币之间、ETH 及其 LSD 衍生品之间归入同一 Category赋予高 LTV最高 97%以提升资金效率。每个 Category 通过collateralBitmap、borrowableBitmap、ltvzeroBitmap三张位图精细控制资产权限。举例假设稳定币 Category 的 id 1将 USDC/USDT/DAI 纳入collateralBitmap和borrowableBitmapLTV 设为 97%。用户存入 USDC 后最高可借出其价值的 97% 的 DAI。E-Mode 整合 Isolation Mode为什么 E-Mode 可以整合实现 Isolation Mode 的功能两者独立运行但有功能重叠Isolation Mode为新资产设置债务上限追踪全局孤立债务超出上限则拒绝借款E-Mode为同类资产设置高 LTV Category通过三张 bitmap 控制抵押品/可借款/零 LTV 范围重叠范围两者都在回答“用户用资产 X 做抵押时能借什么、能借多少”。区别是 Isolation Mode 通过全局债务上限进行约束而 E-Mode 通过 bitmap LTV 限制进行约束。这是 E-Mode 整合 Isolation Mode 功能的核心机制首先在EModeCategory和EModeCategoryBaseConfiguration中新增bool isolated字段将其内化成 E-Mode 的一种类型。当某个 Category 被标记为 isolated 时仅collateralBitmap中的资产可作抵押品其余资产即使有余额也自动适用 LTV0。同时配套新增configureEModeCategoryIsolated和getIsEModeCategoryIsolated两个管理/查询函数。PriceOracleSentinelPriceOracleSentinel是 AAVE 部署在 L2 网络Arbitrum、Optimism 等上的安全组件当 L2 Sequencer 宕机时冻结借款和清算操作防止攻击者利用价格同步滞后套利或恶意清算。举例假设 Arbitrum Sequencer 停机 30 分钟ETH 价格已从 $3000 跌至 $2500但 Arbitrum Oracle 仍显示 $3000。Sentinel 检测到停机后拒绝借款交易阻止攻击者以虚高估值借走 USDC。由于主网Ethereum无 Sequencer 问题PriceOracleSentinel不产生实质保护新版将其从所有执行路径中剔除删除接口文件IPriceOracleSentinel.sol从 4 个参数结构体中移除priceOracleSentinel字段Pool.sol和FlashLoanLogic.sol中不再获取和传入。hasNoCollateralLeft在协议对仓位进行清算后需要回答两个问题被清算的抵押品是否被完全消耗决定是否清除该资产在用户配置中的 collateral 标记用户全部抵押品是否清零决定是否将未还债务记为坏账deficit。在旧版本中这两个值分别通过 underlying 和 USD 的数值来判断随后在 transfer scale 代币AToken时会发生 celi rounding向上取整保护协议利益导致判断的与实际不一致。而新版就统一采用 scale 值来进行判断避免了不一致的情况。旧版本处理流程问题 1 用的是 underlying amount 等值比较actualCollateralToLiquidate liquidationProtocolFeeAmount borrowerCollateralBalance。问题 2 用的是 Base Currency 等值比较totalCollateralInBaseCurrency collateralToLiquidateInBaseCurrency。其中collateralToLiquidateInBaseCurrency来自_calculateAvailableCollateralToLiquidate计算公式为(collateralAmount * price) / unit。两组判断的共同问题是它们都发生在链上实际转账之前而实际转账内部使用rayDivCeil向上取整将 underlying amount 折算为 scaled amount。ceil rounding 可能导致实际消耗的 scaled amount 略大于预估 underlying 对应的 scaled 份额造成预估值与链上实际消耗不一致。举例假设流动性指数 1.3 RAY借款人 scaled balance 1×10¹⁸对应 underlying 1.3 ETH。ETH 价格 $3,000。清算人所得 0.7 ETH协议费 0.6 ETH合计 1.3 ETH恰好等于借款人余额。推导过程getATokenBurnScaledAmount和getATokenTransferScaledAmount的公式都使用rayDivCeil进行向上取整scaled ⌈ underlying × 10^27 / liquidityIndex ⌉分别计算两笔 scaled清算人:⌈ 0.7/1.3 × 10^18 ⌉⌈ 538,461,538,461,538,461.53... ⌉538,461,538,461,538,462协议费:⌈ 0.6/1.3 × 10^18 ⌉⌈ 461,538,461,538,461,538.46... ⌉461,538,461,538,461,539两笔之和:1,000,000,000,000,000,001借款人余额:1,000,000,000,000,000,000差额:1← 各自 ceil 各多出不到 1 单位合计溢出 1这导致旧版本的判断全部通过但转账时会发生 revert。新版本处理流程新版不再基于 underlying 和 USD 进行判断而是将两者换算成链上实际消耗的 scaled amount 后进行判断将清算人所得和协议费两部分各自用rayDivCeil换算成 scaled amount然后加和得到链上实际会消耗的 scaled 总量如果总值超过借款人实际 scaled balance则取实际值reserveFullyConsumed实际 scaled 消耗 借款人全部 scaled balance。从 scaled 维度判断储备是否耗尽consumedInBaseCurrency根据实际 scaled 消耗计算 underlying 数量从而计算出美元价值。最后根据美元价值判断价值是否等于全部抵押品最终条件reserveFullyConsumed || hasNoCollateralLeft任一维度判定清零即执行清零处理。推导过程计算 scaled 消耗:538,461,538,461,538,462 461,538,461,538,461,539 1,000,000,000,000,000,001截断为实际余额:1,000,000,000,000,000,001 1,000,000,000,000,000,000→ 截断为1,000,000,000,000,000,000scaled 判断:1,000,000,000,000,000,000 1,000,000,000,000,000,000→reserveFullyConsumed true基于 scaled 数量反推 USD 价值进行判断:(1,000,000,000,000,000,000 × 1.3/1 × 3000×10^8) / 10^18 390,000,000,000。390,000,000,000 390,000,000,000→hasNoCollateralLeft truereserveFullyConsumed || hasNoCollateralLeft→true→ 正确清零且转账成功。
AAVE V3 v3.7 版本更新：Isolation Mode 被移除，清算流程精度修复
发布时间：2026/7/6 5:04:59
更新内容接下来对更新内容进行详细介绍Isolation ModeAAVE V3 的 Isolation Mode隔离模式 是 V3 版本引入的风险管理功能主要用于安全引入新资产、波动性较大或风险较高的资产作为抵押品同时限制其对整个协议的系统性风险。当一个资产被设置为 Isolated Collateral Asset隔离抵押资产 时它将受到以下约束只能作为唯一抵押品用户一旦启用该资产作为抵押品就不能同时启用其他资产作为抵押品。其他资产仍可 Supply 赚取利息但不能用于借贷了。借贷限制只能借出特定的币种比如稳定币。债务上限整个协议针对该隔离资产有全局债务上限控制风险敞口达到上限后就无法再借更多。举例假设将 PEPE 设为 Isolation Mode 抵押品债务上限为 100 万 USD。用户 Alice 存入 PEPE 后只能借 USDC/USDT 等白名单资产。且当全池 PEPE 孤立债务触及上限后协议不再接受任何以 PEPE 作为抵押品的新借款。在新版本中移除了 Isolation Mode 模块删除IsolationModeLogic库及全部调用点、删除dropReserve/resetIsolationModeTotalDebt两个管理函数、废弃ReserveData.isolationModeTotalDebt存储字段、废弃ReserveConfigurationMap中 4 个相关位域。原有的 Isolation Mode 模块功能整合到 E-Mode 中进行实现在 eMode Category 新增了isolated标志用来表示该类资产是隔离资产。本次更新被移除的变量E-ModeE-ModeEfficiency Mode是 AAVE V3 的资产分类系统将相关性高的资产如稳定币之间、ETH 及其 LSD 衍生品之间归入同一 Category赋予高 LTV最高 97%以提升资金效率。每个 Category 通过collateralBitmap、borrowableBitmap、ltvzeroBitmap三张位图精细控制资产权限。举例假设稳定币 Category 的 id 1将 USDC/USDT/DAI 纳入collateralBitmap和borrowableBitmapLTV 设为 97%。用户存入 USDC 后最高可借出其价值的 97% 的 DAI。E-Mode 整合 Isolation Mode为什么 E-Mode 可以整合实现 Isolation Mode 的功能两者独立运行但有功能重叠Isolation Mode为新资产设置债务上限追踪全局孤立债务超出上限则拒绝借款E-Mode为同类资产设置高 LTV Category通过三张 bitmap 控制抵押品/可借款/零 LTV 范围重叠范围两者都在回答“用户用资产 X 做抵押时能借什么、能借多少”。区别是 Isolation Mode 通过全局债务上限进行约束而 E-Mode 通过 bitmap LTV 限制进行约束。这是 E-Mode 整合 Isolation Mode 功能的核心机制首先在EModeCategory和EModeCategoryBaseConfiguration中新增bool isolated字段将其内化成 E-Mode 的一种类型。当某个 Category 被标记为 isolated 时仅collateralBitmap中的资产可作抵押品其余资产即使有余额也自动适用 LTV0。同时配套新增configureEModeCategoryIsolated和getIsEModeCategoryIsolated两个管理/查询函数。PriceOracleSentinelPriceOracleSentinel是 AAVE 部署在 L2 网络Arbitrum、Optimism 等上的安全组件当 L2 Sequencer 宕机时冻结借款和清算操作防止攻击者利用价格同步滞后套利或恶意清算。举例假设 Arbitrum Sequencer 停机 30 分钟ETH 价格已从 $3000 跌至 $2500但 Arbitrum Oracle 仍显示 $3000。Sentinel 检测到停机后拒绝借款交易阻止攻击者以虚高估值借走 USDC。由于主网Ethereum无 Sequencer 问题PriceOracleSentinel不产生实质保护新版将其从所有执行路径中剔除删除接口文件IPriceOracleSentinel.sol从 4 个参数结构体中移除priceOracleSentinel字段Pool.sol和FlashLoanLogic.sol中不再获取和传入。hasNoCollateralLeft在协议对仓位进行清算后需要回答两个问题被清算的抵押品是否被完全消耗决定是否清除该资产在用户配置中的 collateral 标记用户全部抵押品是否清零决定是否将未还债务记为坏账deficit。在旧版本中这两个值分别通过 underlying 和 USD 的数值来判断随后在 transfer scale 代币AToken时会发生 celi rounding向上取整保护协议利益导致判断的与实际不一致。而新版就统一采用 scale 值来进行判断避免了不一致的情况。旧版本处理流程问题 1 用的是 underlying amount 等值比较actualCollateralToLiquidate liquidationProtocolFeeAmount borrowerCollateralBalance。问题 2 用的是 Base Currency 等值比较totalCollateralInBaseCurrency collateralToLiquidateInBaseCurrency。其中collateralToLiquidateInBaseCurrency来自_calculateAvailableCollateralToLiquidate计算公式为(collateralAmount * price) / unit。两组判断的共同问题是它们都发生在链上实际转账之前而实际转账内部使用rayDivCeil向上取整将 underlying amount 折算为 scaled amount。ceil rounding 可能导致实际消耗的 scaled amount 略大于预估 underlying 对应的 scaled 份额造成预估值与链上实际消耗不一致。举例假设流动性指数 1.3 RAY借款人 scaled balance 1×10¹⁸对应 underlying 1.3 ETH。ETH 价格 $3,000。清算人所得 0.7 ETH协议费 0.6 ETH合计 1.3 ETH恰好等于借款人余额。推导过程getATokenBurnScaledAmount和getATokenTransferScaledAmount的公式都使用rayDivCeil进行向上取整scaled ⌈ underlying × 10^27 / liquidityIndex ⌉分别计算两笔 scaled清算人:⌈ 0.7/1.3 × 10^18 ⌉⌈ 538,461,538,461,538,461.53... ⌉538,461,538,461,538,462协议费:⌈ 0.6/1.3 × 10^18 ⌉⌈ 461,538,461,538,461,538.46... ⌉461,538,461,538,461,539两笔之和:1,000,000,000,000,000,001借款人余额:1,000,000,000,000,000,000差额:1← 各自 ceil 各多出不到 1 单位合计溢出 1这导致旧版本的判断全部通过但转账时会发生 revert。新版本处理流程新版不再基于 underlying 和 USD 进行判断而是将两者换算成链上实际消耗的 scaled amount 后进行判断将清算人所得和协议费两部分各自用rayDivCeil换算成 scaled amount然后加和得到链上实际会消耗的 scaled 总量如果总值超过借款人实际 scaled balance则取实际值reserveFullyConsumed实际 scaled 消耗 借款人全部 scaled balance。从 scaled 维度判断储备是否耗尽consumedInBaseCurrency根据实际 scaled 消耗计算 underlying 数量从而计算出美元价值。最后根据美元价值判断价值是否等于全部抵押品最终条件reserveFullyConsumed || hasNoCollateralLeft任一维度判定清零即执行清零处理。推导过程计算 scaled 消耗:538,461,538,461,538,462 461,538,461,538,461,539 1,000,000,000,000,000,001截断为实际余额:1,000,000,000,000,000,001 1,000,000,000,000,000,000→ 截断为1,000,000,000,000,000,000scaled 判断:1,000,000,000,000,000,000 1,000,000,000,000,000,000→reserveFullyConsumed true基于 scaled 数量反推 USD 价值进行判断:(1,000,000,000,000,000,000 × 1.3/1 × 3000×10^8) / 10^18 390,000,000,000。390,000,000,000 390,000,000,000→hasNoCollateralLeft truereserveFullyConsumed || hasNoCollateralLeft→true→ 正确清零且转账成功。
