Beyond Instant Settlement: The Standard for Asynchronous Vaults

The default assumption in DeFi is that everything happens atomically. Deposit tokens, receive shares in the same transaction. Redeem shares, receive tokens back instantly. ERC-4626 codified this into the standard vault interface, and it works well for liquid onchain assets.

But it doesn’t work for most of the offchain financial products that are now moving onchain.

Real-world assets don't settle in 12 seconds. Traditional settlement is confined to banking hours NAV calculations require offchain data and auditor sign-off. Cross-chain asset transfers involve bridge latency. Compliance checks happen outside the transaction. Every one of these realities breaks the synchronous model.

Asynchronous settlement is not a special case. Even for products where synchronous operations are technically possible, first-come-first-serve redemptions create an inherent unfairness: the fastest redeemers get the best price and everyone else absorbs the loss. Epoch-based processing ensures all investors in the same batch receive the same price and the same pro-rata allocation. For institutional-grade asset management, async is the baseline.

Where async is non-negotiable

Three categories of onchain asset management fundamentally require asynchronous flows.

On/off-ramping funds. Moving capital between fiat and onchain involves bank transfers, compliance checks, and settlement windows that operate on T+1 or T+2 timelines. A vault that wraps a fund with fiat-denominated subscriptions cannot process deposits atomically. The investor submits a request, the fiat settles, the NAV updates, and only then can shares be issued. The same applies in reverse: redemptions trigger fiat payouts that take days to clear.

Allocating to illiquid strategies. A portfolio vault that invests in private credit, real estate debt, or structured products cannot instantly liquidate positions to fund redemptions. The manager needs time to unwind positions, negotiate exits, or wait for loan maturities. Synchronous redemptions would either require massive idle reserves (destroying yield) or create bank-run dynamics where early redeemers drain the pool.

Multichain asset management. When a vault manages assets across multiple chains, every rebalancing operation involves cross-chain messaging with bridge latency. An investor depositing on Arbitrum while the pool's reserves sit on Ethereum mainnet cannot receive shares until the deposit message reaches the hub and the hub sends back a fulfillment.

‍We've been here before

Centrifuge deployed fully asynchronous vault contracts on Ethereum mainnet in November 2020 through Tinlake. New Silver, a US-based real estate bridge lender, tokenized fix-and-flip loans and financed them through MakerDAO. Each loan was represented as an NFT, locked into a Tinlake pool with senior and junior tranches, and the senior tranche (DROP tokens) served as collateral in MakerDAO's first real-world asset vault.

The underlying assets ruled out atomic settlement. Borrower repayments follow real-world timelines, not block times. NAV calculations require offchain data. Investors can't redeem instantly when the underlying assets are illiquid six-month bridge loans. Epoch-based settlement was the only model that worked. The Operator contract managed permissioned access to tranche-based pools where investors submitted supply and redeem orders that were queued, validated against memberlists, and fulfilled in batches once the pool's NAV was updated.

This was years before ERC-7540 existed as a standard. The pattern was born from operational necessity, not theoretical design. Epoch-based async processing was the only model that worked for real-world assets.

That experience directly informed ERC-7540, the asynchronous vault standard that Centrifuge co-authored and that was finalized in 2024.

How ERC-7540 extends ERC-4626

ERC-4626 defines four core operations: deposit, mint, redeem, and withdraw. All four are atomic. You call the function, assets move, shares move, done.

ERC-7540 splits each operation into two steps: request and claim. It adds new functions to the interface:

• requestDeposit(assets, controller, owner) transfers assets into the vault and registers a pending deposit request.
• requestRedeem(shares, controller, owner) locks shares and registers a pending redemption request.

Each request moves through three states: pending (submitted, awaiting processing), claimable (processed by the vault, ready to collect), and claimed (user has called deposit/mint or redeem/withdraw to finalize). Requests cannot skip the claimable state. The user always makes two explicit calls.

Critically, ERC-7540 extends ERC-4626 rather than replacing it. The same deposit, mint, redeem, and withdraw functions still exist, but in async mode they serve as the claim step rather than the full operation. Inspection functions like pendingDepositRequest and claimableRedeemRequest let integrators track request state. Any protocol that already integrates with ERC-4626 vaults can adapt to ERC-7540 with minimal changes.

The standard also adds an operator model (setOperator/isOperator) so that protocols and agents can manage requests on behalf of users, which is essential for automated strategies and smart contract integrations.

Sync deposits, async redemptions

Not every operation on every asset needs to be asynchronous. Centrifuge's vault stack supports a hybrid model through the SyncDepositVault: deposits execute instantly at the current share price (standard ERC-4626 behavior), while redemptions go through the async request/claim flow.

This hybrid makes sense for a common class of products. A tokenized money market fund can accept new capital immediately because the underlying assets are highly liquid and the NAV is stable. But redemptions may need manager approval, compliance verification, or time to liquidate positions. The SyncDepositVault gives investors the instant deposit experience they expect from DeFi while maintaining the operational controls that regulated funds require on the way out.

What's ahead

The async vault model is still evolving. Three developments are on the horizon.

Liquidity ladders. Combining sync and async flows within the same vault to offer tiered liquidity. Instant redemptions up to available reserves, async redemptions for larger amounts that require position unwinding. This gives investors predictable liquidity without forcing managers to hold excessive idle capital.

Transferable request positions. ERC-8161 extends ERC-7540 with the ability to transfer pending deposit and redeem requests to other addresses. This opens the door to secondary markets for redemption queues: an investor waiting for a large async redemption can sell that position rather than waiting for settlement. It also enables wallet migrations and protocol composition over pending positions.

Centrifuge Vaults v2. The next version of the stack introduces further customizability across the request lifecycle, building on the extension points covered in “The Programmable Vault Stack”.