📈 GH Trending Explorer 🎲 Surprise me

← all repos

morpho-org / vault-v2

git clone https://github.com/morpho-org/vault-v2.git 2026-10-12 · 10d ago 🔥 on GitHub Trending today

Morpho's non-custodial vault protocol

+0
stars, 24h · #15,468
+1
stars, 7 days · #15,802
+~0
stars, 30 days · #22,372
108
★ total · +1% this week
79
forks · 7 open issues

Star history (as recorded here)

2026-10-20 · 108 ★ 2026-10-22 · 108 ★
LanguageSolidity
LicenseGPL-2.0
Created2024-10-01 (2y ago)
Last pushtoday
Watchers7
OwnerOrganization

Seen on GitHub Trending

  • 2026-10-22 — #7 weekly in solidity · +1 ★
  • 2026-10-21 — #5 weekly in solidity · +1 ★
  • 2026-10-20 — #5 weekly in solidity · +1 ★

Links

README excerpt
# Vault V2
Vaults V2 enables anyone to create non-custodial vaults that allocate assets into different markets.
Depositors of Vault V2 earn from the underlying markets without having to actively manage their position.
The curation of deposited assets is handled by a set of different roles (owner, curator and allocators).
The VaultV2Factory deploys instances of Vaults V2.
All the contracts are immutable.
## Overview
### Adapters
Vaults allocate assets to underlying markets via separate contracts called adapters.
They hold positions on behalf of the vault.
Adapters are also used to know how much these investments are worth (interest and loss realization).
An adapter registry is used to constrain which adapters a vault can have and add.
This is notably useful when abdicated (see timelocks), to ensure that a vault will forever supply into adapters authorized by a given registry.
The following adapters are currently available:
- Morpho Market V1 Adapter V2 (Morpho Blue).
- Morpho Vault V1 Adapter.
- Midnight Adapter. WIP
### Caps
The funds allocation of the vault is constrained by an id-based caps system.
An id is an abstract identifier for a common risk factor of some positions (a collateral, an oracle, a protocol, etc.).
Allocation on markets with a common id is limited by absolute caps and relative caps.
Relative caps only constrain allocations, so they can be exceeded because of withdrawals from the vault.
### Liquidity
The allocator is responsible for ensuring that users can withdraw their assets at any time.
This is done by managing the available idle liquidity and an optional liquidity adapter.
Additionally, users can make use of the `forceDeallocate` function to withdraw from the vault if there are liquid markets, assuming that they are willing to pay the corresponding penalty.
Indeed, the permissionless `forceDeallocate` function allows anyone to move assets from an adapter to the vault's idle assets (meaning the vault token balance).
When users withdraw assets, the idle assets are taken in priority.
If there is not enough idle liquidity, liquidity is taken from the liquidity adapter.
When defined, the liquidity adapter is also used to forward deposited funds.
A typical liquidity adapter would allow deposits/withdrawals to go through a very liquid Morpho Blue market.
### Timelocks
Curator configuration changes are all timelockable (except `decreaseAbsoluteCap` and `decreaseRelativeCap`), meaning that doing an action requires submitting it first, and only when the timelock has passed it can be executed (by anyone).
This is useful notably to the non-custodial guarantees, but also in general if a curator wants to give guarantees about some configurations.
`increaseTimelock` should be used carefully, because decreaseTimelock is function-dependent: decreasing the timelock of a function is timelocked by the timelock of the function itself.
Also, a configuration can be _abdicated_, meaning that it won't be able to be set anymore, by calling `abdicat