Summary
The current InvestmentUniverse and its execution/price adapters assume synchronous ERC-4626 vault mechanics — deposits and redemptions settle atomically in a single transaction. This breaks for ERC-7540 vaults (e.g. Concrete, Lagoon) where settlement is deferred to a future valuation epoch.
Background
ERC-7540 extends ERC-4626 with a request → claimable → claimed lifecycle:
requestDeposit() — assets locked, request queued (Pending)
- Curator settles at next NAV valuation point (Claimable)
deposit() / redeem() — user claims shares or assets (Claimed)
Vaults like Lagoon (full-stack async vault infra) and Concrete (Earn v2) implement this pattern. Calling standard deposit() on them reverts by design — they require the async flow. These vaults also price shares at the settlement NAV, not at request time, making synchronous previewDeposit calls meaningless.
Problem
InvestmentUniverse asset allowlisting assumes any allowed asset can be atomically deposited into / redeemed from
- Orion's rebalancing engine calls execution adapters expecting synchronous settlement
- Price adapters call
previewDeposit / convertToAssets which revert on async vaults
- No state tracking for pending/claimable requests per vault asset
Proposed Approach
- ERC-7540 detection: Use
supportsInterface(IERC7540) on allowlisted assets to flag them as async
- AsyncExecutionAdapter: New adapter variant that calls
requestDeposit() / requestRedeem() and records the requestId on-chain for later settlement
- Claim settlement hook: A separate permissioned
settleAsyncRequests() function (called by keeper/curator) that calls deposit() / redeem() once requests become claimable
- Pending state accounting: Track locked assets and outstanding requests per vault to ensure NAV reporting stays accurate between request and claim
- Price adapter update: Guard
convertToAssets() calls with async detection; fall back to last accepted NAV from the vault's settlement event
References
Summary
The current
InvestmentUniverseand its execution/price adapters assume synchronous ERC-4626 vault mechanics — deposits and redemptions settle atomically in a single transaction. This breaks for ERC-7540 vaults (e.g. Concrete, Lagoon) where settlement is deferred to a future valuation epoch.Background
ERC-7540 extends ERC-4626 with a request → claimable → claimed lifecycle:
requestDeposit()— assets locked, request queued (Pending)deposit()/redeem()— user claims shares or assets (Claimed)Vaults like Lagoon (full-stack async vault infra) and Concrete (Earn v2) implement this pattern. Calling standard
deposit()on them reverts by design — they require the async flow. These vaults also price shares at the settlement NAV, not at request time, making synchronouspreviewDepositcalls meaningless.Problem
InvestmentUniverseasset allowlisting assumes any allowed asset can be atomically deposited into / redeemed frompreviewDeposit/convertToAssetswhich revert on async vaultsProposed Approach
supportsInterface(IERC7540)on allowlisted assets to flag them as asyncrequestDeposit()/requestRedeem()and records therequestIdon-chain for later settlementsettleAsyncRequests()function (called by keeper/curator) that callsdeposit()/redeem()once requests become claimableconvertToAssets()calls with async detection; fall back to last accepted NAV from the vault's settlement eventReferences