ERC-7575 extends ERC-4626 so that the vault’s share token can be a separate contract from the vault itself. That lets several vaults — each accepting a different underlying asset — mint and burn the same share token. For real-world asset funds that want to accept multiple stablecoins or forms of tokenized cash into one fund, ERC-7575 provides the plumbing, and it is the base on which ERC-7540 asynchronous vaults are built.
Key takeaways
- Adds
share()to the vault, returning the address of the share token (which may be the vault itself, preserving ERC-4626 behaviour). - Multiple entry points (e.g. a USDC vault and a EURC vault) can point to one share token.
- The share token can expose
vault(asset)to look up the entry point for each asset, emittingVaultUpdatewhen this changes. - Useful for modular architectures where compliance, accounting and share transfer logic live in different contracts.
The problem it solves
In ERC-4626, the vault is the share token and has exactly one underlying asset. A fund that wants to accept USDC and EURC would need two vaults with two different share tokens — splitting liquidity and confusing investors. ERC-7575 decouples the two, so investors in either currency end up holding the same fund shares.
How it works
| Element | Role |
|---|---|
| Vault entry point | Implements ERC-4626 deposit/redeem for one asset; share() points to the shared token |
| Share token | ERC-20 representing fund units; minted/burned by authorised vaults |
vault(asset) (optional on share) |
Returns the entry point for a given asset |
VaultUpdate(asset, vault) |
Event when an entry point is added or changed |
Each entry point is responsible for converting its asset into the fund’s accounting unit — for example using an FX rate for EURC — before minting shares.
RWA use cases
- Multi-currency funds accepting USD and EUR stablecoins into one share class.
- Tokenized cash interoperability — accepting both a stablecoin and a bank deposit token.
- Separating compliance — a permissioned share token (identity checks on transfer) with simple entry-point vaults.
- Upgradable entry points — replace or add vaults without migrating the share token investors hold.
Design considerations
- Pricing consistency: every entry point must value deposits and redemptions on the same NAV basis, including FX conversions and fees.
- Mint authority: restrict share minting/burning strictly to registered entry points.
- Liquidity per asset: redemptions in a given asset depend on that entry point’s liquidity; consider routing or async redemptions.
- Integrator awareness: tools that assume vault = share must read
share()instead.
Architecture example: a USD and EUR entry fund
| Contract | Role |
|---|---|
FundShare (ERC-20, permissioned) |
The single share token investors hold |
UsdcEntryVault (ERC-4626 / ERC-7540) |
Accepts USDC; share() → FundShare |
EurcEntryVault (ERC-4626 / ERC-7540) |
Accepts EURC; converts at FX rate; share() → FundShare |
FxOracle |
Provides EUR/USD rate with staleness checks |
NavOracle |
Publishes fund NAV in USD |
On a EURC deposit, the entry vault converts the deposit into USD terms using the FX oracle, then mints shares at the USD NAV. On redemption, it converts back. The share token’s vault(asset) mapping lets integrators discover each entry point.
Pricing pitfalls to avoid
- Stale FX rates creating arbitrage between entry points — enforce freshness and bounds.
- Different rounding in each entry vault — standardise the maths in a shared library.
- Fee inconsistencies — apply fees in one place (often the share or NAV layer).
- Liquidity mismatch — redemptions in EURC require EURC liquidity; consider async redemptions or routing through conversion.
Governance
Adding or replacing an entry point changes who can mint shares. Treat it like a privileged upgrade: multisig approval, timelock, event monitoring (VaultUpdate) and disclosure to investors.
Frequently asked questions
No. It is an extension. A vault where share() returns its own address behaves exactly like ERC-4626.
ERC-7540 asynchronous vaults use the separated share token model so request/claim vaults can be added alongside other entry points.
Yes — each class can be its own share token with its own set of entry points.
Not by itself. Add identity and transfer restrictions to the share token for regulated funds.
Yes, in principle — the share token can enforce identity checks while entry vaults handle deposits and redemptions. The entry vaults themselves then need appropriate permissions.
No — shares are the same token with one NAV; only the conversion of deposit and redemption amounts differs.
NUVZ is the RWA and Web3 engineering brand of ESS ENN Associates (est. 1993). Our team has designed and shipped tokenization platforms for real estate, education loans, solar PPAs, energy, carbon credits, bank deposits and trade documents. About us · Case studies
This article is for general information only and is not legal, tax or investment advice. Token standards evolve — always confirm the current status of an ERC at eips.ethereum.org and take advice from qualified counsel in each jurisdiction before issuing tokens.
