Lido 质押金库 (stVaults)：技术设计与架构

免责声明！ 这不是产品规范或目标文档——尽管这些内容会简要提及以供参考。详细的技术参考资料将在 stVaults 文档中心中提供。

1. 摘要

Lido Staking Vaults (stVaults) 是模块化的原语，连接了质押者、节点运营商和协议——使他们能够定义自定义费用结构、调整验证者配置并微调风险/回报。这种灵活性在不损害去中心化、安全性或 $stETH$ 流动性访问的前提下得以实现。

2. 设计

2.1 目标

stVaults 的设计目标是：

1. 为流动性质押提供可定制的风险-回报配置，同时保持 $stETH$ 的稳定性和可替代性。
2. 提高与希望引入客户并积极参与 Lido 协议的节点运营商的协同性。
3. 支持结构化质押产品和更深层次协议集成的开发。

这些目标建立在 Hasu 的第二份 GOOSE 投票通过提案中概述的愿景之上，为多样化的质押产品线奠定了基础。

2.2 原则

stVaults 的引入对现有 Lido 核心池协议合约（下称 Lido Core）带来了重大改变。为确保协议的稳定性，定义以下不变的基础约束至关重要：

1. stVaults 用户不会对 $stETH$ 用户产生负面影响： a. stVaults 不会对 $stETH$ 用户的 $APR$ 产生负面影响 b. 罚没风险后果被控制在质押 Vault 的节点运营商组内，上限由 $DAO$ 同意
2. stVaults 有一个固定的准备金率，它决定了根据所提供的 $ETH$ 可以铸造的 $stETH$ 数量，并且只能由 $DAO$ 更改
3. 在 Lido Core 和 stVaults 之间可能重新分配质押的影响是可控且可管理的
4. $stETH$ 偿付能力 - 所有现有 $stETH$ 都可以以 $1:1$ 的比例转换为 $ETH$

因此，维护 Lido Core 和整个 Lido 质押基础设施的稳定性和安全性仍然是关键优先事项。

3. 架构

Lido Vaults 平台包含以下合约：

• StakingVault：管理单个质押头寸并持有验证者资产。
• VaultHub：作为 Vault 平台和 Lido Core 之间的中央注册和协调点。
• LazyOracle：验证来自预言机网络的报告，并将单个 Vault 更新转发到 VaultHub。
• OperatorGrid：维护节点运营商注册表并管理 Vault 的铸币参数。
• PredepositGuarantee：确保验证者存款安全。
• VaultFactory：部署经过验证的（允许连接到 VaultHub）Vault 实例。
• Dashboard：一个可选合约，提供节点运营商费用核算和 StakingVault 的用户友好界面。

3.1 StakingVault

StakingVault 合约是一个 $0\text{x}02$ 类型提款凭证目标，也是 Lido Vaults 平台的基本组成部分。它代表了一个由单个 所有者 管理并由单个 节点运营商 提供服务的独立质押头寸。当连接到 Lido 时，该 Vault 可以用作铸造 $stETH$ 的抵押品。

通过 StakingVault，所有者可以：

• 直接将资金质押给其首选节点运营商，而无需放弃托管权；
• 利用各种区块提议和验证方式；
• 铸造由 StakingVault 总价值支持的 $stETH$；以及
• 通过集成协议和风险策展者来构建结构化产品。

质押 Vault 是一个有效的 $0\text{x}02$ 类型提款凭证目标，并支持 EIP-7251。任何 $0\text{x}01$ 或 $0\text{x}02$ 类型的验证者都可以通过执行层整合请求将其余额转移到 Vault 验证者。$0\text{x}00$ 类型的验证者必须首先迁移到 $0\text{x}01$ 类型凭证。

Vault 实体

所有者

所有者是 Vault 中拥有最大权限的管理账户。所有者可以：

• 向 Vault 注入以太币，
• 从 Vault 提取以太币，
• 暂停和恢复信标链存款，
• 请求验证者退出，
• 触发 EIP-7002 验证者提款，
• 更改存款人，
• 不可逆地固定 Vault 实现以选择退出代理升级，
• 通过 两步所有权模型 将所有权转移给另一个账户。

当 Vault 连接到 Lido 协议时，VaultHub 被设置为 Vault 的技术所有者，充当一个中间层，强制执行抵押品锁定以保护针对该 Vault 铸造的 $stETH$。Vault 的实际所有者记录在 VaultHub 内部。一旦链接被移除，VaultHub 将释放控制权并恢复所有权给该记录的所有者，从而保持其非托管性质。

节点运营商

节点运营商地址代表运行与 Vault 相关联的验证者的实体。该地址在 Vault 初始化时设置，不能更改。

强烈建议使用多重签名账户（例如 Gnosis Safe）以避免失去对该账户的访问权限。

由于验证者提款凭证硬编码到 Vault（$0\text{x}02$ 类型指向合约），所有共识奖励和已退出余额都会自动流入 StakingVault；运营商绝不会保管 $ETH$。

节点运营商：

• 应根据所有者发出的信号执行验证者的自愿退出。
• 可以通过 EIP-7002 强制驱逐与 Vault 关联的验证者。

存款人

存款人地址是唯一被允许向信标链存款的方，消耗的是 Vault 中暂存的余额。由于抢跑漏洞（参见 3.6：PredepositGuarantee），此职责被提取为一个由 Vault 所有者控制的单独角色。当连接到 Lido 协议时，存款人必须设置为 PredepositGuarantee，这是一个专门用于缓解存款抢跑的合约。

暂存余额

暂存余额是一种机制，仅作为 PredepositGuarantee 合约完整证明存款流程的一部分使用。

Vault 存款人控制 Vault 的 暂存余额 计数器，该计数器为验证者激活保留 $ETH$，并且不能被提取。取消暂存 $ETH$ 将使这部分 $ETH$ 再次可供提取。这种暂存机制确保了 Vault 激活验证者的承诺。暂存强制执行了一个严格的不变量：每 $1 ETH$ 的预存款必须与为激活而暂存的 $31 ETH$ 配对。这保证了验证者总是可以被补充到所需的 $32 ETH$，这是验证者激活的最低余额。如果没有这个规则，一个 Vault 可能会产生许多 $1 ETH$ 的验证者，这些验证者永远不会激活，从而使资金锁定在信标链上，无法用于协议义务。

StakingVault 源代码：https://github.com/lidofinance/core/blob/feat/vaults/contracts/0.8.25/vaults/StakingVault.sol

3.2 VaultHub

VaultHub 是 Lido Vaults 平台的中央协调合约。它维护连接的 StakingVaults 的注册表，强制执行抵押品约束，根据每个 Vault 的总价值铸造/销毁 $stETH$，并跟踪 Vault 的义务。

当一个 StakingVault 连接到 VaultHub 时，后者：

• （通过两步模式）承担该 Vault 的技术所有权并托管 CONNECT_DEPOSIT ($1 ETH$)；
• 记录由 OperatorGrid 提供的静态连接参数（份额限制、准备金率、费用）；
• 使用来自 LazyOracle 的报告跟踪动态状态（总价值、锁定 $ETH$、负债份额、义务——已累计费用和赎回（如果适用））；并且
• 为 Vault 所有者提供一个控制界面，用于充值、提款、铸造、销毁、再平衡、暂停信标链存款、请求验证者退出和清算义务。 Vault 所有者：
• 通过 VaultHub 保留对底层 StakingVault 的所有权；
• 被授权进行充值、提款、铸造、销毁、管理验证者和清算义务；
• 可以在不断开 Vault 连接的情况下将实际所有权转移给另一个所有者。

图表。VaultHub 交互

VaultHub 源代码：https://github.com/lidofinance/core/blob/feat/vaults/contracts/0.8.25/vaults/VaultHub.sol

Vault 核算

每个 StakingVault 有两个重要的参数来定义其状态：总价值 和 锁定。

• 总价值：Vault 所有验证者余额的总估计值，加上 Vault 合约本身持有的任何 $ETH$。
• 锁定：该 Vault 中 阻止 提款的 $ETH$ 数量。此数量支持通过此 stVault 铸造的 $stETH$ 代币。

为了控制 $stETH$ 铸造，VaultHub 为每个 stVault 跟踪以下参数：

• 负债：针对该 Vault 铸造的 $stETH$ 份额数量（即对 Lido Core 的负债）。
• 准备金率 ($RR$)：Vault 总价值中作为铸造 $stETH$ 额外准备金（安全缓冲）的一部分（例如，如果准备金率为 $30\%$，总价值为 $100 ETH$，则必须保留 $30 ETH$，这意味着该 Vault 最多可以铸造 $70 stETH$）。
• 强制再平衡阈值 ($FRT$)：当准备金低于此阈值时，该 Vault 被视为不健康并受到 强制再平衡。$FRT$ 始终小于或等于 $RR$。
• 份额限制：stVault 可以铸造的 $stETH$ 份额的绝对上限。
• 义务：健康义务、$stETH$ 赎回请求和 Lido 费用。

如果 Vault 的锁定金额突破 $FRT$，则 Vault 被视为不健康：

• 不能铸造 $stETH$、提取 $ETH$、存入新的验证者，并且限制部分验证者提款，
• 并受到无需许可的强制再平衡。

总价值计算 感谢 Pectra 的 EIP-6110 和 PredepositGuarantee，有效的待处理存款会计入 totalValue，这使得无缝铸造无需等待入场队列清算存款。

图表。Vault 总价值分解

流动性

与 Lido Core 以 $1:1$ 的比例铸造 $stETH$ 与提供的以太币不同，Lido Vaults 以更保守的比例铸造 $stETH$。较低的比例实际上意味着 StakingVault 必须保持由风险参数和限制决定的准备金率（储备金率 或 $RR$）。

铸造 $stETH$ 后，相应数量的以太币（加上由于 $RR$ 而产生的一些准备金）将作为抵押品 锁定 在 StakingVault 上，即无法提取。系统会跟踪为每个 StakingVault 铸造的 stETH 份额 (liabilityShares)，并根据 $stETH$ 再平衡更新 StakingVault 上的 locked 金额（以以太币计价）。要解锁以太币进行提款，StakingVault 必须销毁未偿付的 $stETH$ 金额（即偿还 $stETH$）。

示例

给定：

• 准备金率：$20\%$ ($2000 BP$)
• 强制再平衡阈值：$15\%$ ($1500 BP$)

阶段 1 - 初始状态（健康）：

• 总价值：$100 ETH$
• 负债：$0 stETH$
• 准备金：$100 ETH$（$100\%$ 的总价值已保留 $> FRT 15\%$）
• 状态：可铸造

阶段 2 - 初始状态（健康）：

• 总价值：$100 ETH$
• 负债：$80 stETH$
• 准备金：$20 ETH$（$20\%$ 的总价值已保留 $> FRT 15\%$）
• 状态：健康但无法再铸造

阶段 3 - 罚没：

• 总价值降至：$90 ETH$
• 负债：$80 ETH$
• 准备金：$10 ETH$（$11.1\%$ 的总价值已保留 $< FRT 15\%$）
• 状态：不健康，受到强制再平衡

锁定

锁定金额是 Vault 中无法提取的总 $ETH$。它代表支持 Vault 的 $stETH$ 负债和准备金的抵押品。这个锁定金额确保了 Vault 保持超额抵押，并且可以吸收罚款而不会立即产生坏账。锁定金额由 stETH 负债 和 准备金 组成，即 locked = liability + reserve。准备金本身是根据准备金率计算的准备金和最低准备金中较大者得出的。

最低准备金是无论存在多少负债，必须锁定在 Vault 中的抵押品的绝对下限。最低准备金是作为 连接存款 和 罚没准备金 中较大者计算得出的。

• $1 ETH$ 连接存款。Vault 创建至少需要 $1 ETH$ 存在于连接 Vault 的余额中。这种强制性连接存款作为一种反女巫机制，防止创建会给预言机网络带来负担的垃圾 Vault。VaultHub 在连接 Vault 之前验证 Vault 余额中是否有足够的 $ETH$，并在设置期间锁定这笔存款，在 Vault 连接 VaultHub 的整个期间保持锁定，并可能用于支付 Lido 费用。连接存款不能用于铸造 $stETH$。
• 罚没准备金。适用于节点运营商的 Vault，其验证者正在遭受罚没——这笔额外的 $ETH$ 必须保持锁定状态，以防罚没，直到预言机证明 Vault 的验证者不再面临因信标链 相关罚没机制 而受到额外惩罚的风险。预言机在链下计算准备金（基于验证者集、风险时间和检测到的任何可罚没违规行为），并在每份报告中发布该数字。当报告应用时，VaultHub 至少将这笔准备金锁定在 Vault 中，直到验证者被清除且没有额外的关联惩罚。

因此，锁定 的最终计算如下：locked = liability + max(calculatedReserveFromRR, max(connectDeposit, slashingReserve))。

图表。锁定金额分解

Vault 义务

义务是 StakingVault 欠 Lido 协议的所有记录，因此，它会以未决义务的金额阻止 Vault 余额。VaultHub 跟踪三种类型的义务。

1. 健康义务

健康义务以 $stETH$ 份额计价，是必须强制再平衡以恢复 Vault 健康的负债份额数量。当抵押品因验证者罚款、罚没或与 $stETH$ $APR$ 相比表现不佳而低于健康阈值时，健康义务会自动产生。健康义务对其他所有义务具有最高结算优先级。

强制再平衡是一项惩罚性操作，因此强烈建议在接近 $FRT$ 时通过偿还 $stETH$ 或为 Vault 注入资金等更有效的方式恢复健康。

2. 赎回

赎回以 $stETH$ 份额计价，代表必须再平衡或销毁的负债金额，以支持 Lido Core 提款。在 Lido Core 池耗尽且需要流动性以满足其提款队列的罕见情况下，协议保留向符合条件的 Vault 发出赎回义务的权利，该义务应通过再平衡或销毁份额来解决。赎回结算会冲销 Vault 相应负债金额，并向核心池提供 $ETH$ 以处理提款。赎回具有第二优先级，这意味着协议首先恢复 Vault 的健康，然后才清算任何赎回。

已发行的赎回不会增加Vault 的负债。赎回可以被认为是 Vault 现有负债的一部分，必须被销毁或再平衡。

3. Lido 费用

以 $ETH$ 计价的 Lido 费用——包括 基础设施、流动性 和 预留 费用——是 Lido 协议的服务费。这些费用在每次预言机报告时持续累计，报告提供更新的累计费用计数器。VaultHub 跟踪已结算费用计数器，因此，累计费用和已结算费用之间的差额被视为 未结算费用。Lido 费用具有最低优先级，即仅在 Vault 健康且没有分配赎回时才结算。Lido 费用通过 VaultHub 中的专用功能以无需许可的方式结算。

Vault 上的任何未清义务：

• 限制 Vault 的提款，金额为支付义务所需的金额；
• 减少铸造能力，金额为支付义务所需的金额；
• 当 Vault 不健康、有待支付的赎回或未结算费用大于 $1 ETH$ 时，暂停信标链存款。这种暂停阻止 Vault 持续向共识层存款，从而避免义务结算；
• 拒绝断开与 VaultHub 连接的尝试。

义务速查表

义务	优先级	以…计价	描述	累计	结算
健康	1	$stETH$ 份额	恢复 Vault 健康所需的负债减少量	健康状况下降时自动产生	再平衡。强烈建议在接近 $FRT$ 前销毁 $stETH$ 或为 Vault 注入资金，以避免惩罚性强制再平衡
赎回	2	$stETH$ 份额	为服务 Lido Core 提款所需的负债减少量	在 Lido Core 流动性极度短缺时由 $DAO$ 分配	再平衡或销毁份额
Lido 费用	3	$ETH$	Lido 协议服务费	每次报告时持续累计	手动无需许可，断开连接时自动

坏账

准备金率确保 Vault 铸造的 $stETH$ 超额抵押。当 Vault 跌破强制再平衡阈值时，应进行再平衡以恢复抵押率。然而，在严重的群体罚没事件中，Vault 总价值可能跌破 $1:1$ 的比例，这意味着 Vault 的总价值无法完全覆盖未偿付的 $stETH$ 负债。这就是坏账。

坏账通过升级路径解决：

1. Vault 补充：自愿存入额外资金以弥补债务
2. 坏账社会化：由 $DAO$ 发起，将未覆盖的负债转移到同一节点运营商运营的其他 Vault。接受 Vault 必须有足够的容量来吸收额外负债，而不会突破自身的健康阈值。这使得运营商对其所有 Vault 负责，而不是孤立损失
3. 自我覆盖应用：由 $DAO$ 发起保险或覆盖应用机制
4. 坏账内部化：作为最后的手段，Lido $DAO$ 能够核销 Vault 剩余的坏账，并通过减少 $stETH$ 代币再平衡来接受协议损失。

3.3 LazyOracle

LazyOracle 是一个处理 Lido Vault 记账报告的合约。LazyOracle 从 AccountingOracle（为整个 Lido 协议报告）接收每日快照。这种“惰性预言机”机制有效地处理了数千个独立 Vault 的状态更新。与其在单次交易中更新每个 Vault 的状态——这在 gas 成本方面将是极其昂贵的——系统使用基于 Merkle 树的方法，其中只有表示全局状态的根哈希由 AccountingOracle 作为主要记账协议报告的一部分每天存储和更新。

单个 Vault 的更新是按需进行的，通过提供 Merkle 证明来验证特定 Vault 的数据与存储的根哈希。当 Vault 的数据需要更新时，任何人都可以提交证明以及 Vault 的最新数据。系统会根据 Merkle 根哈希验证此数据，如果有效，则更新 Vault 的状态并将相关信息转发到 StakingVault 合约。

报告新鲜度

每个依赖于 Vault 总价值准确性的 Vault 操作都受到新鲜度检查的限制。单个 Vault 报告仅在其时间戳与 LazyOracle 发布的最新全局报告检查点匹配 并且 自该检查点以来经过的时间少于 $2$ 天时才被视为新鲜。如果情况并非如此，则 Vault 被视为陈旧。如果报告陈旧，Vault 所有者无法：

• 从 Vault 提取 $ETH$，
• 铸造针对 Vault 的 $stETH$，
• 重新平衡 Vault，
• 存款到信标链，或
• 从 Vault hub 断开连接。

因此，陈旧状态将 Vault 密封在保守状态，直到提交新的报告，确保抵押品计算绝不会在过时数据上进行。

隔离区

隔离区是 LazyOracle 对 Vault 报告价值突然跳跃施加的时间锁，因为它无法立即在链上确认。如果报告的总价值超出正常例行 EL/CL 奖励，超额部分不会立即反映在总价值中。相反，超额部分被推入隔离缓冲区并忽略预定义的时间；只有在该延迟之后，隔离价值才会被释放到 VaultHub 的总价值中。如果在隔离期内发生另一次跳跃，则初始金额将在当前隔离期结束时释放，并且新超额的累积金额将进入在第一个隔离期结束后立即开始的新隔离期。

这种时间锁机制为协议提供了检查突然增长并在必要时发出警报的时间。

正常的充值——所有者首先将以太币存入 Vault 合约——绝不会通过隔离区。因为这笔以太币在 Vault 余额上是可见的，所以增加可以在链上验证，因此被视为安全。实际上，这意味着直接注资会立即反映在总价值中。

除了一些健全性检查外，隔离区是相对运作的，因此总价值的突然跳跃可能会在一个小 Vault 中被隔离，但相同数量的增长可能不会在一个总价值很大的 Vault 中受到隔离。

3.4 OperatorGrid

OperatorGrid 合约控制连接到 Lido 协议的 Vault 的铸币参数。其主要目的是将 Vault 组织成不同层级的组，并具有特定的 $stETH$ 铸币限制，同时确保任何单一节点运营商都不会处理过多的 $stETH$。

一个 组 代表一个节点运营商。每个组都有一个 shareLimit，用于限制该运营商所有 Vault 可以铸造的 $stETH$ 份额总数。一个组包含一个或多个层级。组会跟踪其负债份额（所有该组 Vault 铸造的份额总数）。

重要！ OperatorGrid 中的节点运营商地址与 StakingVault 合约中设置的节点运营商地址相同。此地址具有关键权限。失去对该地址的访问意味着失去管理 Vault 配置以及与 Vault 所有者协调参数更改的能力。因此，强烈建议节点运营商使用多重签名账户。

一个 层级 代表一组铸币参数。每个层级都属于一个特定的节点运营商组（默认层级除外）。每个层级都有其份额限制、准备金率、强制再平衡阈值和 Lido 费用。层级会跟踪其负债份额（该层级 Vault 铸造的份额总数）。

OperatorGrid 源代码：https://github.com/lidofinance/core/blob/feat/vaults/contracts/0.8.25/vaults/OperatorGrid.sol

默认层级

所有 Vault 都从默认层级开始。默认层级没有特定的节点运营商组。它的 $stETH$ 铸币限制在初始化时定义。默认层级的 Vault 不会计入任何运营商组的负债。当 Vault 从默认层级移动到运营商层级时，其份额会添加到该运营商的组负债中。

即使 Vault 节点运营商有注册组，新 Vault 也会被放置在默认层级。Vault 可以更改其层级，这必须由 Vault 所有者和节点运营商双方确认。断开连接后，Vault 会回到默认层级。

层级参数

每个层级定义了控制 Vault $stETH$ 铸币能力的关键参数：

• 份额限制：该层级所有 Vault 可以铸造的 $stETH$ 份额数量，
• 准备金率：每铸造一个 $stETH$ 必须预留多少 $ETH$，
• 强制再平衡阈值：用于强制再平衡的阈值，
• Lido 费用：向 Lido 财库收取的费用百分比。

这些参数在 Vault 连接或更改层级时传播到 VaultHub。

图表。一个具有 $100k$ 限制和三个层级的示例组

层级变更流程

层级更改通过多重确认操作（参见 Dashboard，多重确认）执行：Vault 所有者和相应的节点运营商必须在彼此设定的时间范围内独立提交匹配的层级更改，无论顺序如何。每次确认都会存储在链上，如果未及时完成则会自动过期，并且可以无副作用地重新提交。一旦第二笔交易到达，合约会从旧层级将 Vault 的负债重新分配到新层级，更新组和层级份额计数器，并且——如果 Vault 已经连接——将新的铸币参数直接推送到 VaultHub。

Lido 费用

OperatorGrid 配置了三种类型的 Lido 费用（以基点表示）：基础设施费（补偿协议运营成本）、流动性费（针对 $stETH$ 流动性收取）和 预留费（涵盖按需流动性）。费用在创建层级时在层级级别设置，并且可以由 $DAO$ 全局针对整个层级或单独针对特定 Vault 进行更新。

个人 Vault 参数

Vault 可以拥有与其层级不同的个人参数：

• 份额限制：Vault 所有者和节点运营商可以共同调整 Vault 的份额限制，独立于层级的份额限制（但不超过），
• Lido 费用：$DAO$ 可以更新单个 Vault 费用（基础设施、流动性、预留），使其与层级费率不同。

这些参数可以通过所有者和节点运营商双方通过同步层级方法相互确认来恢复。

惩戒

OperatorGrid 可以对 Vault 进行 惩戒 作为一种保护措施。惩戒机制的主要目的是防止有问题的 Vault 进一步铸造。

• 在惩戒期间，Vault 不能铸造 新的 $stETH$ 份额。
• 惩戒不影响销毁或其他管理操作；
• 惩戒可以由 $DAO$ 设置或清除。
• 解除惩戒后，正常的铸币操作将恢复，但仍受制于通常的层级和组限制。

3.5 VaultFactory

VaultFactory 合约提供了一种流畅的、单笔交易的方式来创建和配置带有 Dashboard 的 StakingVault。关键是，VaultHub 只接受由该工厂部署的 Vault。任何其他方式部署的 Vault 都将被拒绝。这确保了 Vault 合约代码经过验证，并且其存储未被恶意篡改。

工厂执行以下操作：

• 部署一个 StakingVault，
• 部署一个 Dashboard，
• 使用指定的参数初始化这两个合约，
• 可选地配置 Dashboard 的初始权限，
• 并且，在所有者发起的流程中，在注资连接存款后将 Vault 连接到 VaultHub。

工厂支持两种创建 StakingVault 的方式：

1. Vault 所有者发起的流程 创建 Vault 和 Dashboard，自动为 $1 ETH$ 连接存款 注资并连接到 VaultHub。该函数接受 Vault 所有者子角色的可选角色分配列表。
2. 节点运营商发起的流程 创建 Vault 和 Dashboard，并可选地分配由运营商管理的子角色，但不连接到 VaultHub。Vault 所有者随后为连接存款注资并连接到 VaultHub。

3.6 PredepositGuarantee

为了防止 存款抢跑漏洞，StakingVault 强制执行预存款和验证机制。节点运营商不能直接将支持 $stETH$ 的锁定资产存入信标链。相反，他们必须使用 PredepositGuarantee (PDG) 合约，该合约要求节点运营商发布匹配的担保金额。

通过 PDG，节点运营商进行 $1 ETH$ 预存款并锁定等额担保。同时，PDG（作为 Vault 的存款人）为每个验证者暂存 $31 ETH$ 在 Vault 上，保留激活 $ETH$。为了验证验证者，必须提供使用 EIP-4788 信标区块根的正确提款凭证证明。正向证明（验证者 WC 与 Vault 匹配）解锁担保。只有在验证后，验证者才能使用暂存资金完全激活。负向证明会没收节点运营商的担保，作为对 Vault 的补偿。

💡 对于未锁定且未支持任何 $stETH$ 的 $ETH$，Vault 所有者可以选择简化的“PDG 快捷方式”流程，该流程绕过了担保要求。这种更简单的方法假定 Vault 所有者和节点运营商之间存在信任（可能由链下协议支持）。在此流程中，PDG 可以直接证明和激活验证者，但任何恶意抢跑只会影响 Vault 所有者。

图表。节点运营商存款快乐路径

stVault 验证者存款的完整流程如下：

1. 节点运营商在 PDG 合约中锁定 $1 ETH$ 担保。
2. 节点运营商通过 PDG 提交从 Vault 存款 $1 ETH$。同时，PDG 为激活暂存 $31 ETH$。
3. 一旦验证者出现在信标链上，节点运营商通过 PDG 证明有效的提款凭证。这会解锁 $1 ETH$ 担保。
4. 暂存的 $31 ETH$ 加上可选的额外金额被存入以激活验证者。
5. 如果验证者的提款凭证被证明无效，PDG 会用从运营商担保中取出的 $1 ETH$ 补偿 Vault，并释放暂存的 $31 ETH$ 回到 Vault 的可用余额。

图表。已证明的验证者存款流程

重要须知！

• 节点运营商担保可以来自专门的担保人账户（信任运营商的账户）。
• $1 ETH$ 担保 始终保留在 PDG 中；只有 Vault 的 $ETH$ 才会发送到信标存款合约。
• 连接时，VaultHub 强制 Vault 中的所有预存款都有足够的暂存余额。
• StakingVault 支持 Pectra 的 EIP-7251 MAX_EB，因此预存款 + 激活流程适用于 $32 ETH$ 和多 $ETH$（高达 $2048$）验证者。
• PDG 中的大多数步骤都可以批量处理，包括一条快速路径，可以在一次调用中证明、激活和充值多个验证者。
• 节点运营商可以在预存款期间附加其 PDG 余额。
• 一旦验证者预存款被发送，它就会出现在信标存款队列中。提款凭证证明只能在验证者在共识状态中最终确定后才能生成。

节点运营商的存款人

为了操作灵活性，节点运营商可以指定一个专用的 存款人 地址（不要与 StakingVault.depositor 混淆），该地址被授权代表该运营商通过 PDG 执行存款（包括预存款和激活）。存款人角色可以随时由运营商替换，而不会影响现有余额或担保。如果未分配，存款人默认为运营商地址。

值得注意的是，VaultHub 强制所有已连接的 Vault 将 PDG 设置为 Vault 中的 存款人，而 PDG 本身则验证调用者是否与运营商指定的存款人匹配。这种分离允许安全的验证者签名操作，同时保持管理密钥离线。

链上 BLS12-381 签名验证

预存款操作必须包含有效的 $BLS12-381$ 签名，才能通过 EIP-2537 中引入的预编译在链上进行验证。这就是为什么交易还必须携带必要的签名转换数据。签名验证至关重要——它确保预存款是合法的存款，并且具有指定 pubkey 的验证者最终将出现在共识层。这将使得能够为验证者及其提款凭证生成存在证明。

已证明的验证者充值不需要有效的 $BLS$ 签名，只有预存款需要。

证明未知验证者

Lido 协议支持直接向存款合约存款以及针对与 Vault 关联的验证者进行验证者整合。为了处理此类情况，PDG 包含一种特殊方法，用于证明“侧面”或“整合”验证者的提款凭证——这些验证者要么绕过了标准预存款流程，要么后来合并到 Vault 的验证者集中。

此方法允许这些验证者在 PDG 中清除，而无需经过预存款流程。然而，这些验证者的余额不计入 Vault 的 totalValue，直到通过预言机报告确认。

重要！ 只有已在信标链上激活的验证者才能向 PDG 证明。待处理的验证者将被拒绝，因为它们尚未符合 EIP-7002 提款条件，并且在激活之前无法强制退出。

图表。向 PDG 证明未知验证者

PredepositGuarantee 源代码：https://github.com/lidofinance/core/blob/predeposit-guardian/contracts/0.8.25/vaults/predeposit_guarantee/PredepositGuarantee.sol

3.7 Dashboard

Dashboard 是 StakingVault 的一个实用扩展，处理以下事务：

• 对 StakingVault 操作的细粒度基于角色的访问控制，
• 节点运营商费用的管理和支付，
• PDG 预存款绕过，
• 用户友好的方法和各种代币辅助功能。

尽管技术上是可选的，但 Dashboard 强烈建议用于 StakingVaults 更简单的操作管理。没有 Dashboard，Lido 的网络界面和 CLI 工具将无法运行。选择不使用 Dashboard 的 Vault 所有者应具备底层合约的强大技术知识，并准备通过原始交易调用来管理其 Vault。对于大多数用户来说，Dashboard 提供了基本的质量改进，极大地降低了管理验证者和 $stETH$ 铸币操作的复杂性。

架构

StakingVault 是一个最小的质押原语，只管理即时质押操作并跟踪其 totalValue 和锁定的以太币。它实现了一个简单的单所有者模型。Dashboard 是可选的，并且在 VaultHub 之上运行，即它在 VaultHub 中被记录为 Vault 的所有者，而实际的 Vault 所有者成为 Dashboard 合约的管理员。

图表。Dashboard 访问控制模型

角色

使用 Dashboard，StakingVault 中的每个操作都需要相应的角色。例如，向 StakingVault 注资需要发送者拥有 FUND_ROLE。所有这些角色都有其 角色管理员。

图表。角色受限操作

重要须知！

• Dashboard 合约包含批量授予和批量撤销角色的功能；
• 某些操作（如再平衡）如果交易中附带以太币且发送者拥有 FUND_ROLE，则可以预先注资。

多角色确认

多角色确认机制限制了一些管理操作，从而防止单方面决策。这意味着每个所需角色的成员必须在可配置的持续时间（生命周期）内发送具有相同参数的交易，但无论顺序如何。

图表。多角色确认流程示例

节点运营商费用

StakingVault 有意不包含任何额外费用（例如，节点运营商费用、奖励份额）的核算，以允许在不同设置中具有灵活性。相反，此逻辑已在 Dashboard 中实现，并留有配置空间。Dashboard 包含节点运营商管理角色，该角色授予代表节点运营商利益的地址，并且可以与 Vault 中设置的节点运营商地址不同。

费用核算采用高水位线方法，计算方式如下：

• 将 增长 定义为 Vault 总价值中非明确注资的部分：

  growth = totalValue – inOutDelta

• 将 已结算增长 保持为已收取给运营商（已支付）或明确豁免（例如，无担保/侧面存款、整合）的增长部分的高水位线。

因此，费用基数是：

• unsettled = max(growth – settledGrowth, 0)

费用是：

• fee = unsettled \times feeRate

如果 unsettled 为零或负数，则 settled growth 保持不变，不产生费用。

费用支付

费用以无需许可的方式支付（异常高额费用除外）。支付流程：

1. 读取最新的 Vault 报告，
2. 计算 unsettled 增长和费用，
3. 将 已结算增长 更新为当前增长（因此相同的金额不会再次收取），
4. 从 Vault 的可用余额中向配置的接收方支付费用。

自愿断开连接时，费用会首先自动支付，然后才进行断开连接。

异常高额费用

为了防止由于配置错误/过时的已结算增长导致过高支付，Dashboard 强制执行一个 异常高额费用阈值。

• 如果费用超过 Vault 总价值的 $1\%$，则正常的无需许可支付将被阻止。
• 在这种情况下，只有 Vault 所有者（DEFAULT_ADMIN_ROLE）可以执行单独的管理员功能进行支付。
• 这要求管理员在允许支付之前明确验证已结算增长是否正确。

$1\%$ 的阈值是非常保守的：如果 $APR$ 约为 $5\%$，即使运营商费用为 $10\%$，如果费用从未支付，Vault 也需要大约 $2$ 年才能达到阈值。

费用变更

更改费率需要双重确认（管理员 + 节点运营商经理）和几项安全检查：

• 最新报告必须新鲜（以便核算最新），
• 任何近期对已结算增长的豁免/更正必须在该报告之前记录（防止追溯收费），
• Vault 不得处于隔离状态（确保报告的总价值未减少并完全反映任何豁免）。

PDG 策略

Dashboard 强制执行由管理员配置的 PDG 策略：

• STRICT (严格)

所有验证者资金必须通过完整的预存款和证明流程。

• ALLOW_PROVE (允许证明)

节点运营商可以证明不通过标准流程（例如，侧面存款）的验证者，以便它们有资格通过 PDG 进行未来的充值。

• ALLOW_DEPOSIT_AND_PROVE (允许存款和证明)

节点运营商可以 (a) 执行无担保存款——从 Vault 中提取 $ETH$ 并直接存入信标合约，绕过担保/签名检查——和 (b) 随后向 PDG 证明这些验证者。此快捷方式假定 Vault 所有者和运营商之间存在信任。

无担保存款

Dashboard 合约为节点运营商提供了一个快捷流程，允许他们执行绕过标准 PDG 预存款流程的存款——具体来说，跳过 $1 ETH$ 担保要求和 $BLS$ 签名验证。此路径旨在用于 Vault 所有者信任节点运营商不会抢跑存款，或者存在正式法律协议管理安排的情况。

这些 无担保存款 是通过从 Vault（不包括锁定部分）提取 $ETH$ 并直接向以太坊存款合约存款来执行的，而无需通过 PDG 路由交易。因此，Vault 的 totalValue 会因存款金额而减少，协议不承担与存款相关的任何风险。

此快捷流程通过更新已结算增长自动调整 Vault 的节点运营商费用核算。相关的验证者不计入奖励计算，因此节点运营商只收到实际获得的奖励——而不是完整验证者余额的份额。一旦验证者激活，其提款凭证可以使用 PDG 的“未知验证者”证明方法进行证明。证明后，验证者可以通过标准 PDG 流程接收充值存款。

图表。PDG 快捷方式

其他情况——例如验证者整合或不通过 Vault 直接向存款合约存款——也可能导致与 Vault 关联的验证者获得新的质押。为了在这些情况下确保准确的奖励归属，节点运营商可以在 Dashboard 合约中手动添加费用豁免，以增加已结算增长。

4. 流程

质押和解押

1. 注资
   • Vault 所有者 调用 VaultHub 上的 fund() 向 stVault 发送 $ETH$。
   • 增加 Vault 的 totalValue。
2. 存款验证者
   • 节点运营商 通过 预存款担保 发送存款以创建或充值验证者。
   • 可以批量完成。
   • 使用指向 Vault 地址的 $0\text{x}02$ 提款凭证。
   • 不改变 totalValue。
   • 如果 locked > totalValue 则回滚。
3. 接收 EL 和 CL 验证奖励
   • 验证者费用接收方可以设置为 Vault 地址。
   • 尽管增加 Vault 余额在报告更新之前不反映在 totalValue 中。
4. 退出验证者
   • Vault 所有者 可以调用 requestValidatorExits() 请求自愿退出。
   • 节点运营商、Vault 所有者 或 VaultHub（在极端条件下）可以调用 triggerValidatorWithdrawal() 执行 EIP-7002 “可触发提款”。
   • 一旦退出，验证者的余额将转移到 Vault。
   • 只有当 Vault 健康时才能请求部分提款。
5. 提款
   • Vault 所有者 调用 VaultHub 上的 withdraw() 从 Vault 余额中提取任意数量的未锁定 $ETH$（即 totalValue - locked）。
   • 退出验证者或部分提款对于提取质押的 $ETH$ 是必需的。

访问 stETH

1. 铸币

• Vault 所有者 调用 VaultHub 上的 mint()，铸造 $stETH$，最高可达锁定以太币（包括 $RR$）可覆盖的金额。
• 增加 Vault 的 liabilityShares。
• 铸币能力受当前 totalValue、liabilityShares、shareLimit 和 reserveRatio 的限制。

针对 stVault 的铸币受协议范围内的铸币 速率限制 的约束。

2. 销毁

• Vault 所有者 调用 VaultHub 上的 burn() 代表 Vault 销毁 $stETH$。
• 减少 Vault 的 liabilityShares。
• locked 金额会随着下一次证明更新而减少。

3. 再平衡

• Vault 所有者 调用 VaultHub 上的 rebalance() 将 $ETH$ 从 Vault 中再平衡出去。
• 通过从 Vault 中提取 $ETH$，以 $1:1$ 的比例通过 Lido Core 提交以获取 $stETH$，然后代表 Vault 销毁 $stETH$，从而同时减少 liabilityShares 和 totalValue。
• 以减少其 totalValue 为代价改善 Vault 健康状况。
• 如果意图使用已质押的 $ETH$，则需要退出验证者或部分提款。
• 可以由 Vault 所有者 执行，如果 Vault 的 forcedRebalanceThreshold 被突破，也可以无需许可地执行。

连接和断开

每个质押 Vault 都可以作为基本的委托质押设置独立运行。然而，为了启用 $stETH$ 铸币，它必须连接到 Lido VaultHub——一个管理 Vault 注册和控制铸币的中央合约。

连接流程：

1. 注资 Vault：Vault 的余额中必须至少有 $1 ETH$（连接存款）。
2. 设置存款人：Vault 中的存款人必须引用 Predeposit Guarantee 合约。
3. 将所有权转移给 VaultHub：Vault 将 Vault 的所有权转移给 VaultHub，从而表示同意加入。这防止 VaultHub 强制连接 Vault。
4. 连接：调用 VaultHub 上的连接函数，该函数会创建 Vault 记录，并附带从 OperatorGrid 检索到的默认铸币参数。

断开连接流程：

1. 销毁未偿付的 $stETH$：Vault 所有者必须完全销毁由 Vault 支持的任何 $stETH$。
2. 清算任何未清义务。Vault 所有者必须完全偿还任何现有赎回并支付 Lido 费用。
3. 请求断开连接：所有者调用 VaultHub 上的断开连接函数，标记 Vault 待移除。
4. 报告确认：断开连接在下一次 VaultHub 报告期间完成——Vault 从记录中移除，所有权被转回。Vault 从 OperatorGrid 的层级中移除。如果它选择再次连接，它将被放置在默认层级。如果任何 Vault 验证者在罚没事件中被报告，则断开连接中止。

Vault 固化

Staking Vault 使用自定义的 BeaconProxy 模式部署。从 VaultHub 断开 Vault 不会 阻止它接收由 Lido $DAO$ 控制的未来升级。

为了永久冻结 Vault 的逻辑并拒绝任何未来升级，Vault 所有者可以对其进行 固化——通过在代理中锁定当前实现地址。此固化只能在 Vault 完全与 VaultHub 断开连接之后才能执行。

强制再平衡

stVaults 设计的一个基石原则是：

$stETH$ 偿付能力 - 所有现有的 $stETH$ 都可以以 $1:1$ 的比例转换为 $ETH$

因此，每个 Vault 必须保持偿付能力，防止任何 Vault 特定的损失蔓延到 $stETH$ 持有者。强制执行此目的的机制称为 强制再平衡：

• 当 Vault 用于铸造 $stETH$ 的 准备金 降至其强制再平衡阈值以下时触发（例如，由于罚没或长期惩罚）。
• 包括两个部分：
  1. 强制验证者提款（无需许可，通过 EIP-7002）。
  2. 强制再平衡（使用可用 Vault 未质押的 $ETH$ 进行无需许可的再平衡）。
• 一旦触发，在 Vault 恢复健康之前，不允许进一步存款或提款。
• 强制再平衡将抵押率恢复到 $Reserve Ratio$。
• 最大再平衡金额 ($X$) 满足：

$$ (mintedShares - X)(totalValue - X) = 1 - RR $$

5. 风险

质押者和生态系统参与者应在参与 stVaults 之前仔细考虑这些风险并进行自己的研究。

5.1 生态系统风险

1. 质押集中度：通过 stVault 无许可创建、风险参数和限制来缓解，平衡多样化的节点运营商参与。
2. 代币偿付能力：通过风险参数来解决，以维持铸造的 $stETH$ 的合理准备金率，同时设置 stVaults 的最大可铸造 $stETH$ 的本地和全局限制。

5.2 stVaults 质押者的风险

1. 存款抢跑：通过 PredepositGuarantee 模块缓解。
2. 强制再平衡：通过确定性规则、政策和持续监控进行管理。
3. 罚没风险：尽管通过仔细的节点运营商选择和监控得到缓解，但故意不当行为或技术问题的可能性仍然存在。
4. 流动性风险：在市场压力下，将大量 $stETH$ 快速转换为 Lido Core 的 $ETH$ 可能存在潜在挑战，这将需要通过 stVaults 进行 $stETH$ 赎回。
5. 互操作性风险：与其它 DeFi 协议的集成可能引入额外的复杂性和潜在漏洞。

5.3 继承风险

1. 以太坊风险：以太坊网络的问题，例如共识失败或重大协议更改，可能会影响 stVault 操作。
2. Lido 基础设施风险：
   • $stETH$ 市场价格：由于提款时间延长，质押者面临 $stETH$ 交换价格低于固有价值的风险，预期验证者退出将使套利和无风险市场制造变得不可能。
   • 智能合约安全：Lido 可能存在智能合约漏洞或 bug 的固有风险；为了最大程度地降低这种风险，Lido 协议代码库保持开源、经过审查、审计、在测试网上推出，并由广泛的测试和 bug 赏金计划覆盖。
   • 预言机故障和数据篡改：预言机可能通过带来格式错误的数据影响协议的核算状态，该风险通过预言机委员会的共识机制和智能合约安全网得到缓解。
   • 协议内相关联的大规模罚没：如果 Lido Core 发生大规模罚没事件，将激活地堡模式，在 $stETH$ 持有者之间分摊转换率损失。
   • 治理风险：协议由 $LDO$ 代币持有者维护和升级。治理风险的缓解措施包括两阶段投票系统、公共委托投票平台以及预计在 $2025$ 年上半年激活的双重治理。

6. 有用链接

• stVaults 文档中心
• Lido V3 测试网
• GitHub 上的 stVaults PR
• Hasu 的第 2 份 GOOSE 投票通过提案
• EIP-7002 “可触发提款”
• EIP-7251 “增加 MAX_EFFECTIVE_BALANCE”
• LIP-5 “存款抢跑漏洞的缓解措施”
• EIP-6110：链上提供验证者存款

7. 变更日志

2025-02-11: 初始版本
2025-04-24: 为 Hoodi 上的 Lido V3 测试网进行修订
2025-06-16: 为 Hoodi 上的 Lido V3 测试网 2 进行修订
2025-10-17: 为 Hoodi 上的 Lido V3 测试网 3 进行修订
2026-1-6: 软发布后的微小更正

---

附录一. 测试网 2 → 测试网 3 回顾

新概念

• StakingVault 中的暂存余额 (PDG 全证明流程)
  • PDG 现在为每个 $1 ETH$ 的预存款在 Vault 上暂存 $31 ETH$，以保证验证者激活。暂存的 $ETH$ 在激活或释放之前不可提款。
  • VaultHub 强制所有现有预存款在连接时都有足够的暂存余额支持。
  • 行动：将暂存步骤纳入 PDG 存款流程；在用户界面/操作中显示暂存与可用余额。
• 健康义务 (份额)
  • 义务类型、它们的提名和优先级得到完善：健康、赎回、Lido 费用。
  • 行动：在机器人/操作中增加对健康义务的处理；在强制再平衡触发之前，优先进行自愿销毁/注资。
• Dashboard 中的高水位线运营商费用核算
  • 费用基础使用增长高水位线：growth = totalValue – inOutDelta，unsettled = max(growth – settledGrowth, 0)，fee = unsettled \times feeRate。
  • 明确的豁免调整 settledGrowth（例如，侧面/无担保存款、整合）。
  • 行动：更新任何费用计算假设和监控以符合 HWM 语义。
• Dashboard 中的 PDG 策略
  • 可配置模式：STRICT（严格）、ALLOW_PROVE（允许证明）、ALLOW_DEPOSIT_AND_PROVE（允许存款和证明）；管理通过 Dashboard 证明侧面验证者和无担保存款的允许范围。
  • 行动：确保在操作工具和用户流程中显示和执行策略。
• VaultHub 锁定计算中的最小准备金下限得到完善
  • locked = liability + max(reserveFromRR, max(connectDeposit, slashingReserve))。
  • $1 ETH$ 连接存款保持锁定状态，不能用于铸币。
  • 行动：在健康/铸币能力计算器中反映最小准备金下限。
• OperatorGrid 惩戒（阻止新的 $stETH$ 铸币）
  • $DAO$ 能够阻止铸币，同时允许销毁/管理操作（“惩戒”概念）。
  • 行动：在前端/机器人中处理惩戒状态；显示可操作的指导。
• VaultFactory 强制执行
  • VaultHub 只接受由 VaultFactory 部署的 Vault（代码/存储来源保护）。
  • 行动：仅通过工厂创建新 Vault。

破坏性变更

• 义务单位和优先级
  • 三种具有优先级的义务：健康（份额，最高）、赎回（份额）、Lido 费用（$ETH$，最低）。
  • 铸币能力/提款/存款门控现在取决于义务组合和优先级；如果不健康、有待处理赎回或未结算费用 > $1 ETH$，则存款暂停。
  • 行动：更新结算流程，在适用时首先通过销毁/再平衡减少份额。
• LazyOracle 新鲜度门控更多操作
  • 当报告过期时（要求最新检查点起 $\le 2$ 天新鲜度），新鲜度锁定提款、铸币、再平衡、向信标链存款和断开连接。
  • 行动：确保集成在这些操作之前更新单个 Vault 报告；添加重试/警告。
• PDG 证明限制
  • 只有已激活的验证者才能向 PDG 证明；待处理的验证者将被拒绝。
  • 行动：调整侧面/整合证明流程，等待激活最终确定后再证明。
• PDG 存款序列需要暂存
  • 预存款必须与暂存的 $31 ETH$ 配对；跳过暂存的流程将失败。
  • 行动：更新 PDG 调用（预存款 → 暂存 → 证明 → 激活/充值）和状态检查。
• Dashboard 费用模型变更
  • 以前使用的“奖励调整”模型被 HWM settledGrowth 加明确豁免取代；费用支付和安全检查已更改。
  • 行动：更新任何链下费用预测、警报和仪表板以符合 HWM；取消对旧“奖励调整”的依赖。
• 仅限 VaultFactory 接受
  • 手动部署的 Vault（非来自 VaultFactory）将不再被 VaultHub 接受。
  • 行动：迁移配置脚本以将 VaultFactory 用于所有新 Vault。

改进和优化

• 明确锁定/储备金语义
  • 正式化的最小储备金（连接存款和罚没储备金的最大值）提高了铸造/提款限制的可预测性。
  • 行动：修订计算器和健康阈值以匹配公式。
• 运营商费用安全和治理
  • 异常高费用阈值：超过总价值 $1\%$ 需要管理员支付；正常费用是无需许可的。
  • 费用变更需要新鲜报告和安全隔离条件。
  • 行动：添加 $1\%$ 阈值的警报；在操作中将费用变更门控在新鲜度检查之后。
• PDG 用户体验和批处理
  • 快速路径用于证明、激活和充值多个验证者；预存款时运营商/担保人余额附加。
  • 行动：采用批处理流程以减少操作开销和 gas。
• 铸币速率限制清晰度
  • 针对 stVaults 的铸币受协议范围内的质押速率限制的约束，明确记录。
  • 行动：在客户端中显示速率限制错误和退避。
• 隔离行为澄清
  • 相对隔离大小和指导；链上可验证的 EL 充值绕过隔离。
  • 行动：在基于 TV 的容量预测中反映隔离延迟。
• OperatorGrid 改进
  • 单个 Vault 参数（份额限制、费用）以及 StakingVault 和 OperatorGrid 之间运营商地址的明确耦合。
  • 行动：确保运营商多重签名卫生；在应用或重置每个 Vault 的覆盖时同步 UI。

废弃

• Dashboard “奖励调整”
  • 被 settledGrowth 高水位线加明确豁免取代。
  • 行动：移除基于奖励调整的调整；迁移到调整 settledGrowth 的豁免。
• 以 $ETH$ 计价的赎回
  • 被以份额计价的赎回和健康义务取代。
  • 行动：清除基于 $ETH$ 的赎回结算路径；在份额中使用销毁/再平衡。
• 手动（非工厂）Vault 部署
  • 今后将不被 VaultHub 接受。
  • 行动：停用临时部署脚本。

测试网 2 后值得深入研究的关键拉取请求

审计修复 2

// 修复 1-eth 恶意攻击
// [VAULTS] 1 eth 恶意攻击修复 #1432
// 更多检查新鲜报告和暂停存款的地方
// 铸造外部份额的质押限制
// stVaults 的 ERC20 恢复
// [功能请求]：StakingVault recoverERC20/recoverERC721 #1253
// 恢复赎回优先级高于费用
// 更好的整合辅助函数

审计修复 3

// PDG 的明确激活流程
// renounceOwnership 阻塞
// 节点运营商费用重做
// ERC7201 的存储位置统一

审计修复 4

// VaultHub 中更好的暂停状态
// 添加 obligationShortfallValue 视图
// Vault 只能由其所有者连接
// 断开连接时妥善结算 Lido 费用
// 外部份额更好的质押限制
// 使 Lido 中的 pause/resumeStaking 在已暂停/已恢复时回滚
// 修复来自 NO 端的基于溢出的 DoS

审计修复 5

// 修复 [Bug]：RoleMemberConfirmed：命名不一致 — 成员/角色字段实际上是地址/地址(256)
// 修复了许多注释
// 已向 OperatorGrid 添加 setConfirmExpiry()
// 已在 OperatorGrid 中添加参数验证
// PDG 的几项改进（输入验证、proveWCActivateAndTopUp 中的可选 topUp 和修复事件）
// Dashboard.transferVaultOwnership 现在返回布尔值，与其他确认方法一样

• 原文链接： hackmd.io/@lido/stVaults...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～