{"id":"ERC-4626","name":"Tokenized Vaults","status":"Final","chain":"both","category":{"id":"defi","name":"DeFi Patterns","description":"Vaults, bonds, and financial primitives"},"journeyStages":[{"id":"management","name":"Asset Management","description":"Managing assets over time"}],"uxImpact":"ERC-4626 standardizes tokenized vault interfaces. Deposit an underlying asset and receive shares representing a claim on the vault; share-to-asset value and yield depend on the deployed strategy. Different protocols can expose the same deposit, withdraw, share, and asset methods without guaranteeing positive returns.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-4626","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-4626","summary":"ERC-4626 standardizes tokenized vault interfaces. Deposit an underlying asset and receive shares representing a claim on the vault; share-to-asset value and yield depend on the deployed strategy. Different protocols can expose the same deposit, withdraw, share, and asset methods without guaranteeing positive returns.","applicability":{"whenToUse":["Users deposit into yield vaults and need share-to-asset value clarity.","Your product lists vault positions from multiple protocols with one pattern.","Deposit and withdraw previews must show expected assets after fees."],"whenToAvoid":["Yield is informational only with no deposit or withdraw actions.","Each vault uses a bespoke API you cannot normalize to ERC-4626.","Users never see share balances or underlying asset equivalence."]},"designerTakeaways":["You can show vault value in assets users understand, not opaque share units.","You can reuse a deposit and withdraw flow across ERC-4626 vaults while reading each vault's limits, fees, and strategy data.","You can label estimates, fees, and measured gains or losses without promising positive returns."],"designDecisions":[{"question":"Do you show shares, assets, or both?","recommendation":"Lead with asset value (USDC); expose share count in advanced details.","rationale":"Users think in deposits and dollar value, not internal share units."},{"question":"How is APY presented?","recommendation":"Label as estimated APY with source and update time.","rationale":"Vault yields change; over-precise APY feels guaranteed."},{"question":"What does withdraw preview include?","recommendation":"Show assets out, shares burned, and any delay or fee.","rationale":"The base interface does not define an asynchronous queue; extensions and surrounding protocols may add delays or separate request flows."},{"question":"How do you handle insolvency or pause?","recommendation":"Read current maxDeposit/maxMint/maxWithdraw/maxRedeem and protocol-specific restrictions; disable only unavailable actions and explain why.","rationale":"A restriction on deposits does not necessarily block withdrawals. A pause or insolvency signal does not establish recovery timing or fund safety."}],"statesToDesign":[{"state":"Deposit preview","trigger":"User enters deposit amount.","userNeed":"Know expected shares and post-deposit balance.","designResponse":"Show assets in, estimated shares, and current exchange rate."},{"state":"Withdraw preview","trigger":"User enters withdraw amount.","userNeed":"Know assets received and timing.","designResponse":"Assets out, shares burned, cooldown if applicable."},{"state":"Position value changes","trigger":"The vault's share-to-asset value changes over time.","userNeed":"See value and profit/loss without assuming a gain.","designResponse":"Live asset value with an optional measured profit/loss metric."},{"state":"Insufficient liquidity","trigger":"Vault cannot fulfill full withdraw instantly.","userNeed":"Know the current withdrawal limit and whether another supported path exists.","designResponse":"Show maxWithdraw/maxRedeem for the owner. Offer a queue or delayed request only when the integration implements it; otherwise explain that withdrawal is currently unavailable or limited."},{"state":"Vault paused","trigger":"Protocol pauses deposits or withdrawals.","userNeed":"Know which actions are unavailable and whether recovery timing is known.","designResponse":"Link the protocol’s explanation, disable only restricted actions, and show unknown timing when no reliable resumption estimate exists."}],"problemsSolved":[{"problem":"Every DeFi protocol has different vault interface","oldWay":"Vault implementations expose different methods, parameters, and accounting conventions","newWay":"Conforming ERC-4626 vaults expose a common deposit, mint, withdraw, and redeem interface","impact":"critical"},{"problem":"Hard to calculate actual value of vault shares","oldWay":"Each vault has custom math for share→asset conversion","newWay":"convertToAssets(shares) and convertToShares(assets) standard","impact":"high"},{"problem":"Can't aggregate vault positions across protocols","oldWay":"Custom integration for each vault type","newWay":"One interface queries any ERC-4626 vault","impact":"high"}],"uxPatterns":[{"name":"Vault Deposit","description":"Standard deposit flow with fee-aware share preview","userFlow":["User enters deposit amount","Read maxDeposit(receiver) and the integration’s supported slippage protection","App calls previewDeposit(assets) for the fee-aware estimate","Shows expected shares, fees, and a slippage bound","Displays the current preview rate and any ideal/reference rate separately","User confirms deposit"]},{"name":"Vault Position","description":"Show current position with measured value change","userFlow":["User views positions","App queries share balances","Calls convertToAssets for value","Calculates earnings vs deposit","Shows profit/loss"]},{"name":"Withdraw Flow","description":"Redeem shares for underlying assets","userFlow":["User chooses withdraw mode","Enter shares OR assets amount","Read maxWithdraw(owner) or maxRedeem(owner) for the selected action","App calls previewWithdraw or previewRedeem for the fee-aware estimate","Shows shares to burn","User confirms withdrawal"]}],"uiComponents":[{"name":"VaultCard","description":"Summary of a vault position","states":["no-position","deposited","earning","losing"],"props":["vault","shares","assets","apy"]},{"name":"ShareAssetConverter","description":"Input that converts between shares and assets","states":["shares-mode","assets-mode"],"props":["shares","assets","exchangeRate","onChange"]},{"name":"APYIndicator","description":"Show estimated APY with its source, period, and update time; ERC-4626 does not define an APY query.","states":["positive","negative","loading"],"props":["apy","timeframe"]},{"name":"EarningsDisplay","description":"Shows profit/loss vs deposited amount","states":["profit","loss","break-even"],"props":["deposited","currentValue","earned"]}],"antiPatterns":[{"pattern":"Only showing share balance","why":"\"952.38 yvUSDC\" means nothing without conversion","instead":"Show the current asset value from the deployed vault conversion, with timestamp and profit/loss direction","severity":"critical"},{"pattern":"Not explaining share price changes","why":"Users confused when share count doesn't match deposits","instead":"Explain the measured change in asset value, including losses, using actual position data.","severity":"high"},{"pattern":"Hiding withdrawal fees/slippage","why":"User expects $1000, gets $950","instead":"Show expected output AFTER fees clearly","severity":"critical"},{"pattern":"Not showing historical earnings","why":"Users can't see if vault is performing well","instead":"Track measured profit or loss with deposits, withdrawals, and valuation assumptions accounted for.","severity":"medium"}],"onMonad":[{"aspect":"Vault asset and transaction fee","ethereum":"An ERC-4626 vault accepts its configured ERC-20 asset; native ETH fees are separate.","monad":"A vault's ERC-20 asset balance is separate from native MON fees and EOA reserve eligibility. No universal 10-unit reserve applies to the vault's asset or shares.","designImplication":"Read the vault's asset and deposit or withdrawal limits. Account for native transaction fees separately and verify the deployed vault before offering the flow."}],"specConstraints":[{"id":"share-vs-asset","constraint":"ERC-20 operations on a vault’s shares represent a claim on the underlying holdings, not direct underlying units.","appliesTo":"application","normativity":"normative","specQuote":"All [EIP-4626](./eip-4626.md) tokenized Vaults MUST implement EIP-20 to represent shares.\nIf a Vault is to be non-transferrable, it MAY revert on calls to `transfer` or `transferFrom`.\nThe EIP-20 operations `balanceOf`, `transfer`, `totalSupply`, etc. operate on the Vault \"shares\"\nwhich represent a claim to ownership on a fraction of the Vault's underlying holdings.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#specification","designImplication":"Balance, amount, and confirmation copy must label whether it is showing shares or underlying assets and avoid treating the two as interchangeable."},{"id":"share-label","constraint":"Vault name and symbol should reflect the underlying token when appropriate.","appliesTo":"application","normativity":"normative","specQuote":"All EIP-4626 tokenized Vaults MUST implement EIP-20's optional metadata extensions.\nThe `name` and `symbol` functions SHOULD reflect the underlying token's `name` and `symbol` in some way.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#specification","designImplication":"Use the deployed vault metadata and underlying asset metadata together so users can identify the share instrument and its underlying."},{"id":"convert-fee-free","constraint":"convertToShares and convertToAssets exclude fees and should not reflect per-user limits.","appliesTo":"application","normativity":"normative","specQuote":"MUST NOT be inclusive of any fees that are charged against assets in the Vault.","specSection":"Specification > Methods > convertToShares","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#converttoshares","designImplication":"Label convert results as fee-free exchange-rate estimates and do not present them as the exact amount a particular user will receive."},{"id":"convert-caller-independent","constraint":"Conversion methods must return the same result regardless of caller.","appliesTo":"application","normativity":"normative","specQuote":"MUST NOT show any variations depending on the caller.","specSection":"Specification > Methods > convertToShares","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#converttoshares","designImplication":"Do not make a quote depend on the connected account unless the paired preview or transaction path explicitly introduces caller-specific behavior."},{"id":"convert-round-down","constraint":"Conversion methods must round down toward zero.","appliesTo":"application","normativity":"normative","specQuote":"MUST NOT revert unless due to integer overflow caused by an unreasonably large input.","specSection":"Specification > Methods > convertToShares","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#converttoshares","designImplication":"Show rounding loss where it matters and never promise more shares or assets than the conversion result permits."},{"id":"max-deposit-limit","constraint":"maxDeposit is a conservative upper bound and must not exceed what the receiver can accept.","appliesTo":"application","normativity":"normative","specQuote":"MUST return the maximum amount of assets `deposit` would allow to be deposited for `receiver` and not cause a revert, which MUST NOT be higher than the actual maximum that would be accepted (it should underestimate if necessary). This assumes that the user has infinite assets, i.e. MUST NOT rely on `balanceOf` of `asset`.","specSection":"Specification > Methods > maxDeposit","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#maxdeposit","designImplication":"Use maxDeposit to cap amount-entry guidance, while explaining that the current limit can be zero or lower than the user’s balance."},{"id":"max-deposit-disabled","constraint":"maxDeposit must return zero when deposits are disabled.","appliesTo":"application","normativity":"normative","specQuote":"MUST return the maximum amount of assets `deposit` would allow to be deposited for `receiver` and not cause a revert, which MUST NOT be higher than the actual maximum that would be accepted (it should underestimate if necessary). This assumes that the user has infinite assets, i.e. MUST NOT rely on `balanceOf` of `asset`.","specSection":"Specification > Methods > maxDeposit","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#maxdeposit","designImplication":"Render a disabled/paused deposit state when maxDeposit is zero instead of presenting a signable deposit action."},{"id":"preview-fees","constraint":"Preview methods include fees and other transaction-specific effects.","appliesTo":"application","normativity":"normative","specQuote":"MUST be inclusive of deposit fees. Integrators should be aware of the existence of deposit fees.","specSection":"Specification > Methods > previewDeposit","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#previewdeposit","designImplication":"Use the matching preview for confirmation amounts and label fees or deductions; do not substitute convertToShares/assets for a transaction preview."},{"id":"deposit-revert","constraint":"deposit must revert when the full requested asset amount cannot be deposited for the receiver.","appliesTo":"application","normativity":"normative","specQuote":"MUST revert if all of `assets` cannot be deposited (due to deposit limit being reached, slippage, the user not approving enough underlying tokens to the Vault contract, etc).","specSection":"Specification > Methods > deposit","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#deposit","designImplication":"Before signing, validate the requested amount against the receiver’s acceptance path and show a recoverable failure if the full amount cannot be deposited."},{"id":"mint-revert","constraint":"mint must revert when the requested full share amount cannot be minted for the receiver.","appliesTo":"application","normativity":"normative","specQuote":"MUST revert if all of `shares` cannot be minted (due to deposit limit being reached, slippage, the user not approving enough underlying tokens to the Vault contract, etc).","specSection":"Specification > Methods > mint","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#mint","designImplication":"Treat a share-targeted mint as a distinct flow and show the exact share target plus the underlying amount required by the matching preview."},{"id":"withdraw-revert","constraint":"withdraw must revert when the full requested asset amount cannot be withdrawn for the owner.","appliesTo":"application","normativity":"normative","specQuote":"MUST revert if all of `assets` cannot be withdrawn (due to withdrawal limit being reached, slippage, the owner not having enough shares, etc).","specSection":"Specification > Methods > withdraw","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#withdraw","designImplication":"Keep the requested asset amount visible and explain when limits, liquidity, or owner-specific constraints prevent the full withdrawal."},{"id":"redeem-revert","constraint":"redeem must revert when the full requested share amount cannot be redeemed for the owner.","appliesTo":"application","normativity":"normative","specQuote":"MUST revert if all of `shares` cannot be redeemed (due to withdrawal limit being reached, slippage, the owner not having enough shares, etc).","specSection":"Specification > Methods > redeem","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#redeem","designImplication":"Keep share and asset amounts distinct in redemption confirmation and show the matching preview result before signing."},{"id":"preview-not-oracle","constraint":"Preview values are not safe price oracles and may be manipulated.","appliesTo":"application","normativity":"security-considerations","specQuote":"## Security Considerations\n\nFully permissionless use cases could fall prey to malicious implementations which only conform to the interface but not the specification.\nIt is recommended that all integrators review the implementation for potential ways of losing user deposits before integrating.\n\nIf implementors intend to support EOA account access directly, they should consider adding an additional function call for `deposit`/`mint`/`withdraw`/`redeem` with the means to accommodate slippage loss or unexpected deposit/withdrawal limits, since they have no other means to revert the transaction if the exact output amount is not achieved.\n\nThe methods `totalAssets`, `convertToShares` and `convertToAssets` are estimates useful for display purposes,\nand do _not_ have to confer the _exact_ amount of underlying assets their context suggests.\n\nThe `preview` methods return values that are as close as possible to exact as possible. For that reason, they are manipulable by altering the on-chain conditions and are not always safe to be used as price oracles. This specification includes `convert` methods that are allowed to be inexact and therefore can be implemented as robust price oracles. For example, it would be correct to implement the `convert` methods as using a time-weighted average price in converting between assets and shares.\n\nIntegrators of EIP-4626 Vaults should be aware of the difference between these view methods when integrating with this standard. Additionally, note that the amount of underlying assets a user may receive from redeeming their Vault shares (`previewRedeem`) can be significantly different than the amount that would be taken from them when minting the same quantity of shares (`previewMint`). The differences may be small (like if due to rounding error), or very significant (like if a Vault implements withdrawal or deposit fees, etc). Therefore integrators should always take care to use the preview function most relevant to their use case, and never assume they are interchangeable.\n\nFinally, EIP-4626 Vault implementers should be aware of the need for specific, opposing rounding directions across the different mutable and view methods, as it is considered most secure to favor the Vault itself during calculations over its users:\n\n- If (1) it's calculating how many shares to issue to a user for a certain amount of the underlying tokens they provide or (2) it's determining the amount of the underlying tokens to transfer to them for returning a certain amount of shares, it should round _down_.\n\n- If (1) it's calculating the amount of shares a user has to supply to receive a given amount of the underlying tokens or (2) it's calculating the amount of underlying tokens a user has to provide to receive a certain amount of shares, it should round _up_.\n\nThe only functions where the preferred rounding direction would be ambiguous are the `convertTo` functions. To ensure consistency across all EIP-4626 Vault implementations it is specified that these functions MUST both always round _down_. Integrators may wish to mimic rounding up versions of these functions themselves, like by adding 1 wei to the result.\n\nAlthough the `convertTo` functions should eliminate the need for any use of an EIP-4626 Vault's `decimals` variable, it is still strongly recommended to mirror\nthe underlying token's `decimals` if at all possible, to eliminate possible sources of confusion and simplify integration across front-ends and for other off-chain users.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#security-considerations","designImplication":"Do not use a preview as a market-price or safety badge; warn users when a quote is only a transaction estimate and surface stale/manipulated-rate risk where relevant."},{"id":"preview-pairing","constraint":"Each preview method should be used for its corresponding transaction operation, not treated as interchangeable.","appliesTo":"application","normativity":"rationale","specQuote":"The `convertTo` functions serve as rough estimates that do not account for operation specific details like withdrawal fees, etc.\nThey were included for frontends and applications that need an average value of shares or assets, not an exact value possibly including slippage or other fees.\nFor applications that need an exact value that attempts to account for fees and slippage we have included a corresponding `preview` function to match each mutable function. These functions must not account for deposit or withdrawal limits, to ensure they are easily composable, the `max` functions are provided for that purpose.","specSection":"Rationale","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#rationale","designImplication":"Pair deposit with previewDeposit, mint with previewMint, withdraw with previewWithdraw, and redeem with previewRedeem in copy and confirmation UI."},{"id":"non-transferable-shares","constraint":"A vault may reject transfers of its shares when the vault is non-transferable.","appliesTo":"application","normativity":"normative","specQuote":"If a Vault is to be non-transferrable, it MAY revert on calls to `transfer` or `transferFrom`.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#specification","designImplication":"Only show share-transfer controls when the deployed vault supports them, and explain a non-transferable share state instead of presenting a transfer that will fail."},{"id":"permit-share-approval","constraint":"A vault may implement EIP-2612 to simplify share approvals.","appliesTo":"application","normativity":"normative","specQuote":"EIP-4626 tokenized Vaults MAY implement [EIP-2612](./eip-2612.md) to improve the UX of approving shares on various integrations.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#specification","designImplication":"Offer a permit-based approval path when the vault supports it, while keeping the ordinary approval path available and clearly labeling the signature request."},{"id":"total-assets-compounding","constraint":"totalAssets should include compounding yield.","appliesTo":"application","normativity":"normative","specQuote":"SHOULD include any compounding that occurs from yield.","specSection":"Specification > Methods > totalAssets","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#totalassets","designImplication":"Treat a displayed total-assets or vault-value figure as including compounded yield when provided, and avoid implying that a raw principal balance is the whole managed value."},{"id":"convert-average-user","constraint":"Conversion methods may report an average-user price rather than a per-user price.","appliesTo":"application","normativity":"normative","specQuote":"This calculation MAY NOT reflect the \"per-user\" price-per-share, and instead should reflect the \"average-user's\" price-per-share, meaning what the average user should expect to see when exchanging to and from.","specSection":"Specification > Methods > convertToShares","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#converttoshares","designImplication":"Label conversion results as average estimates, not account-specific guaranteed output, and pair them with the operation-specific preview before confirmation."},{"id":"preview-deposit-slippage","constraint":"An unfavorable gap between convertToShares and previewDeposit SHOULD be treated as slippage or another loss condition.","appliesTo":"application","normativity":"normative","specQuote":"Note that any unfavorable discrepancy between `convertToShares` and `previewDeposit` SHOULD be considered slippage in share price or some other type of condition, meaning the depositor will lose assets by depositing.","specSection":"Specification > Methods > previewDeposit","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#previewdeposit","designImplication":"Call out an unfavorable preview-versus-conversion gap as a possible loss before the user confirms a deposit."},{"id":"preview-mint-slippage","constraint":"An unfavorable gap between convertToAssets and previewMint SHOULD be treated as slippage or another loss condition.","appliesTo":"application","normativity":"normative","specQuote":"Note that any unfavorable discrepancy between `convertToAssets` and `previewMint` SHOULD be considered slippage in share price or some other type of condition, meaning the depositor will lose assets by minting.","specSection":"Specification > Methods > previewMint","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#previewmint","designImplication":"Call out an unfavorable preview-versus-conversion gap as a possible loss before the user confirms a share-targeted mint."},{"id":"preview-withdraw-slippage","constraint":"An unfavorable gap between convertToShares and previewWithdraw SHOULD be treated as slippage or another loss condition.","appliesTo":"application","normativity":"normative","specQuote":"Note that any unfavorable discrepancy between `convertToShares` and `previewWithdraw` SHOULD be considered slippage in share price or some other type of condition, meaning the depositor will lose assets by depositing.","specSection":"Specification > Methods > previewWithdraw","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#previewwithdraw","designImplication":"Call out an unfavorable preview-versus-conversion gap as a possible loss before the user confirms a withdrawal."},{"id":"preview-redeem-slippage","constraint":"An unfavorable gap between convertToAssets and previewRedeem SHOULD be treated as slippage or another loss condition.","appliesTo":"application","normativity":"normative","specQuote":"Note that any unfavorable discrepancy between `convertToAssets` and `previewRedeem` SHOULD be considered slippage in share price or some other type of condition, meaning the depositor will lose assets by redeeming.","specSection":"Specification > Methods > previewRedeem","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#previewredeem","designImplication":"Call out an unfavorable preview-versus-conversion gap as a possible loss before the user confirms a share redemption."},{"id":"withdraw-allowance-check","constraint":"The vault implementation SHOULD check that msg.sender can spend the owner's funds, convert assets to shares, and check the resulting share allowance.","appliesTo":"account-implementation","normativity":"normative","specQuote":"SHOULD check `msg.sender` can spend owner funds, assets needs to be converted to shares and shares should be checked for allowance.","specSection":"Specification > Methods > withdraw","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#withdraw","designImplication":"For delegated withdrawals, show whose funds are being spent, what allowance is needed, and whether approval must happen before the withdrawal."},{"id":"redeem-allowance-check","constraint":"The vault implementation SHOULD check that msg.sender can spend the owner's funds using allowance.","appliesTo":"account-implementation","normativity":"normative","specQuote":"SHOULD check `msg.sender` can spend owner funds using allowance.","specSection":"Specification > Methods > redeem","specUrl":"https://ercs.ethereum.org/ERCS/erc-4626#redeem","designImplication":"For delegated redemptions, make the owner, spender, share allowance, and approval step explicit before signing."}],"keyTakeaways":["ERC-4626 = standard vault interface","ALWAYS show asset value, not just share balance","Offer deposit or withdrawal actions only within current contract limits and integrated capabilities","Show measured profit or loss against deposited amounts without promising yield","Display fees/slippage before withdrawal"],"technicalNotes":"ERC-4626 extends ERC-20 (shares are tokens). Key functions: deposit(assets, receiver), mint(shares, receiver), withdraw(assets, receiver, owner), redeem(shares, receiver, owner). convertToShares/convertToAssets are ideal caller-independent rates; previewDeposit/previewMint/previewWithdraw/previewRedeem model the corresponding transaction and include applicable fees. Limits come from maxDeposit, maxMint, maxWithdraw, and maxRedeem. Preview methods do not include the max-method limits or guarantee execution. The base interface does not define a withdrawal queue, a recovery deadline, APY data, or built-in user slippage parameters; integrations must provide any extra protection or asynchronous flow.","sources":[{"label":"Monad reserve-balance rules","url":"https://docs.monad.xyz/developer-essentials/reserve-balance","type":"reference"},{"label":"Official ERC-4626 specification","url":"https://ercs.ethereum.org/ERCS/erc-4626","type":"official-spec"}],"lastUpdated":"2026-09-18","lastReviewed":"2026-09-18"},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-4626","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-4626","type":"discussion"},{"label":"Monad reserve-balance rules","url":"https://docs.monad.xyz/developer-essentials/reserve-balance","type":"reference"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-4626","markdown":"https://www.eipsfordesigners.com/standards/ERC-4626/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-4626/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-4626","official":"https://ercs.ethereum.org/ERCS/erc-4626","discussion":"https://ethereum-magicians.org/search?q=ERC-4626"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}