ERC-7535 Ether-native ERC-4626 vault (Native Asset ERC-4626 Tokenized Vault)
Final · Vaults & DeFi · created 2023-10-12
A standard that keeps the ERC-4626 tokenized vault interface intact while letting ether (ETH), Ethereum's native currency, be deposited into and withdrawn from the vault as its underlying asset instead of an ERC-20 token.
Why it is needed
ERC-4626 is a common specification for vaults that give you share tokens when you deposit assets, but it presumes that the deposited asset is an ERC-20 token. Ether itself is not an ERC-20 token, so it has no token transfer function or approve step, and it moves by attaching an amount directly to the transaction (msg.value). As a result, vaults that take ether directly, especially services such as Liquid Staking Tokens where you deposit ether and receive a liquid token, could not use ERC-4626 as is. If each service builds its own ether deposit function in its own way, it is incompatible with existing tools and protocols built for ERC-4626, and integration costs rise. This standard keeps the same function shapes as ERC-4626 and specifies only the behavior that changes when handling ether, preserving compatibility with the existing ecosystem as much as possible.
In depth
Behavior that differs from ERC-4626
A vault under this standard MUST implement ERC-4626 (and ERC-20), but changes the behavior of only three functions: asset, deposit and mint. Every assets amount means a quantity of ether in wei, not an ERC-20 balance. ERC-20 transfer calls are replaced by ether transfers (send or call), and the transferFrom approval flow for an underlying asset is not implemented. deposit and mint must be payable, and deposit uses msg.value as its primary input and may ignore the assets parameter. Event usage must be identical to ERC-4626.
asset returns the ether representative address
Ether has no contract address, so the asset function must return the ether representative address defined by ERC-7528, 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE. An integrator that sees this address knows the vault's underlying asset is native ether, not an ERC-20 token.
deposit is based on msg.value
deposit deposits exactly msg.value of ether and mints shares to the receiver. The primary input to the share calculation must be msg.value, and the assets parameter MAY be ignored. If the full msg.value cannot be deposited, for example because a deposit limit is reached or because of slippage, it must revert, and it must emit the Deposit event. The assets input is kept so that the function signature stays identical to ERC-4626. Since msg.value is always passed anyway, it is used as the reference value. Forcing it to match assets would cost unnecessary gas or could produce undefined behavior when the two values differ, so the parameter is allowed to be ignored.
mint is based on the share amount
mint mints exactly shares of shares to the receiver and returns assets, the amount of ether required. It must be payable and must emit the Deposit event. It must revert if all of the shares cannot be minted, for example because a deposit limit is reached, because of slippage, or because the msg.value the user sent is insufficient. The specification does not force msg.value and the returned assets value to be equal. Users often send slightly more ether than needed, and enforcing equality would make transactions fail unnecessarily. Whether to refund the excess ether or have the vault absorb it is up to the implementer, and depositors are advised to send an amount as exact as possible.
Not applicable to Wrapped ETH vaults
An ERC-4626 vault that uses the Wrapped ETH ERC-20 token as its underlying asset MUST NOT implement this standard. This standard applies only to native ether. A Wrapped ETH vault is well served by plain ERC-4626, and mixing the two standards can cause confusion because of subtle behavioral differences.
Design direction: minimal changes
This standard is designed to maximize compatibility with ERC-4626 and to add as little opinion to the interface as possible. It keeps the redundant assets input of deposit but makes its use optional, does not enforce any relationship between msg.value and assets in mint, and does not specify fallback behavior, whether other functions are payable, or how forcibly sent ether is handled. Every difference from ERC-4626 exists only to accommodate the fact that ether is not an ERC-20. At the function interface level it is fully backward compatible with ERC-4626, and there are no known conflicts with other standards. The status of this proposal has been finalized as Final.
Things to watch out for
- Difference between call and send: Sending ether with call opens up broader reentrancy attacks and arbitrary code execution than a trusted ERC-20 token does. Sending with send, which attaches only a small amount of gas, is safer, and the choice of transfer method requires particular care.
- Forced ether transfers: The SELFDESTRUCT instruction can force ether into any vault. You must verify that this does not disturb the vault's accounting, and also check that any additional payable functions you add do not break the accounting.
- Use Wrapped ETH where possible: A system that implements ERC-4626 should by default consider supporting only ERC-20 underlying assets and handling ether as Wrapped ETH. Subtle differences between ERC-4626 and this standard can cause code fragmentation and security problems, so this standard is best used only where the vault is ether-specific, such as Wrapped ETH or liquid staking tokens.