Not All Vaults Are Created Equal
A practical framework for reading what constrains a vault strategy, from protocol-native markets to managed strategies and tokenized fund wrappers.
"Vault" is one of the most overloaded words in crypto. We are guilty of this too.
When vaults.fyi started, the word mostly meant ERC-4626 tokenized vaults. That was the clean version: a standard interface for deposits, shares, withdrawals, and accounting. Since then, our coverage has expanded to Aave pools, Morpho markets, yield-bearing stablecoins, LSTs, private credit, and managed strategies that have expanded the original "vault" definition.
The vault label stuck because it is useful shorthand. It also hides a lot.
Onchain metrics can show a lot: asset, network, TVL, curator, fees, capacity, and 30d trailing APY, max drawdown (MDD). They only go so far. Understanding the strategy constraint often means looking at smart contract permissions, governance controls, offchain reporting, or custody policy.
This post maps the vault spectrum from code-constrained protocols to discretionary fund wrappers. The practical question is what prevents a manager from acting outside the stated strategy.

The Vault Spectrum
The spectrum runs from code-constrained to discretionary. The categories are not hard borders. Some protocols can produce vaults that sit in different places depending on configuration.
Protocol-native
The protocol and its parameters define what can happen.
Check: approved markets, caps, timelocks, veto roles, onchain NAV.
Actively managed
The manager has discretion, often inside verified execution bounds.
Check: action verification, permission updates, custody rails, reward APY.
Fund wrappers
The contract handles shares and reporting. Strategy execution happens elsewhere.
Check: asset control, NAV source, redemption terms, verification coverage.
1. Protocol-native vaults
Protocol-native vaults are the most constrained. The strategy is defined by the protocol's logic plus parameters that can change through visible, bounded processes.
The exact mechanics differ, but the central idea is similar: the vault cannot execute arbitrary strategy decisions. A curator or operator may set parameters, select markets, manage caps, or configure risk settings. The code enforces the perimeter.
Morpho V1 is a clean example. Curators can choose approved Morpho Blue markets and set supply caps. Cap increases are timelocked. Capital can move within the approved market set. The curator cannot move funds to an external wallet or use an unrelated protocol.
Morpho Vault V2 expands the strategy surface with adapters, which can connect vaults to external yield sources. That moves the model toward a broader mandate, but the same question still applies: which adapters are approved, what caps exist, who can change them, and how much notice do depositors get?
For depositors, the key checks are:
- Which markets, adapters, or modules can the vault use?
- Are cap increases timelocked?
- Who can revoke or veto pending changes?
- Can the curator move assets outside the protocol-defined path?
- Is NAV computed from onchain market state?
Our advancedAnalytics endpoint tracks allocations inside Morpho vaults through the composition field. For these vaults, allocation data can show where capital is deployed across approved adapters or markets, which makes the "what can this vault use?" question easier to monitor over time.
API reference: Advanced vault analytics, POST /alpha/advanced-analytics.
2. Actively managed vaults
Actively managed vaults give managers more room to make allocation decisions. Strategy scope can span multiple protocols, chains, or execution venues. The important distinction is whether each action is still constrained onchain.
These protocols use different control systems. Veda and Aera rely on Merkle proofs that approve specific contracts, functions, and arguments. Makina verifies operator instructions against a committed instruction set. IPOR Fusion uses immutable adapter contracts called Fuses. Mellow routes curator actions through verifier contracts, with granular checks at the subvault level.
The common pattern is bounded discretion. The manager decides where to deploy within an approved universe. The contract rejects actions outside that universe.
This tier is where protocol-level labels become less reliable. A Lagoon vault using Zodiac roles can have meaningful onchain constraints. A Lagoon vault using MPC custody has a different enforcement model. Upshift lending pool vaults and Upshift multi-asset vaults can also rely on different constraint mechanisms.
For depositors, the key checks are:
- Is each manager action verified onchain?
- Are approved contracts, functions, and arguments visible?
- Who can update the approved action set?
- Is there a timelock or veto process for permission changes?
- Does any part of the strategy depend on custodial rails or offchain venues?
- How are fees, rewards, and reported APY separated?
3. Fund wrappers and credit structures
In fund wrappers and credit structures, the smart contract is primarily an accounting and access layer. It may handle share issuance, subscriptions, redemptions, transfer rules, and NAV publication. The underlying strategy is executed elsewhere.
The point is not to rank these models. It is to understand what each one asks depositors to trust. A token representing exposure to a short-duration Treasury ETF has a different trust model than a token representing a discretionary market-neutral strategy with some opaque centralized exchange exposure. Both can sit inside tokenized fund infrastructure. The wrapper does not make the underlying strategy equivalent.
Pareto vaults enforce credit structure: lending cycles, tranching, KYC gating, and borrower terms. They do not enforce what the borrower does with capital after receiving a loan.
Accountable takes a different approach. It does not try to constrain every manager action through code. It focuses on verified transparency through cryptographic proofs, trusted execution environments, and live connections to custodians and exchanges.
For depositors, the key checks are:
- Who controls the underlying assets?
- Is the investment mandate enforced by code, contract, custody policy, or reporting?
- Who calculates NAV?
- How often is NAV updated?
- What portion of positions is verifiable onchain?
- What are the redemption terms, gates, and capacity limits?
- Are rewards, fees, and base yield reported separately?
What A Vault Standard Does And Does Not Tell You
The original technical meaning of a vault was narrower than the way the word is used today. ERC-4626 standardized the interface for tokenized vaults: deposits, withdrawals, shares, redemptions, and accounting.
That standard is useful. It tells an app how to deposit assets, redeem shares, and calculate conversions. It does not define the investment strategy.
ERC-4626 does not say where assets can be deployed, who can rebalance them, how NAV is determined, or whether a manager can move capital offchain. It standardizes the wrapper, not the trust model.
That is why the vault label can hide more than it reveals. The interface can look similar while the actual constraints are very different.
The Three Checks That Matter
The vault spectrum is easiest to understand through three checks.
Execution enforcement
Execution enforcement asks whether code can prevent the manager from taking an action.
In a tightly constrained lending vault, a curator may be able to add a market, set a cap, or rebalance between approved markets. The curator cannot send vault assets to an arbitrary wallet or interact with an unapproved protocol because the contract will not execute that action.
In a discretionary structure, the onchain contract may handle deposits, shares, redemptions, and NAV reporting while capital is managed elsewhere. Constraints come from governance, custody policy, legal agreements, operating process, and reputation.
Strategy scope
Strategy scope asks where the vault can deploy capital.
Some vaults are narrow by design. They allocate within one protocol or one asset class. Others can operate across lending, liquidity provision, restaking, basis trades, credit, or offchain venues.
Broad scope is not automatically bad. It can be the source of differentiated returns. It does change the evaluation. The wider the mandate, the more you need to understand how the strategy is bounded, who sets those bounds, and how quickly those bounds can change.
NAV determination
NAV determination asks where the share price comes from.
In protocol-native vaults, NAV can be computed from onchain market state. In managed vaults, NAV may depend on oracle systems, price reports, or position accounting across multiple venues. In fund wrappers and credit structures, NAV can be reported by an administrator, manager, or verification process.
The question is not whether a reported NAV is useful. The question is what you are trusting when you rely on it.
How To Read A Vault Before A Deposit
The practical evaluation starts with visible data, then moves into trust assumptions.
Start with the visible terms: asset, network, TVL, curator, fees, capacity, past price per share performance, max drawdown (MDD), and APY across multiple timeframes (1/7/30d avg).
Next, check who controls strategy changes. A curator adjusting caps inside a protocol-defined market set is different from an operator with broad custody permissions. Look for timelocks, veto roles, emergency powers, and whether depositors can exit before a material change takes effect.
Then check how NAV is determined. If NAV comes directly from onchain market state, the main questions are market data, oracle assumptions, and protocol accounting. If NAV is reported by an administrator or manager, the main questions are verification, frequency, independence, and redemption mechanics.
Finally, check capacity. A vault near capacity may not accept new deposits or may behave differently as it grows. A small vault with high APY may depend on incentives, temporary market imbalance, or a narrow opportunity that cannot absorb much capital.
None of these checks make a vault good or bad by themselves. They make the tradeoff legible.
Why This Matters
The useful context goes beyond headline APY: historical yield, TVL, reward composition, fees, curator details, capacity, positions, risk signals, NAV source, and protocol-specific metadata.
The vault spectrum gives a vocabulary for assessing different opportunities. A protocol-native vault, an actively managed vault, and a tokenized fund interest can all be useful. They ask you to trust different things.
The word vault will keep being used across all of them. The better question is what sits underneath it.
Before supplying funds, useful questions to ask are:
- what constrains the strategy?
- how is NAV determined?
- who can change the rules?
These will provide clarity in vault assessments.
Compare The Vault, Not The Label
The spectrum is not a ranking. It is a way to make the trust model legible before capital moves.
vaults.fyi is built around that job: standardize the surface area for yield products while preserving the protocol-specific details that matter. A vault page should make APY windows, TVL, curator, fees, capacity, rewards, positions, and risk signals easy to scan, then give enough context to understand what sits underneath.
That is the difference between comparing labels and comparing vaults. Explore the full DeFi yield landscape on vaults.fyi.
Compare vaults by what matters underneath
Use vaults.fyi to get data on APY, TVL, curators, fees, rewards, capacity, positions, risk signals, and protocol-specific context across DeFi protocols.
Sign up for the API