Native Asset ERC-4626 Tokenized Vault
Video
Original
Abstract
This standard is an extension of the ERC-4626 spec with an identical interface and behavioral overrides for handling Ether or any native asset as the underlying.
Motivation
A standard for tokenized ETH Vaults has the same benefits as ERC-4626, particularly in the case of Liquid Staking Tokens, (i.e. fungible ERC-20 wrappers around ETH staking).
Maintaining the same exact interface as ERC-4626 further amplifies the benefits as the standard will be maximally compatible with existing ERC-4626 tooling and protocols.
Specification
All ERC-7535 tokenized Vaults MUST implement ERC-4626 (and by extension ERC-20) with behavioral overrides for the methods asset
, deposit
, and mint
specified below.
ERC-4626 Breaking Changes
- Any
assets
quantity refers to wei of Ether rather than ERC-20 balances. - Any ERC-20
transfer
calls are replaced by Ether transfer (send
orcall
) - Any ERC-20
transferFrom
approval flows forasset
are not implemented deposit
andmint
have state mutabilitypayable
deposit
usesmsg.value
as the primary input and MAY ignoreassets
Methods
asset
MUST return 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE
per ERC-7528.
- name: asset type: function stateMutability: view inputs: [] outputs: - name: assetTokenAddress type: address
deposit
Mints shares
Vault shares to receiver
by depositing exactly msg.value
of Ether.
MUST have state mutability of payable
.
MUST use msg.value
as the primary input parameter for calculating the shares
output. MAY ignore assets
parameter as an input.
MUST emit the Deposit
event.
MUST revert if all of msg.value
cannot be deposited (due to deposit limit being reached, slippage, etc).
- name: deposit type: function stateMutability: payable inputs: - name: assets type: uint256 - name: receiver type: address outputs: - name: shares type: uint256
mint
Mints exactly shares
Vault shares to receiver
by depositing assets
of ETH.
MUST have state mutability of payable
.
MUST emit the Deposit
event.
MUST revert if all of shares
cannot be minted (due to deposit limit being reached, slippage, the user not sending a large enough msg.value
of Ether to the Vault contract, etc).
- name: mint type: function stateMutability: payable inputs: - name: shares type: uint256 - name: receiver type: address outputs: - name: assets type: uint256
Events
The event usage MUST be identical to ERC-4626.
Wrapped ETH
Any ERC-4626 Vault that uses a Wrapped ETH ERC-20 as the asset
MUST NOT implement ERC-7535. ERC-7535 only applies to native ETH.
Rationale
This standard was designed to maximize compatibility with ERC-4626 while minimizing additional opinionated details on the interface. Examples of this decision rationale are described below:
- maintaining the redundant
assets
input to thedeposit
function while making its usage optional - not enforcing a relationship between
msg.value
andassets
in amint
call - not enforcing any behaviors or lack thereof for
fallback
/__default__
methods, payability on additional vault functions, or handling ETH forcibly sent to the contract
All breaking implementation level changes with ERC-4626 are purely to accomodate for the usage of Ether or any native asset instead of an ERC-20 token.
Backwards Compatibility
ERC-7535 is fully backward compatible with ERC-4626 at the function interface level. Certain implementation behaviors are different due to the fact that ETH is not ERC-20 compliant, such as the priority of msg.value
over assets
.
It has no known compatibility issues with other standards.
Reference Implementation
TODO / WIP
Security Considerations
In addition to all security considerations of ERC-4626, there are security implications of having ETH as the Vault asset.
call
vs send
Contracts should take care when using call
to transfer ETH, as this allows additional reentrancy vulnerabilities and arbitrary code execution beyond what is possible with trusted ERC-20 tokens.
It is safer to simply send
ETH with a small gas stipend.
Implementers should take extra precautions when deciding how to transfer ETH.
Forceful ETH transfers
ETH can be forced into any Vault through the SELFDESTRUCT
opcode. Implementers should validate that this does not disrupt Vault accounting in any way.
Similarly, any additional payable
methods should be checked to ensure they do not disrupt Vault accounting.
Wrapped ETH
Smart contract systems which implement ERC-4626 should consider only supporting ERC-20 underlying assets, and default to using a Wrapped ETH ERC-20 instead of implementing ERC-7535 for handling ETH.
The subtle differences between ERC-4626 and ERC-7535 can introduce code fragmentation and security concerns.
Cleaner use cases for ERC-7535 are ETH exclusive, such as Wrapped ETH and Liquid Staking Tokens.
Copyright
Copyright and related rights waived via CC0.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all