ERC-7535 原生资产金库：ERC-4626 装 ETH 时，哪三个接口要改写

许多金库类产品用 ERC-4626 接口统一记账，这套接口默认底层资产是一个 ERC-20 代币：asset() 返回代币合约地址，deposit() 靠 approve 加 transferFrom 把钱搬进金库。可一旦底层资产是原生以太币，这些假设全部落空——以太币没有合约地址，也没有授权流。ERC-7535（Native Asset ERC-4626 Tokenized Vault）就是给这种场景写的适配规范。按照以太坊 ercs 仓库的记录，这份提案状态为 Final，创建于 2023 年 10 月 12 日。

只改行为，不改接口形状

ERC-7535 的做法不是另造一套金库，而是要求实现者在保持 ERC-4626（以及其下的 ERC-20）接口签名不变的前提下，对 asset、deposit、mint 三个方法做行为覆盖。也就是说，任何已经会读 ERC-4626 的仪表盘、路由器或前端，理论上不改代码就能对接一个装 ETH 的金库。

具体的行为覆盖有四条。第一，asset() 必须返回 ERC-7528 约定的原生资产哨兵地址 0xEeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE，用这个全大写 E 的特殊地址告诉所有工具：这里的资产不是任何 ERC-20，而是链的本位币。第二，所有涉及资产数量的地方，计量单位从代币余额改为以 wei 计的以太币。第三，凡是原规范里用 ERC-20 transfer 出金的地方，一律换成以太币的直接转账（send 或 call），而针对资产代币的 transferFrom 授权流程则完全不实现——原生币本来就没有授权可走。第四，deposit 和 mint 的状态可变性改成 payable，deposit 必须以 msg.value 为主要输入来铸造份额，可以忽略 assets 参数；当然它仍然要在存款限额或滑点不满足时回滚，并照常发出 Deposit 事件。

为什么流动性质押最需要它

标准文本点名的受益场景是流动性质押代币：本质上是围绕 ETH 质押的 ERC-20 份额凭证。过去每个 LSD 项目都要自己发明”如何用 4626 语义描述一个装 ETH 的金库”，注释和边界情况各家不同，聚合器只能逐家适配。ERC-7535 把 msg.value 与 assets 谁说了算、asset() 该填什么这类高频分歧写死成统一规则，金库份额仍然是标准 ERC-20，对下游组合协议的可见性没有变化。

出金一侧的两个经典坑

装了原生币，出金逻辑就从代币转账变成了 ETH 转账，而 ETH 转账有两个 ERC-20 世界里不存在的坑，标准专门用两个小节讲透。其一是 call 与 send 的取舍：标准提醒用 call 转 ETH 会引入重入与任意代码执行面，比接收一个受信的 ERC-20 危险得多，转而建议用小 gas 额度的 send——代价是接收方若是带复杂 fallback 的智能合约钱包，这笔出金可能失败，实现必须交代自己选了哪条路以及如何应对合约接收方。其二是强制 ETH 入账：标准点名 SELFDESTRUCT 自我毁灭这类机制可以把 ETH 硬塞进任何合约地址”绕过合约逻辑直接塞钱进来”的路径，任何人并不需要调用 deposit 也能让金库收到 ETH。标准要求实现者正面处理这笔钱——要么在文档里声明它算入金库资产从而瞬间稀释份额估值，要么把它排除在记账之外，含糊不得。读一个金库合约时，这两段说明是判断它是否认真做过原生资产适配的快速标志。

买家该看什么

与普通 ERC-20 金库并排读时的核对清单

把两类金库的合约摊开对照，差异集中在三处。看函数签名，7535 与普通 4626 完全同名同参，唯一线索是 asset() 的返回值是不是那个哨兵地址——若返回某个 ERC-20 地址，它就是普通金库；若返回 0 地址，多半是没做适配的旧实现，需要按各自文档的特殊说明对待。看 payable 标记，deposit 与 mint 带 payable 是原生资产路径的直接证据。看事件流，Deposit 事件里的 assets 字段按 wei 解释，跨金库做收益率对比的工具如果不区分计量单位，会把同一个数字读出两种含义。还有一个常被忽略的入口：原生金库普遍同时提供 redeem 与 withdraw 这对按份额出金的路径，语义与 4626 一致，只是出口从转账变成了 ETH 发送，接收方为智能合约钱包时能否收款、是否要求预先声明接收能力，都写在实现的 call 与 send 一节里，用大额出金前先小额试路永远是低成本的习惯。标准末尾还给生态留了一句建议：不专用于以太币的系统可以直接要求底层资产用 WETH 这类 ERC-20，把 7535 留给以太币专属场景——流动性质押、WETH 包装层本身——以减少两套近似语义并存带来的代码分裂与安全面，这解释了为什么同一产品族里两类金库会长期共存。

对一个提供 ETH 生息份额的产品，可以按三个问题核验：金库合约的 asset() 是否返回那个哨兵地址，说明它认真走 7535 语义还是自造接口；文档是否写明 deposit 以 msg.value 为准，避免你多转的零头去向不明；文档是否承认强制转账路径并说明记账方式。最后按仓库口径提醒一句：Final 指规范文本冻结，不等于市面金库都已实现它，接入前仍要用 supportsInterface 或直接读合约代码核对。本文为机制说明，不构成任何投资建议。