Mellowfinance Vault Architecture Choices

Execution changes within an existing Core Vault

Core Vaults support changes to approved execution paths through configuration, while retaining the base vault architecture. Declarative verifier rules define permitted calls, so a new execution path needn’t require a protocol-specific adapter. The configured mandate still limits available assets and venues. This supports adapting an existing Core Vault when its design already accommodates the intended allocation.

An operator’s authority follows the active configuration and role assignments. Structured governance controls changes to guardrails, and each operation must satisfy the permissions active during execution. Adding an execution path concerns technical capability; widening a mandate also requires authority to change its constraints.

Which architecture applies to a new deployment?

Core Vaults are the starting architecture for new Mellowfinance deployments, including Earn products and managed treasury allocations. Their design combines execution permissions, liquidity management and multi-asset accounting within one configurable vault system.

Earlier Mellowfinance vault architectures remain documented for existing-deployment maintenance and historical reference. Legacy families include Mellow ALM, MultiVault and Restaking Vaults, Interoperable Vaults, Simple LRT and DVstETH.

Some products using earlier architectures may remain live.

An Earn or treasury label describes a product’s purpose; its deployed contracts establish which architecture-specific instructions and component interfaces apply.

Legacy maintenance and migration boundaries

Existing vaults retain their deployed architecture’s operating rules unless an applicable product change alters that deployment. Historical documentation supports their maintenance. An older contract doesn’t acquire Core Vault queue mechanics or permission interfaces when general project documentation changes. Legacy status alone also doesn’t announce a migration, a withdrawal window or a product closure. Moving capital through redemption and a new deposit would remain subject to the source product’s redemption terms and the destination product’s eligibility conditions.

Deployment names, assets and chains

The deployment list reviewed on 29 September 2026 places Lido EarnETH, Lido EarnUSD and USDG Yield Vault on Core Vaults. Those product names identify deployments within the architecture; they don’t make deposit assets and networks uniform. The same contract framework supports different eligibility rules and allocation mandates.

Lido owns and distributes its Earn products, while Mellowfinance supplies infrastructure and has appointments for curation services. USDG Yield Vault also uses Core Vault infrastructure, with USDG issued by Paxos and the product deployed on Robinhood Chain. A shared architecture doesn’t transfer one product’s chain, token support or operator arrangement to another.

Queue design and liquidity commitments

Core Vaults support asynchronous deposits and redemptions, which lets a product accommodate assets with different settlement schedules. A queued request and completed redemption represent different states, and the architecture tracks economic net asset value (NAV) separately from withdrawable NAV. Portfolio valuation therefore doesn’t by itself describe assets currently available for redemptions.

Staking cooldowns and tokenized treasury redemption windows can create a gap between portfolio value and available liquidity. The vault can account for positions whose settlement doesn’t match an immediate withdrawal request. Its liquidity requirements and queue configuration must fit the underlying strategies. A generic vault label supplies no common waiting period.

An Oracle processing interval adds another timing condition. It specifies a minimum request age for the relevant processing path, without setting a maximum completion time or removing an underlying asset’s settlement constraint.

Oracle settings that govern price acceptance

The Core Vault Oracle applies configured deviation limits and request-age intervals to price reporting and processing. Its securityParams() readout returns the active settings. Each field holds a deployment-specific value that the selected Oracle’s configuration determines. Absolute thresholds use price units; relative thresholds use a ratio scaled by 10^18.

Both absolute and relative maximum checks apply to a submitted price, and crossing either maximum rejects that price. A report above a suspicious threshold, but within both maxima, follows the suspicious-report branch. The timing exception belongs to timeout : a suspicious previous report removes that report-gap check. It doesn’t erase the other validation rules or the deposit and redemption age requirements.

The Oracle validates reported prices against local thresholds, while trusted accounts supply the reports. Price-reporting authority and automated consistency checks serve separate purposes. The deviation controls constrain accepted price changes; they don’t independently establish the economic accuracy of an underlying position. Oracle-defined NAV and an asset’s settlement process also remain separate mechanisms.

Eligibility and venue boundaries at deployment

Core Vault compatibility includes the assets and counterparties that a mandate permits, alongside the contract architecture. Depositor allowlists, transfer-restricted shares and per-issuer rules can apply at the vault level. Configurable hooks support know-your-customer (KYC) and know-your-business (KYB) providers. A product’s configuration determines which eligibility perimeter applies.

Execution support also differs from a product’s enabled scope. Core Vaults can span decentralized finance (DeFi) and centralized finance (CeFi), including institutional custody integrations. A particular mandate selects permitted venues and operations. Real-world asset (RWA) allocation also depends on integrations, jurisdiction and issuer eligibility. Selecting Core Vaults doesn’t authorize every supported asset or venue for every product.

Products on the same platform can enforce different compliance perimeters without separate codebases. This makes a mandate change distinct from an architecture change. Asset eligibility also differs from depositor eligibility: permission to hold an instrument and permission to deposit into a vault answer different questions.

View image file

Security review scope across vault generations

Security reports follow the architecture and component under review, so their scope matters when comparing a current Core Vault with an older deployment. Core Vault reports cover the flexible-vaults codebase.

Nethermind’s Core Vault audit NM_0930 dates to May 2026. Its permissioned Oracle audit NM_0891 dates to April 2026. These reports examine different components within the current architecture.

Earlier architecture reports remain separate, with MultiVault reports from StateMind and ChainSecurity. Interoperable Vault reports include Nethermind and Decurity. Simple LRT and DVV also have their own audit group, which includes reports from MixBytes and ChainSecurity.

An audit for one family doesn’t establish another deployment’s behavior. Likewise, a component review doesn’t announce a product migration or settle its liquidity terms. Architecture, component and deployed configuration must align before a review can answer a deployment-specific security question.

Does ERC-4626 describe every Core Vault requirement?

ERC-4626 alone doesn’t specify Core Vaults’ multi-asset accounting, externalized NAV or institutional permissions. The standard defines a tokenized vault interface around a single underlying asset, while Core Vaults add mechanisms for broader portfolios and execution constraints. A token interface and a complete product architecture answer different integration questions.

Asynchronous liquidity, isolated strategies and cross-venue execution introduce requirements beyond that interface description. The architecture decision therefore turns on the product’s accounting and operating needs, alongside its interface requirements. If a product moves to another architecture, its new contracts and configuration determine which operating rules apply.