VAULT INFRASTRUCTURE

The Next Generation of Tokenized Vault Standards. Part 1

ERC-4626 gave DeFi a common interface for tokenized vaults, so wallets, aggregators, and protocols could integrate any vault the same way. But it standardizes only the simplest model: one asset, fungible shares, instant deposits and redemptions. As on-chain vaults start to resemble real investment funds — async settlement, multiple assets, lock-up periods — a new generation of ERCs is trying to standardize everything that happens around ERC-4626. Here is the emerging landscape, and what it means for anyone building on top of vaults.

Beyond ERC-4626

ERC-4626 was an important milestone for DeFi infrastructure. It introduced a common interface for tokenized vaults, letting wallets, aggregators, asset managers, and other protocols interact with a vault without building a bespoke integration for every implementation. That model works well for lending markets, yield-bearing tokens, and many DeFi vaults. It standardizes the simplest vault:

• The vault has one underlying ERC-20 asset.
• Investors receive fungible shares.
• Deposits and redemptions happen synchronously.
• The vault itself is normally also the share token.
• Assets and shares convert through a standard accounting interface.

It becomes less sufficient as tokenized vaults begin to resemble real investment funds. Private-credit strategies may not be able to return capital immediately. An institutional fund may process subscriptions once a day or once a week. A vault may accept several assets while issuing one common share token. Investors may need to cancel or transfer pending requests. A native-ETH vault needs different transfer mechanics from an ERC-20 vault. A new generation of ERCs is attempting to address exactly these requirements. (For pigi's working definition of "vault," see What is a Vault in crypto?)

A Final ERC does not automatically become widely used. Conversely, a Draft or even Stagnant proposal can still contain ideas worth implementing — a proposal can identify an important problem or reveal where vault infrastructure is heading, even if its exact interface never wins.

The emerging standards landscape

As of July 20, 2026, the most relevant standards around ERC-4626 vault operations are (each links to its full spec):

The statuses matter, but the standards are more useful viewed as parts of a larger architecture built outward from ERC-4626:

ERC-4626: basic tokenized vault
│
├── Safer synchronous interactions
│   └── ERC-5143: slippage protection
│
├── Restricted liquidity
│   └── ERC-6229: lock-in periods
│
├── Native assets
│   ├── ERC-7528: native-asset address convention
│   └── ERC-7535: native-asset ERC-4626 vaults
│
├── Multi-asset architecture
│   └── ERC-7575: multiple entry points + external shares
│
└── Asynchronous operations
    ├── ERC-7540: deposit and redemption requests
    ├── ERC-7887: request cancellation
    └── ERC-8161: transferable requests

1. ERC-7540: asynchronous vaults

ERC-4626 is optimized for atomic operations: a user calls deposit, receives shares, done. That assumption breaks for many strategies. A real-world-asset fund may need time to sell an underlying position. A private-credit vault may process redemptions only during defined liquidity windows. A cross-chain strategy may need to move assets back to the user's chain.

ERC-7540 extends ERC-4626 with asynchronous deposit and redemption requests — an implementation can make deposits async, redemptions async, or both. The request lifecycle has three principal states:

Request submitted
      ↓
   Pending      (assets/shares locked; not yet issued)
      ↓
  Claimable     (vault has processed the request)
      ↓
   Claimed      (user or operator calls deposit/mint/withdraw/redeem)

This is much closer to how a traditional fund works: an investor submits an order, it enters a processing queue, the fund determines the applicable valuation, the order settles, and only then does the investor receive shares or assets. ERC-7540 is therefore more than a small extension — it changes the vault interaction model from an immediate conversion into an order-management lifecycle.

Controllers and operators

ERC-7540 separates roles that are usually one address in a simple ERC-4626 call. The owner supplies the assets or shares; the controller owns and manages the request; an operator may be authorized to act on the controller's behalf. That separation is useful for institutional systems, custodial structures, smart accounts, routers, and fund administrators — the wallet holding assets need not be the account that processes and claims the request.

Why this matters for infrastructure

Supporting ERC-7540 is more than adding two transaction types. An indexer or portfolio app has to track deposit and redemption requests, request IDs, controllers and operators, pending balances, claimable balances, completed claims, and the exchange rate applied when a request is fulfilled. Two details make this harder:

• The standard deliberately does not require an event for the Pending → Claimable transition (it may happen via internal batching or a timestamp). So providers may need to query vault state rather than reconstruct the lifecycle from events alone.
• The final conversion rate may not be known when the request is submitted — the shares or assets received depend on the vault's accounting state when it becomes claimable. A UI should not present an async request as though it were a settled ERC-4626 transaction.

This is the same class of problem that makes on-chain vault data hard in general — see our article on building a DeFi vaults indexer.

2. ERC-7887: cancellation

Once a vault has pending requests, a new question appears: what happens when an investor no longer wants to wait? ERC-7540 does not include cancellation. ERC-7887 (Draft) proposes an extension that lets pending deposit and redemption requests be cancelled — and, importantly, cancellation is not necessarily immediate. It has its own lifecycle:

Cancellation requested
      ↓
Pending cancellation
      ↓
Claimable cancellation
      ↓
Assets or shares reclaimed

The vault may already have begun processing the original request — assets may be allocated, liquidity may need recovering, or the request may be part of a larger settlement batch. So ERC-7887 treats cancellation as another asynchronous financial operation rather than a simple reversal. For infrastructure, that means a request can be pending normally, pending cancellation, claimable for settlement, claimable for cancellation, claimed through the original request, or claimed through the cancellation process — states that must be represented clearly.

3. ERC-8161: transferable requests

ERC-8161 (Last Call) goes one step further: it lets pending ERC-7540 deposit and redemption requests be transferred from one controller to another. Deposit- and redemption-request transferability are independently optional, and only the pending balance moves — claimable balances stay with the original controller.

At first glance this looks like an account-management feature. The more interesting implication is that a pending vault request starts to behave like a financial position of its own. A transferable redemption request could be sold to another investor at a discount, transferred to a liquidity provider, moved into a different custody structure, or used in an OTC settlement — creating the possibility of secondary liquidity for assets still waiting to be redeemed.

Pricing such requests is hard. Unlike ordinary shares, a pending request has no canonical on-chain conversion rate — its value depends on the expected settlement date, the future exchange rate, liquidity conditions, and the probability of successful processing. ERC-8161 is experimental, but the idea is important: async fund orders may become composable on-chain objects.

4. ERC-7575: multiple entry points

ERC-4626 assumes one underlying ERC-20 asset, and the vault contract is normally also the share token. That gets restrictive when a fund wants to accept several subscription assets — say USDC, USDT, and DAI — while issuing one common share token. ERC-7575 (Final) separates the asset-specific entry point from the share token:

USDC entry-point vault ─┐
USDT entry-point vault ─┼── Common share token
DAI  entry-point vault ─┘

Each entry point represents one underlying asset, and multiple entry points connect to the same external ERC-20 share token. The standard adds a share() function to identify the share token, plus an optional reverse lookup. That changes a core assumption:

ERC-4626:  one vault contract = one asset = one share token
ERC-7575:  one logical vault = many entry points + many assets + one share token

Infrastructure now has to distinguish the logical investment product, the individual asset entry points, the underlying assets, and the common share token. Treating every contract as a separate vault would make the same fund appear several times in a portfolio. Note that ERC-7540 requires support for ERC-7575 (including share() and ERC-165 detection) — together they move the ecosystem away from the assumption that one contract address represents the entire fund.

5. ERC-6229: lock-in periods

ERC-6229 (Draft) addresses vaults where deposits and withdrawals are unavailable during defined lock-in periods. It introduces vault rounds: during a locked round users cannot execute ordinary deposits or withdrawals, but operations can be scheduled for later processing. This suits epoch-based strategies, structured products, credit funds, fixed-term investments, and any vault that needs predictable periods without investor flows.

Lock-in periods and async requests solve related but distinct problems: ERC-7540 models an individual request that stays pending until processed; ERC-6229 models the vault itself moving between locked and unlocked periods. A vault could use both — operating in rounds while also processing requests asynchronously. The broader lesson is that continuous, permissionless liquidity is not a universal property of tokenized funds; as less-liquid strategies move on-chain, lock-ups and dealing windows become first-class product characteristics.

6. ERC-5143: slippage protection

ERC-4626's preview functions estimate shares or assets, but the standard deposit/mint/withdraw/redeem methods accept no explicit minimum-output or maximum-input limits. That is a problem when the exchange rate or limits change between preparing and executing a transaction. ERC-5143 (Stagnant) proposes overloaded methods with slippage parameters — the same protection used in DEX swaps:

Deposit 1,000 assets
Receive at least 995 shares
Otherwise revert

ERC-5143 is Stagnant, so it should not be treated as an emerging consensus standard — but the underlying problem is real, and protocols frequently add equivalent safeguards through routers or proprietary deposit functions. It is a good example of a proposal whose design goal stays relevant even without interface-level adoption.

7. ERC-7535 & ERC-7528: native assets

ERC-4626 expects an ERC-20 underlying. Native ETH implements no ERC-20 transfers or approvals, so a vault that accepts ETH directly cannot follow ERC-4626 as-is. ERC-7535 (Final) adapts ERC-4626 for native ETH (or another chain's native asset): it keeps the function interface as much as possible but makes deposit and mint payable and uses msg.value to transfer the underlying.

ERC-7528 (Final) provides the companion address convention. Where native ETH must appear in a field that normally holds an ERC-20 address, the standard uses:

0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE

That lets contracts, APIs, events, and data providers represent ETH and ERC-20 assets through one consistent data model. These standards are narrower than ERC-7540 or ERC-7575, but they solve a recurring integration problem — especially for native-asset staking vaults where forcing users to wrap ETH first adds friction. Native ETH does raise extra security and accounting considerations (reentrancy, forced ETH transfers, msg.value vs ERC-20 transfer mechanics), and ERC-7535 itself recommends weighing whether wrapped ETH is simpler for general-purpose integrations.

8. Who is building this today?

Standards on paper are one thing; production code is another. Several vault-infrastructure teams already ship these capabilities — sometimes as the ERC interface itself, more often as their own mechanism solving the same problem. Here is a snapshot of three: IPOR (Fusion), Veda (BoringVault), and Rethink Finance.

Assessment as of July 2026, based on public documentation and source code. "—" means no public implementation evidence was found — not necessarily that the capability is absent. IPOR's Plasma Vaults are ERC-4626 with scheduled (async-style) withdrawals; Veda's BoringVault uses a custom Teller / Atomic Queue with share-lock periods.

Keep reading: The Next Generation of Tokenized Vault Standards. Part 2