Vault curation is the job of deciding and maintaining what a pooled onchain vault is allowed to hold: a curator selects the markets a vault may allocate into, sets exposure caps and risk parameters, and adjusts them as conditions change. Depositors keep custody through the vault contract. The curator holds configuration rights, not the assets.
Key takeaways
- A curator sets policy and limits. They do not custody deposits, cannot usually send assets to an address of their choosing, and have no control over the venues they allocate into.
- The economics are set at configuration time. Morpho's Vault V2 documentation permits a performance fee of up to 50% on yield and a management fee of up to 5% on total assets, making the fee a parameter rather than a market rate.
- Accountability is the unresolved part of the role. Losses reach depositors through the share price by default, and whether a curator owes anything beyond that depends on facts that live outside the contract.
Just the basics
A pooled vault holds everyone's deposits in one contract and lends or invests them together, and somebody has to decide where that money is allowed to go, how much may sit in any one place, and when to pull it back. That person or firm is the curator. They do not hold the money. They hold a set of permissions over a contract that holds the money, and most of those permissions take effect only after a waiting period so depositors can see a change coming and leave first. In return the curator takes a share of the yield, at a size written into the vault when it is created, and if the vault loses money, the loss shows up as a lower share price for every depositor at once.
What's in this article?
- What is vault curation?
- What does a curator control, and what do they not control?
- How does a curator get paid?
- The roles that constrain a curator
- Curator operations, step by step
- How should an allocator evaluate a curator?
- Who is accountable when a curated vault loses money?
- Where Railnet fits
- What should you do next?
What is vault curation?
Vault curation is risk configuration as a continuing job: choosing the venues a vault may use, sizing the exposure to each, and revising both as the underlying markets change. It is closer to a credit committee than to a trading desk. The curator's output is a set of limits rather than a set of trades.
The role exists because permissionless lending markets are isolated by design. A market for one collateral asset against one loan asset, with its own oracle and its own liquidation threshold, is easy to reason about and useless on its own to a depositor who wants a single place to put cash. Curation is the layer that assembles many isolated markets into one product a depositor can actually hold, and someone has to own the judgement calls that assembly requires.
Two clarifications, because both get muddled in the popular explanations. A curator is not a custodian, because the vault contract holds the assets and the curator's rights are permissions over configuration, and a curator is also not a portfolio manager in the traditional sense, because the instruments are protocol positions rather than securities and the decision surface is caps and eligibility rather than security selection.
What does a curator control, and what do they not control?
A curator controls eligibility, caps, fees and the shape of the allocation, and does not control the venues themselves, the price feeds those venues use, or the timing of a depositor's exit. That gap accounts for most of the risk in the role.
Under Morpho's Vault V2 role model, the curator is described as "the risk configuration role" and "configures adapters, caps, fees, and interest rate limits," with most of those actions subject to a timelock. A separate allocator role executes the allocation into enabled adapters. The split matters: the party that decides what is permitted is not the party that moves the money.
What sits outside the curator's control is longer than what sits inside it. Loan-to-value ratios, liquidation thresholds, interest rate models and oracle configuration belong to the underlying market or its governance, and a curator can decline to use a market and can cap the exposure to it. They cannot amend it. When a venue's governance changes a parameter, every vault allocated to that venue inherits the change without any curator having acted.
Liquidity is the other thing they do not control. A curator can hold a liquidity buffer and prefer venues with instant exits, but if borrowers have drawn a lending market to full utilisation, the vault cannot withdraw from it until repayments arrive. The buffer is the only part of that exit the curator sets.
How does a curator get paid?
The fee comes out of the vault, configured when the vault is set up and changeable only through the same timelocked process as any other parameter, and two types are common: a performance fee on yield, and a management fee on assets.
The caps are set by the vault framework rather than negotiated per deal. Morpho's Vault V2 documentation states a performance fee cap of up to 50% on yield and a management fee cap of up to 5% on total assets, with changes to fees and fee recipients subject to timelock. A ceiling that high means the framework declines to have an opinion, so the actual rate is a commercial decision an allocator has to check rather than assume.
A performance fee pays on yield, and yield rises with risk, while nothing in the fee mechanism pays for restraint and nothing claws back when a position that produced fees last quarter produces a loss this one. That is not an accusation against any curator; it is the shape of the incentive, and it is the reason serious allocators look at parameter history rather than at return.
The roles that constrain a curator
A curated vault splits authority across several roles so that no single party can both change the rules and move the money instantly, and while the names differ between frameworks the functions are consistent.
The table below uses Morpho's Vault V2 terminology, because it is documented and checkable, and other vault frameworks use different names for the same functions, most often for the fast-acting veto role. Read the functions, not the labels.
| Role | Can do | Cannot do | Timelocked? |
|---|---|---|---|
| Owner | Appoint the curator, add and remove sentinels, transfer ownership | Set strategy, allocate funds, execute timelocked actions, revoke pending proposals | No, owner actions are immediate |
| Curator | Propose adapters, caps, fees, interest rate limits, allocator changes; decrease caps | Execute allocations, manage sentinels, transfer ownership | Most curator actions are timelocked |
| Allocator | Allocate assets to enabled adapters, configure the liquidity adapter | Propose changes, manage roles, revoke proposals | No, for its core function |
| Sentinel | Revoke pending proposals, deallocate assets, decrease caps, execute proposals after the timelock expires | Propose changes independently, manage roles, set strategy | No, the point of the role is speed |
The timelock is the depositor's actual protection, and its length is a parameter like any other: Morpho's Vault V2 makes it configurable from zero to three weeks, with some timelocks able to be made permanent through abdicate. Raising an allocation cap is timelocked. Decreasing one is not, and can be executed immediately by a curator or a sentinel.
The asymmetry is the correct design and it is also the thing to check. Risk can always be reduced immediately and can only be increased slowly, so a vault with a zero timelock has the mechanism and none of the protection, and that is visible onchain before you deposit.
Curator operations, step by step
The work is monitoring, reallocation, reconciliation and reporting, on a loop, across every protocol the curator runs vaults on. Almost everything written about curators covers selection and risk-taking, while the operating work is what actually consumes the team.
A single cycle looks like this.
- Onboard a venue. Assess the market, the oracle behind it, its liquidation parameters and its liquidity depth. Propose the adapter. Wait out the timelock. The waiting is not dead time: it is the window where depositors can object or leave, and a curator who publishes the rationale during it is doing the role properly.
- Set the cap. Size the exposure against the market's own depth, not against the vault's appetite. An allocation the vault cannot exit inside its own redemption promise is a cap error, whatever the yield says.
- Allocate. Execution belongs to the allocator role, against the enabled adapters and within the caps.
- Monitor continuously. Utilisation, oracle deviation, collateral concentration, borrower concentration, governance proposals at each underlying venue. This is per-venue and it does not aggregate itself.
- Reconcile. Vault share price against the sum of the underlying positions, accrued fees against the fee configuration, and the vault's own accounting against the events each venue emitted, where discrepancies are usually a missed event or an unmodelled reward and have to be resolved before anything gets reported.
- Report. Depositors and, increasingly, the platforms distributing the vault want exposure by venue, by collateral and by settlement horizon, plus attribution for the period, and none of that exists in a readable form on the chain.
- De-risk when required. Decrease a cap, deallocate, or revoke a pending proposal. These are the immediate actions, and they are the ones that get exercised at inconvenient hours.
- Offboard. Withdraw, remove the adapter, confirm nothing is stranded. Offboarding is the step most likely to go wrong, because it happens under time pressure and it touches the venue's exit mechanics rather than its entry mechanics.
Now multiply that by protocols. Each vault framework has its own role model, its own timelock semantics, its own event schema and its own accounting conventions, so a curator running vaults on four frameworks maintains four operating manuals and reconciles four data shapes into one report. The work grows with the product count, and none of it is the judgement work the curator is actually paid for. If that is the constraint you are hitting, talk to the Railnet team.
How should an allocator evaluate a curator?
Evaluate on process and on parameter history, not on realised return, because return over any period short enough to be recent is mostly a read on how much risk was carried, and the parameter record shows that directly.
The questions that separate curators:
- Who is the legal entity? Named firm, jurisdiction, insurance, and a contract you can actually reference. If the answer is an address, the rest of the diligence has nowhere to attach.
- What is the parameter policy? A written rule for how caps are sized, what triggers a reduction, and what disqualifies a venue: ask for the policy, then check the last twelve months of onchain parameter changes against it.
- Who holds each role? Owner, curator, allocator and the veto role should not all resolve to the same signer set. Check the timelock length and whether it has ever been shortened.
- What happened the last time something broke? The question is not whether they have taken a loss, because a curator who has never taken one has either been lucky or has not been running long. It is what they did in the following 48 hours, and what they told depositors.
- How is the vault reconciled? Who checks the share price against the underlying positions, how often, and what happens when the two disagree.
- What does the reporting look like? Ask for a real position report, not a dashboard screenshot, because the gap between the two says most of what you need to know about operational maturity.
Ask every one of them before the deposit. The answers are much harder to obtain afterwards, and a curator who cannot produce a position report on request is unlikely to produce one during a drawdown.
Who is accountable when a curated vault loses money?
Mechanically, the depositors are. Legally, it is unresolved, and anyone telling you otherwise is describing their own preferred answer rather than a settled one.
Start with what the code does, because that part is not ambiguous. A loss inside an allocated position reduces the vault's total assets. The share price falls. Every depositor takes the loss in proportion to their holding, at the same moment, whether or not they were in the vault when the risky allocation was made. There is no seniority, no side pocket by default, and no clawback of fees the curator has already accrued unless the vault was specifically built with one.
The rest has no clean answer. The vault contract does not define a duty of care. Neither does any of the token standards a vault is built on. A curator's obligations, if any, come from outside the chain: from a contract with the distributor or the depositor, from a published policy that could be read as a representation, or from whatever the relevant regulator decides the activity amounts to, and those sources conflict, they differ by jurisdiction, and very few of them have been tested. An allocator asking "who do I have recourse against" is asking a question the technology does not answer, and it is the correct question to ask.
What that means in practice is that accountability has to be constructed rather than assumed, out of an identified counterparty, a written mandate, disclosed parameter policy, notice on changes, and independent reporting. Those are contractual and operational choices made before the deposit, not remedies available after a loss.
Railnet does not have a complete answer either. What an operating layer can do is make the record unambiguous: what role changed what parameter, when, under whose key, and what the position looked like before and after. That does not create liability, but it removes the argument about the facts, and that is where these disputes currently stall.
Where Railnet fits
Railnet is the operating layer curators run on. It does not curate, does not take allocation decisions, and does not compete for the depositor relationship. Curation is the judgement. The execution, accounting and reporting underneath it is the part that scales badly, and that is the part Railnet standardises.
Three things change for a curator operating on Railnet. Venues connect through adapters Railnet maintains, so a new venue is not a codebase the curator writes, and strategies hold synchronous and asynchronous sources at once, with owner-defined guardrails and sector-based accounting rather than a bespoke ledger per protocol. Several distributors can sit on one strategy, each with its own share token, fee configuration and access rules, without splitting the underlying liquidity.
Underneath, every deposit and redemption is a Query running one state machine, so a position that settles in a block and a position that settles over days produce the same shape of record. That is what makes step 5 of the operating cycle tractable at more than one or two products.
The layers here are worth separating, because they get collapsed routinely. Protocols produce the yield. Vault infrastructure holds the strategy with its state, settlement and governance. Curation is the risk judgement made inside that structure, asset management is the origination of the mandate, and distribution is who the depositor actually signs up with. Railnet is the second of those. Morpho, Aave, Euler, Compound and Ondo are yield sources that plug in, and the judgement stays with the curator.
Implementation detail lives in the Railnet roles and permissions documentation and the allocation strategy guardrails reference.
What should you do next?
If you are curating, work out where the binding constraint sits among the eight operating steps above, because it is rarely where people expect, and teams tend to invest in venue selection only to discover that reconciliation and reporting are what cap the product count.
For an allocation into a curated vault, put the six diligence questions above to a named entity first, then read the vault's parameter history yourself rather than the marketing page.
If you are a platform distributing a curated vault to your own users, the questions are access control, fee configuration and what you can show a customer after a loss. Settle all three before the integration work starts, because each one changes the share token you issue.
See all questions on vault curation
Foundations
Related pillars
- What is onchain asset management?
- A risk framework for onchain allocation
- Which vault standard does a strategy need?
FAQ
What is vault curation?
The job of deciding what a pooled onchain vault may hold and how much of it. A curator selects eligible markets, sets exposure caps and risk parameters, and revises them as conditions change. The vault contract holds the assets. The curator holds configuration rights over that contract, and most of those take effect only after a timelock.
Does a curator hold my money?
No. Deposits sit in the vault contract. A curator's rights are permissions to change configuration, and in well-separated designs the role that decides what is permitted is not the role that executes allocations. That does not make a curated vault risk-free. It means the risk is bad configuration rather than direct misappropriation.
How is a curator paid?
Out of the vault, through fees set at configuration time. Morpho's Vault V2 documentation allows a performance fee of up to 50% on yield and a management fee of up to 5% on total assets, with changes subject to timelock. The specific rate is a commercial decision, so it has to be checked per vault rather than assumed.
What is a timelock and why does it matter?
A mandatory delay between proposing a configuration change and executing it. It is the depositor's main protection, because it creates a window to exit before a change takes effect. Length is itself a parameter. Risk-increasing changes are typically delayed while risk-reducing ones are immediate, and that is the correct asymmetry.
Can a curator be removed?
By the owner role, the one that appoints and replaces the curator. Whether that helps depends on who holds the owner role and whether it is independent of the curator, so checking that the owner, curator, allocator and veto roles do not all resolve to the same signer set is a basic diligence step.
Who is liable if a curated vault loses money?
Mechanically the depositors, through a lower share price, in proportion to their holding. Legally it is unresolved. The vault contract defines no duty of care, and any obligation comes from a contract, a published policy or a regulator's view, sources that differ by jurisdiction and have rarely been tested. Recourse has to be built before the deposit.
Is curation the same as being a fund manager?
The economics rhyme and the decision surface does not. A fund manager selects securities. A curator sets eligibility and caps over protocol positions they cannot amend, inside a framework that constrains when their changes take effect. The role also carries operational duties a fund manager would delegate to an administrator.
Talk to the team
If you curate vaults and the constraint is reconciliation, reporting or the cost of the next protocol integration, talk to the Railnet team. There is no form to fill in first.