MellowfinanceMellowfinance curators and Onchain Execution Limits
Mellowfinance curators manage Core Vault strategies within permissions and allocation limits encoded in each vault’s mandate. They select and operate permitted strategies, while onchain verifiers constrain the calls they can execute. Depositors supply capital, the distribution partner controls the customer-facing product and Mellowfinance supplies the vault infrastructure.
The curator relationship combines active portfolio management with rules that govern assets, venues and individual operations. Strategy authority and permission administration have different scopes. Valuation and liquidity conditions also constrain how an approved strategy handles capital.
Curators, capital and product ownership
Depositors and distribution partners
Depositors fund a vault, while its distribution partner owns the product interface, branding and customer relationship. In an embedded Earn product, that partner also controls pricing and depositor eligibility. These responsibilities concern product access and distribution, without automatically identifying which account can execute a strategy call.
Vault managers and infrastructure
Asset managers, market makers, staking operators and DeFi teams can act as curators within a vault’s mandate. Their role covers strategy operation inside the permitted execution environment. Mellowfinance supplies the smart contract layer that combines permission enforcement with accounting and liquidity management. Managing a strategy doesn’t automatically confer authority to change its governing rules.
Mandates, verifiers and strategy isolation
Mandate limits
A Core Vault’s mandate defines eligible depositors, supported assets, approved venues, allocation limits, liquidity requirements, verifier rules and oracle constraints. The vault owner sets its rules, and curators operate within them. Venue approval establishes where capital may go, while an allocation cap constrains the exposure that the vault permits.
Subvault boundaries
Subvaults give strategies separate constraints inside a shared vault. Adding or removing a strategy preserves the boundaries governing the remaining allocations. A permitted operation still has to fit the limits that apply to its strategy, asset and venue. Permission to operate one strategy doesn’t establish the available authority over another allocation.
What does a curator’s call permission actually authorize?
A curator’s call permission authorizes a defined operation through the configured verification mode. The Verifier can assess a shortened call, a fuller call description or custom verification logic. These modes differ in which details they authenticate and where that validation occurs.
Compact verification identifies
who
,
where
and the function
selector
: the caller, target and function.
ONCHAIN_COMPACT
checks the compact hash against the stored allowlist, while
MERKLE_COMPACT
authenticates that description through a Merkle proof. The compact description omits the full argument data and ETH value that an extended call contains.
The
MERKLE_EXTENDED
mode authenticates the caller, target, ETH value and full call data through a Merkle proof.
Those additional fields distinguish calls to the same function with different arguments.
CUSTOM_VERIFIER
uses a Merkle-authenticated verification payload and delegates validation to an external verifier.
The selected mode determines the permission evidence. A compact call’s allowlist entry doesn’t describe every other risk control that governs its execution.
From assigned authority to strategy execution
Call details and the selected verification payload enter the same verification request. That request connects the curator’s assigned authority to a particular operation.
| Stage | What happens | Who or what controls it |
|---|---|---|
| Vault configuration | The mandate defines assets, venues and operating limits. | The vault owner sets the rules. |
| Operator authorization |
The initiating account holds
CALLER_ROLE
.
|
Vault access control governs the role. |
| Call preparation | The call identifies the actor, target, value and data. | The requested operation supplies these inputs. |
| Verification selection | The payload identifies the verification type and any required proof data. | The permission scheme determines valid evidence. |
| Permission check |
verifyCall(...)
validates the selected mode and reverts on verification failure.
|
The Verifier enforces call permission. |
| Strategy execution | A call that passes permission checks can proceed within the remaining vault limits. | The curator operates inside the vault mandate. |
Passing verification establishes permission for the checked call under that configuration. Because
verifyCall(...)
is a view function, the permission check doesn’t execute the requested strategy operation.
Strategy changes and permission administration
Curators can adapt strategy behavior without redeploying a Core Vault when the changes fit its configured execution surface. Administrative roles separately govern changes to call permissions. Holding
CALLER_ROLE
doesn’t by itself confer the ability to add allowlisted calls, remove them or update the Merkle root. Each administrative action requires its corresponding role.
Governance can change configured guardrails through the authorized process. Some operation types can require multiple verifier approvals, time locks or enhanced validation. The applicable configuration determines whether routine operations need a single approval.
How do valuation and liquidity constrain a curator’s strategy?
Oracle-defined valuation and queue-based liquidity govern how a Core Vault accounts for positions and processes capital movements.
Oracle reports
Core Vaults calculate net asset value (NAV) using oracle reports, including for portfolios with externalized capital. The Oracle validates reported prices against configured absolute and relative deviation thresholds. Trusted roles submit reports, and suspicious reports require explicit acceptance. The timing settings govern report submission and minimum request age; they don’t promise a redemption completion time.
Withdrawable capital
Core Vaults track economic NAV separately from withdrawable NAV. Deposit and redemption queues accommodate strategies with cooldowns or redemption windows. A portfolio valuation doesn’t establish that the same amount is immediately withdrawable. Curator strategy choices interact with the vault’s liquidity requirements, redemption buffers and underlying settlement conditions.
Human and automated curators under the same permission model
Agent-operated vaults use the same permission model that constrains human curators. Approved functions, assets and venues remain subject to contract-level controls before execution. An autonomous operator’s decision cannot override those configured constraints.
Core Vault integrations include DeFi protocols and access to centralized exchanges through institutional custody integrations. Each mandate determines which venues and operations a particular curator can use. A venue’s appearance in the platform’s integration catalogue doesn’t authorize a strategy to allocate capital there. The vault’s allocation limits still apply when the chosen venue and call are both authorized.
Quick answers
Who can update the active Merkle root for a Core Vault verifier?
An account with SET_MERKLE_ROOT_ROLE can update the active Merkle root through setMerkleRoot(...). A curator’s CALLER_ROLE alone doesn’t grant permission to replace the root that the verifier uses for Merkle-based checks.
Which view functions list a verifier’s explicitly allowlisted calls?
The Verifier exposes allowedCalls() for the entry count and allowedCallAt(index) for each stored CompactCall. The isAllowedCall(who, where, callData) function checks whether a particular compact call appears in that allowlist. These views describe explicit entries. They don’t enumerate calls that require Merkle proofs or custom verification.
What happens if a curator adds a call that’s already allowed?
The allowCalls(...) function reverts if a supplied compact call already exists in the allowlist. Adding compact calls also requires ALLOW_CALL_ROLE. A curator’s execution role alone doesn’t authorize the update.
Can a permission administrator remove an individual compact call?
An account with DISALLOW_CALL_ROLE can remove compact calls through disallowCalls(...). The function reverts if a supplied call isn’t present in the allowlist. This operation changes explicit compact-call entries; it doesn’t revoke CALLER_ROLE from the operator named in the removed entry or establish the outcome of another verification mode.
Where can curators manage rebalancing and track positions?
Mellowfinance provides a curation interface and command-line interface (CLI) for strategy management, rebalancing and position tracking. Its interface also shows portfolio health and economic parameters. These tools support operational management within the vault’s configured permissions; using them doesn’t expand the curator’s authorized actions.
Is the vault manager always separate from the distribution partner?
The distribution partner and vault manager may be the same entity. Their responsibilities remain distinct: the partner controls the product surface and customer relationship, while the manager operates the strategy within the mandate. A deployment’s role assignments determine how one organization combines those functions.
How can a curator inspect an asset’s latest Oracle report?
The Oracle’s getReport(asset) view returns the last report’s price, timestamp and suspicious flag for the selected asset. The timestamp dates the price report, which doesn’t record the curator’s strategy execution. The reported price also doesn’t establish how much capital the vault can immediately release.