Aave 创始人 Stani Kulechov 推出了 Aave V3.8，这是该借贷协议 V3 架构的最新增量版本。Aave 是一个去中心化、非托管的借贷协议——属于去中心化金融领域规模最大的协议之一——用户在其中存入数字资产以赚取收益，并以抵押品进行借贷。此次公告在 X 上的一篇帖子中发布，表明 V3 代码库的开发仍在继续，但完整的技术规格、治理提案和部署时间表尚未公布。

V3.8 的发布确立了什么

Kulechov 的 X 帖子是 V3.8 版本标签首次公开亮相。Aave 的 V3 系列一直是该协议在多链部署中的架构基础，该系列中的每个次要版本增量在历史上都针对特定的风险参数、效率设置或功能模块。对于 V3.8 而言，这些细节尚未在现有文档中得到确认，仅凭版本标签无法判断其范围。

从 V3.x 到 V3.8 的版本递增，表明此次发布是一次迭代升级，而非完整的架构重写。Aave 此前已将 V3 部署到十余个网络，其增量版本曾调整过隔离模式、效率模式（eMode）以及池级别的供应与借款上限等机制。V3.8 是否专门针对这些系统中的某一项，官方发布说明尚未明确。

Aave 的多链布局（近期已扩展至 BNB Chain）意味着任何 V3.8 升级很可能需要在每个网络上分别进行部署并获得治理批准，而非一次统一的协同发布，这是多链 DeFi 协议普遍面临的约束。由于批准是针对各网络的，某一部署上的参数变更不会自动延伸至其他部署，各链上的流动性的提供者和借款人需要持续跟踪各自链上出现的治理提案。

V3.8 可能对协议用户带来哪些变化

潜在的产品层变化

由于尚未发布技术文档，无法确认 V3.8 涉及哪些 Aave 模块。以往的 V3 迭代曾调整过利率策略、预言机配置，以及管理闪电贷和清算阈值的参数。V3.8 中的任何此类变化都将影响借贷成本、抵押品效率以及现有仓位的清算风险状况，但这些具体内容必须来自官方的 Aave 改进提案（AIP），而非仅凭版本标签。

治理与上线流程

Aave 的治理通过链上投票运作，由 AAVE 和 stkAAVE 持有者批准或否决提案。V3.8 规模的协议升级通常需要先在治理论坛上发布正式的 Aave 意见（ARC），随后进行链上快照投票，最后提交可执行提案。根据发布时可获得的信息，这些步骤均未确认已完成或已排期，这使得 V3.8 仍处于信息披露阶段，而非部署阶段。

近期通过 MCP（一种允许 AI 代理连接外部服务的开放标准）将 Aave 支持集成到 MetaMask Agent Wallet 中，这说明了协议的治理行动会对第三方集成产生下游影响，也使 V3.8 的治理时间表对核心 Aave 用户之外的相关方同样重要。

对用户的影响考量

对于活跃的贷款人和借款人而言，实际问题是 V3.8 是否会引入需要仓位迁移、更新授权流程或修订现有抵押品类型风险参数的变化。历史上，调整 eMode 类别或供应上限的 V3 升级曾要求用户重新评估其抵押品策略。在官方迁移指引发布之前，应密切关注现有仓位，以应对最终部署时可能伴随的任何参数变化。

V3.8 推进过程中需要关注的事项

Aave 治理论坛是 V3.8 技术规格在任何链上投票之前发布的主要渠道。如需治理提案，其中将详细列出具体的合约变更、审计机构的签署确认以及激活时间表。读者应将创始人的发布视为信息披露过程的开始，而非部署准备就绪的确认。

部署时间和网络顺序仍未确认。Aave 此前的上线策略是先在流动性较低的市场部署升级，然后再登陆以太坊主网，从而给社区留出在真实条件下观察行为的时间。V3.8 是否遵循这一模式取决于其范围，而范围至今未公布。协议 TVL 及各链的流动性分布可通过 DeFiLlama 的 Aave 协议页面实时跟踪，该页面将反映部署后随之而来的资金流动。

智能合约风险是任何 Aave 升级的基本考量。Aave 代码库在重大部署前会经过正式审计，社区的漏洞赏金计划也持续运行。在 V3.8 的审计报告发布之前，针对与 newly 部署合约版本交互的常规审慎原则仍然适用。治理参与者还应评估 V3.8 是否会与 GHO（通过 Aave 协议发行的稳定币）或 Aave 安全模块（由质押的 AAVE 提供支持）产生交互——这两者本身都带有各自的风险面。随着治理进展的展开，包括市场定价和交易量在内的代币基本面可通过 CoinGecko 的 AAVE 代币页面进行跟踪。

更多细节预计将通过 Aave 的官方治理和沟通渠道陆续公布。