ERC-7540 vaults
The vault standard that makes everything else possible.
What ERC-7540 is:
A token standard for asynchronous vaults.
ERC-4626 (the predecessor) is synchronous: deposit and get shares instantly, redeem and get assets instantly. That works for lending markets and AMMs, not for actively managed strategies with open positions that can't be deployed or unwound on the spot.
ERC-7540 adds asynchronous flows. Deposit becomes two steps: request, then fulfillment when the strategy is ready. Same for redemption. Pending requests are tracked and fulfilled in batches.
Daily settlement for deposits. Monthly windows for redemptions. Fits the platform exactly.
How an allocation works:
You call requestDeposit on the vault contract, transferring USDC from your wallet into the vault's holding area. The vault records your pending deposit on-chain.
At daily settlement, the asset manager calls fulfillDeposit. Pending deposits are processed. USDC moves into the SMA at the custodian. Shares are issued at prevailing NAV per share.
You hold shares. Your USDC is in the SMA, where the asset manager trades it.
How a redemption works:
You call requestRedeem on the vault contract with the share amount you want to redeem. The vault records the request and reserves your shares.
At the monthly redemption window, the asset manager calls fulfillRedeem. The asset manager has been unwinding positions to free up USDC. USDC moves from the SMA back to the vault and is distributed to redeemers at the end-of-window NAV per share.
You now hold USDC. Your shares are burned.
What you can see on-chain:
The vault exposes a public interface. Anyone can query: current NAV per share, total shares outstanding, aggregate pending deposits and redemptions, recent settlement history. For your address: share balance, pending deposits, pending redemptions.
All native to ERC-7540. No custom RPC methods.
What governance can change:
A small set of vault parameters: the platform fee receiver address and the asset manager fee receiver address.
Each change requires the standard governance flow: timelocked proposal, optional guardian veto, execution after timelock expires. Detail in Self-custody model.
What governance cannot change:
- The custody arrangement. The vault sends and receives USDC to/from the SMA at the custodian, configured at deployment.
- Share issuance and redemption arithmetic. The math is in the contract, not parameterised.
- Your right to redeem. The redemption window opens on its on-chain schedule. Governance cannot close it.
Why ERC-7540 and not a custom standard:
Three reasons.
It's a standard. Wallets, explorers, indexers, and accounting tools understand it out of the box.
Right invariants. Request separated from fulfillment. Pending state on-chain. Clean redemption flow. Nothing to invent.
Ecosystem-reviewed. Audited at spec level by multiple firms. The platform's implementation audited separately. Two layers reduce bug risk.
What the platform adds on top:
Minimal additions:
- Fee accrual and settlement. Platform and insurance fees accrue into NAV; performance fee crystallises at scheduled events.
Documented and audited. They extend ERC-7540 without departing from it.
Vault deployment:
One vault per strategy, deployed when approved. The platform deploys it, not the asset manager, preventing non-standard logic.
Contract is verified on Base. Source code public. Deployment parameters (limits, thresholds, fees) visible on-chain.
Vault addresses:
Each vault has its own contract address on Base, published on the strategy detail page. Technical users can interact directly via the contract interface. Documented in Smart contract addresses.