ERC-7535: 原生资产 ERC-4626 代币化 Vault

以太币（原生资产）作为底层资产的 ERC-4626 代币化 Vault

摘要

本标准是 ERC-4626 规范的扩展，具有相同的接口，并对处理以太币或任何原生资产作为底层资产进行了行为覆盖。

动机

代币化 ETH Vault 的标准与 ERC-4626 具有相同的优势，特别是在流动性质押代币的情况下（即，围绕 ETH 质押的可互换 ERC-20 包装器）。

保持与 ERC-4626 完全相同的接口进一步扩大了优势，因为该标准将最大限度地与现有的 ERC-4626 工具和协议兼容。

规范

所有 ERC-7535 代币化的 Vault 必须实现 ERC-4626（并因此实现 ERC-20），并对下面指定的方法 asset、deposit 和 mint 进行行为覆盖。

ERC-4626 突破性变更

• 任何 assets 数量指的是以太币的 wei，而不是 ERC-20 余额。
• 任何 ERC-20 transfer 调用都将替换为以太币转移（send 或 call）
• 任何 ERC-20 transferFrom 的 asset 批准流程都不会实现
• deposit 和 mint 具有状态可变性 payable
• deposit 使用 msg.value 作为主要输入，并且可以忽略 assets

方法

asset

必须按照 ERC-7528 返回 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE。

- name: asset
  type: function
  stateMutability: view

  inputs: []

  outputs:
    - name: assetTokenAddress
      type: address

deposit

通过存入精确数量的 msg.value 以太币，将 shares Vault 份额铸造给 receiver。

必须具有状态可变性 payable。

必须使用 msg.value 作为计算 shares 输出的主要输入参数。即，可以忽略 assets 参数作为输入。

必须发出 Deposit 事件。

如果所有 msg.value 都无法存入（由于达到存款限额、滑点等），则必须回退。

- name: deposit
  type: function
  stateMutability: payable

  inputs:
    - name: assets
      type: uint256
    - name: receiver
      type: address

  outputs:
    - name: shares
      type: uint256

mint

通过存入 assets 数量的 ETH，将精确数量的 shares Vault 份额铸造给 receiver。

必须具有状态可变性 payable。

必须发出 Deposit 事件。

如果所有 shares 都无法被铸造（由于达到存款限额、滑点、用户没有向 Vault 合约发送足够大的 msg.value 以太币等），则必须回退。

- name: mint
  type: function
  stateMutability: payable

  inputs:
    - name: shares
      type: uint256
    - name: receiver
      type: address

  outputs:
    - name: assets
      type: uint256

事件

事件用法必须与 ERC-4626 相同。

包装后的 ETH

任何使用包装后的 ETH ERC-20 作为 asset 的 ERC-4626 Vault 必须不实现 ERC-7535。ERC-7535 仅适用于原生 ETH。

理由

此标准旨在最大限度地与 ERC-4626 兼容，同时最大限度地减少接口上其他固执己见的细节。以下描述了此决策原理的示例：

• 在使 assets 的使用成为可选的情况下，保持 assets 输入到 deposit 函数的冗余
• 不强制执行 msg.value 和 assets 在 mint 调用中的关系
• 不对 fallback/__default__ 方法、其他 vault 函数的可支付性或处理强制发送到合约的 ETH 强制执行任何行为或缺乏行为

与 ERC-4626 的所有突破性实现级别更改纯粹是为了适应使用以太币或任何原生资产而不是 ERC-20 代币。

允许在存款中忽略 assets 参数

无论如何，msg.value 必须始终传递以资助 deposit，因此最好将其视为主要输入数字。允许使用 assets 要么强制执行严格的相等性和额外的不必要的 gas 开销以实现冗余，要么允许不同的值，这可能会导致 footgun 和未定义的行为。

可能有效的最后一个选项是要求 assets 必须为 0，但这仍然需要在实现级别强制执行 gas，并且可以更容易地保持未指定状态，因为输入在规范中编写的功能上可以忽略不计。

允许 msg.value 不等于 Mint 中的 assets 输出

在许多情况下，用户可能会在 mint 调用中存入稍微过多的以太币。在这些情况下，强制 msg.value 等于 assets 将导致不必要的回退。是否退还或吸收任何多余的以太币由 vault 实现者决定，存款人可以尽可能接近精确金额进行存款。

向后兼容性

ERC-7535 在函数接口级别与 ERC-4626 完全向后兼容。由于 ETH 不符合 ERC-20 标准，因此某些实现行为不同，例如 msg.value 优先于 assets。

它与其他标准没有已知的兼容性问题。

安全考虑

除了 ERC-4626 的所有安全考虑之外，将 ETH 作为 Vault 资产还存在安全隐患。

call vs send

合约在使用 call 转移 ETH 时应小心，因为这会带来额外的重入漏洞和超出可信 ERC-20 代币可能性的任意代码执行。

简单地 send 带有少量 gas 津贴的 ETH 更安全。

实施者在决定如何转移 ETH 时应采取额外的预防措施。

强制 ETH 转移

ETH 可以通过 SELFDESTRUCT 操作码强制进入任何 Vault。实施者应验证这不会以任何方式扰乱 Vault 会计。

同样，应检查任何额外的 payable 方法，以确保它们不会扰乱 Vault 会计。

包装后的 ETH

实现 ERC-4626 的智能合约系统应考虑仅支持 ERC-20 底层资产，并默认使用包装后的 ETH ERC-20 而不是实现 ERC-7535 来处理 ETH。

ERC-4626 和 ERC-7535 之间的细微差异可能会导致代码碎片和安全问题。

ERC-7535 更清洁的用例是 ETH 独有的，例如包装后的 ETH 和流动性质押代币。

版权

版权及相关权利通过 CC0 放弃。

Citation

Please cite this document as:

Joey Santoro (@joeysantoro), "ERC-7535: 原生资产 ERC-4626 代币化 Vault," Ethereum Improvement Proposals, no. 7535, October 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7535.