Morpho Vault V2 implements a flexible gate system that allows curators to control who can interact with the vault. Gates are external contracts that implement specific interfaces to permit or deny operations.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/morpho-org/vault-v2/llms.txt
Use this file to discover all available pages before exploring further.
Overview
Gates provide granular access control over four distinct operations:- Share transfers - Control who can send and receive vault shares
- Asset operations - Control who can deposit and withdraw vault assets
Gates are set by the curator and changes go through timelocks, ensuring users have time to exit before new restrictions take effect.
Gate types
Vault V2 defines four independent gate types:Receive shares gate
- Controls permission to receive vault shares
- Applied on:
deposit,mint,transfer,transferFrom - Can lock users out of getting back shares deposited on other contracts
Send shares gate
- Controls permission to send vault shares
- Applied on:
withdraw,redeem,transfer,transferFrom,forceDeallocate - Can lock users out of exiting the vault
Receive assets gate
- Controls permission to receive assets when withdrawing from the vault
- Applied on:
withdraw,redeem - The vault itself (
address(this)) is always allowed to receive assets, regardless of gate configuration - Can lock users out of exiting the vault
Send assets gate
- Controls permission to deposit assets into the vault
- Applied on:
deposit,mint - Not critical (cannot block users’ funds already in the vault)
- Can be used to gate new deposits
Implementation example
Here’s a complete gate implementation that works with Bundler3:This example uses a single whitelist for all permissions and supports Bundler3 for delegated operations on behalf of whitelisted users.
Gate configuration
Gates are set by the curator using timelocked functions:address(0).
Gate enforcement
The vault checks gates using internal view functions:Design requirements
- Never revert - Gates must return
trueorfalse, never revert - Low gas consumption - Gates should not consume excessive gas
- Predictable behavior - Gate logic should be transparent and deterministic
Use cases
Whitelisting
Restrict vault access to approved addresses:KYC/AML compliance
Integrate with identity verification services:Jurisdictional restrictions
Block addresses from restricted jurisdictions:Delegated access with Bundler3
Allow whitelisted users to interact via Bundler3:Security considerations
Gate vulnerabilities
- Locked funds - Improperly designed send gates can permanently lock user funds
- Centralization risk - Gate owners control access; consider time delays for changes
- Gas griefing - Gas-heavy gates can DOS vault operations
- Upgradeable gates - If gates are upgradeable, users face additional trust assumptions
Best practices
For vault curators:
- Audit gate contracts thoroughly before deployment
- Set appropriate timelocks for gate changes
- Test gate behavior under all edge cases
- Consider gradual rollout for new gate implementations
- Document gate logic clearly for users
- Understand gate restrictions before depositing
- Monitor pending gate changes via timelock events
- Verify gate contracts are not upgradeable or have appropriate governance
- Exit before problematic gate changes take effect
Emergency considerations
Even with restrictive gates:forceDeallocatestill allows in-kind redemptions (subject to send shares gate)- Sentinels cannot modify gates (only curator can)
- Gate changes go through timelocks, allowing exit window
Initial configuration
At vault creation, all gates are set to
address(0) (disabled), meaning anybody can interact with the vault. To restrict access from the start, batch gate configuration with vault creation using multicall.