# Operational Control This page describes the operational control model where YieldFi operates multiple Vaults. The model replaces traditional administrator and agency functions with a software-driven control layer, uses MPC wallets and exchange sub-accounts for custody and execution, and makes the Curator the sole risk manager for each Vault. ### Operating model YieldFi creates multiple Vaults (e.g., Vault A / Vault B / Vault C). Each Vault is a distinct product with its own terms, asset segregation, accounting, and reporting. Operational control is enforced through (i) Vault-level mandates, (ii) software modules that implement lifecycle rules, and (iii) segregated MPC wallets and exchange sub-accounts per Vault. ### Control objectives • Maintain clear accountability for decision-making and execution\ • Enforce Vault-level segregation across assets, liabilities, cashflows, and reporting\ • Control asset movements with explicit permissions, logs, and verifiable execution trails\ • Produce consistent NAV, reporting, and user lifecycle processing at the Vault level ### Governance and decision rights **YieldFi**\ • Approves creation, modification, and termination of Vaults\ • Publishes Vault terms, including deposit assets, fees, redemption SLAs, valuation policy, and risk limits in consultation with the Curator\ • Approves Curator appointment and maintains a Vault-specific mandate for the Curator\ • Oversees whitelisting of DeFi protocols and execution endpoints based on Curator requirements **Curator**\ • Operates strategy execution within the Vault mandate\ • Initiates deployments, rebalances, hedges, liquidations, and position unwinds\ • Manages Vault-level risk within defined limits and escalation triggers\ • Provides strategy rationale and post-trade reporting inputs into the software control layer ### Roles and responsibilities (software + custody/execution control) **Software Module — Vault Lifecycle & User Operations**\ • Processes deposits and redemptions per Vault terms (windows, limits, queues)\ • Mints/burns Vault tokens and maintains user balance ledger\ • Enforces eligibility/KYC gating where applicable\ • Produces user confirmations and lifecycle event logs **Software Module — Accounting, NAV & Reporting**\ • Maintains Vault-level books (positions, cash, liabilities, P\&L, fees)\ • Calculates NAV per Vault methodology and frequency\ • Reconciles token supply vs Vault net assets and flags breaks\ • Produces reporting packs (NAV history, performance, holdings, fees) **Software Module — Payment Waterfall & Fee Engine**\ • Accrues and settles Vault-level fees per terms\ • Enforces the Vault’s payment priority (fees → payouts/redemptions)\ • Generates an audit-ready trail of all calculations and settlements **Segregated MPC Wallets (per Vault)** * Segregated on-chain wallets per Vault, typically including:\ • deposit wallet(s)\ • collateral/strategy wallet(s)\ • redemption/processing wallet(s) * Execute transfers based on authorized instructions and policy checks\ • Preserve immutable transaction history for all on-chain movements **Exchange sub-accounts (per Vault)**\ • Segregated exchange sub-accounts per Vault used for execution, hedging, and yield strategies\ • Enforce Vault attribution at the venue level (positions, margin, financing, P\&L)\ • Produce account statements for reconciliation back into Vault accounting ### Vault segregation in operations • Each Vault uses a dedicated MPC wallet set and dedicated exchange sub-accounts\ • The software modules maintain Vault-specific ledgers and reporting outputs\ • Asset movements only occur within the Vault’s approved pathways (MPC ↔ DeFi, MPC ↔ exchange sub-account)\ • Cross-Vault transfers are prohibited ### Asset movement controls **Instruction controls**\ • Curator initiates strategy actions and transfers within the Vault mandate\ • Software enforces policy checks (whitelisted endpoints, limits, timing rules, role permissions) before execution\ • High-risk actions (new endpoint, large transfer, emergency unwind) trigger elevated checks and escalation **Authorization controls**\ • Role-based access control across software modules and signing policies\ • Maker-checker approvals for sensitive actions (config changes, whitelist changes, large moves)\ • Full logging of who approved what, when, and why **Reconciliations**\ • Reconcile MPC wallet balances and transactions against internal Vault ledger\ • Reconcile exchange sub-account balances, positions, and P\&L against internal Vault ledger\ • Exceptions are tracked with status, owner, and resolution notes ### NAV, pricing, and reporting controls • Each Vault has a defined valuation policy (sources, frequency, cutoffs, fallback rules)\ • The NAV module produces daily/periodic NAV and flags pricing anomalies\ • Manual overrides (if any) are permissioned, justified, logged, and reviewable\ • Reporting outputs remain Vault-specific: NAV, performance, holdings, fees, and token supply reconciliation ### Fees and settlement controls • Fees accrue and settle at the Vault level, not across Vaults\ • Distributions (if supported) and redemptions are paid from the Vault’s redemption/processing MPC wallet\ • Any off-chain settlements (e.g., exchange financing costs) are allocated back to the Vault ledger with supporting records ### Change management and escalation • Vault term changes and risk-limit changes follow a controlled workflow (proposal → review → approval → versioned release)\ • Whitelist changes (protocols/endpoints) are versioned and auditable\ • Escalation triggers are defined per Vault (limit breach, liquidity stress, exchange margin events, oracle/pricing anomalies)\ • Incidents produce a post-event report and result in control updates where required --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.yield.fi/due-diligence-questionaire/operational-control.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.