交易所
交易所排行榜
24小时成交排行榜
人气排行榜
交易所比特币余额
交易所资产透明度证明
资金费率
资金费率热力图
爆仓数据
清算最大痛点
多空比
大户多空比
币安/欧易/火币大户多空比
Bitfinex杠杆多空比
ETF追踪
比特币持币公司
加密资产反转
以太坊储备
HyperLiquid钱包分析
Hyperliquid鲸鱼监控
索拉纳ETF
大额转账
链上异动
比特币回报率
稳定币市值
期权分析
新闻
文章
财经日历
专题
钱包
合约计算器
账号安全
资讯收藏
自选币种
我的关注
AAVE在DeFi借贷竞争进入精细化阶段之际，Aave再次选择从“底层重构”而非简单调参入手。面对V3阶段逐渐显现的流动性分散与清算效率问题，Aave V4通过Hub+Spoke的新架构打通多资产流动性，同时引入更清晰的份额会计与动态清算逻辑，让风险控制与资本效率同步升级。这一轮升级，标志着Aave正从单一借贷市场，进化为可扩展、可组合的DeFi借贷基础设施。
从「市场」为中心的V3，到流动性割裂的现实约束
在Aave V3中，协议采用的是一种以「市场」为核心的部署方式。在不同网络，甚至同一网络内，Aave会划分出多个彼此独立的市场，例如以太坊主网中的Core与Prime。每一个市场都拥有完全独立的流动性池、支持的资产组合以及对应的风险参数，从而形成各自不同的风险画像。
当用户向Aave V3供应资产时，实际上是将资产明确地存入某一个特定市场，而不是进入一个全局共享的资金池。这意味着，供应到Ethereum Core市场的资产，只能被该市场内的借款人使用，无法被Prime市场或其他网络的用户调用。
这种设计在风险隔离上具有明显优势，不同市场之间不会相互传导风险，但代价同样清晰：流动性被切割。即便是同一种资产，也会被分散在多个市场之中，难以统一调度，进而影响整体的资金利用效率、市场深度以及新功能的扩展能力。
Hub and Spoke：Aave V4的流动性重组逻辑
Aave V4对这一问题的回应，是对底层架构进行根本性重构，引入被称为Hub and Spoke(轮辐式)的新架构。这一设计的出发点，正是为了解决V3中长期存在的流动性割裂与扩展受限问题。
在V4中，协议不再将流动性绑定在单一市场之内，而是在每一条网络上引入一个统一的流动性Hub，作为所有资金的中心来源。用户供应的资产不再进入某一个具体市场，而是统一存入该网络对应的Hub，由Hub负责全局的流动性管理和核心会计约束，例如确保系统内借出的资产总量不超过已供应规模，并记录不同模块对流动性的占用情况。
但Hub并不是用户直接交互的对象。所有用户可感知的操作入口，被放置在一层高度模块化的功能单元中，在V4中被称为Spoke。
Spoke：风险被局部化的模块化入口
Spoke构成了Aave V4中用户实际接触协议的前台层。每一个Spoke都连接到同一个流动性Hub，但可以拥有完全不同的规则、参数与风险假设。Spoke在本地管理用户头寸、抵押品结构、预言机接入以及清算逻辑，而Hub只在后台向其提供受限额度内的流动性支持。
这种分工的核心意义在于：风险被严格限制在Spoke内部，而不会在系统层面扩散。不同类型资产、不同行为模式的借贷需求，不再被迫共享同一套风险参数，而是可以在共享流动性的前提下，实现风险逻辑的分离。
也正因如此，许多在V3中已经存在、但实现上相对笨重的功能，在V4中可以以更自然的形式落地。例如，E-Mode不再只是某组参数配置，而可以作为一个独立的Spoke存在，专门服务于高度相关的资产组合;隔离模式同样可以通过专用Spoke实现，并由Hub对其可用流动性设定明确上限。对于RWA或更复杂的抵押结构，V4也允许通过定制化Spoke引入更严格的访问控制和风险规则，而无需将这些复杂性扩散到整个协议。
统一流动性的账，V4是怎么算清楚的?
为了支撑Hub层统一流动性，V4在会计模型上放弃了aToken rebase，转向ERC-4626风格份额体系。
在Aave V4中，协议摒弃了以往aToken的重新基准机制，转而采用ERC-4626风格的份额会计制度。这意味着用户不再持有会随着利息累积自动增加数量的aToken，而是持有固定数量的份额(shares)，每一份份额对应的底层资产价值会随时间增长。换句话说，利息不再通过代币数量的变化体现，而是通过每份份额可以兑换的资产数量变化呈现，这种方式更接近传统金库(vault)的会计逻辑。
这种份额模型与V4的统一流动性设计紧密相关。在V4架构下，所有供应资产都汇集到链上的流动性Hub，而Hub使用份额系统精确记录全局资产状态。Hub不需要关注每一个Spoke的具体借贷策略或风险模式，只需管理总资产规模、总份额数量以及各Spoke已占用的额度。这种设计使得同一个资产池可以被多个Spoke共享，同时在会计上保持清晰、可控，避免了传统aToken rebase在多模块环境下可能出现的复杂性和风险外溢。
如果继续沿用aToken的rebase机制，不同Spoke共享同一资产时将面临指数同步困难、利息和风险外溢、以及对子模块额度限制难以精确控制的问题。而ERC-4626风格的份额模型将这些潜在问题转化为简单的算术关系，使得Hub可以在统一流动性的前提下，安全、可控地支持多种借贷策略和风险配置。这不仅保证了资本效率，也为V4架构的模块化和未来扩展提供了基础。
清算机制的精细化调整：摆脱固定比例清算
在流动性结构重构之外，Aave V4还对清算机制进行了重要调整。与此前以固定比例为核心的清算逻辑不同，V4引入的是一个以风险目标为导向的清算引擎。
在V3及更早版本中，一旦用户头寸的健康因子跌破安全阈值，协议允许清算者按照预设的close factor偿还一定比例的债务，并相应没收抵押品。这种方式在保护协议安全方面行之有效，但在波动剧烈或风险边缘的情况下，往往会导致过度清算，即清算规模明显超过恢复头寸安全所必需的程度。
V4的新清算引擎则将重点从「清算比例」转向「安全目标」。当头寸进入可清算状态时，系统会计算出只需偿还多少债务、处置多少抵押品，才能将健康因子恢复到安全区间。清算不再以最大化风险切除为目标，而是追求最小必要清算，在不牺牲协议安全性的前提下，尽可能减少对用户资产的侵蚀。
这一变化意味着close factor从一个静态参数，演变为由头寸风险状况动态决定的结果。清算规模会随资产波动性、抵押结构和风险参数变化，使清算机制更真实地反映不同头寸之间的风险差异，也有助于降低清算冲击和无谓的资产抛售。
Aave清算机制的更新，很容易让人联想到Fluid的清算设计。从借贷产品本身来看，Aave V4的确显著改善了原本「一刀切」的清算方式，使清算逻辑更精细、更贴近风险实际。
但与将借贷与DEX流动性深度整合的Fluid相比，Aave仍然处在不同的设计范式之中。Fluid通过将借贷头寸直接嵌入交易流动性，使部分风险可以在池内被自动吸收，从而在很多情况下无需引入外部清算人即可完成头寸调整。这种设计在成本结构和执行效率上具备明显优势，而依赖外部第三方清算者的Aave，即便在清算逻辑上实现了精细化，也难以在这一维度上完全对标。
小结
整体来看，Aave V4并不是对现有模型的推翻，而是一条相对克制但系统性的进化路径：通过Hub and Spoke架构重组流动性，通过模块化Spoke实现风险局部化，再辅以更精细的清算引擎，Aave正在从一个以「市场」为单位扩展的借贷协议，演变为一个可承载更复杂金融结构的模块化借贷基础设施。
