> For the complete documentation index, see [llms.txt](https://docs.goevolve.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.goevolve.xyz/dd-questioniare/operational-control.md). # Operational Control This page describes the operational control model where **Evolve** operates multiple Vaults (including **eUSD** and future products). The model replaces traditional administrator and agency functions with a **software-driven control layer**, uses **segregated MPC wallets** and **exchange sub-accounts** for custody and execution, and makes the **Curator / Strategy Operator** the primary risk owner for each Vault within a defined mandate. *** ### Operating model Evolve creates multiple Vaults (e.g., **Vault A / Vault B / Vault C**). Each Vault is a distinct product with its own terms, **bankruptcy-remote segregated vault structure**, asset segregation, accounting, and reporting. Operational control is enforced through: 1. **Vault-level mandates** (terms, limits, escalation rules) 2. **Software modules** that implement lifecycle + accounting rules 3. **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 #### Evolve * 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 where applicable) * Approves Curator appointment and maintains a Vault-specific mandate for the Curator * Oversees whitelisting of DeFi protocols and execution endpoints based on Curator requirements and internal controls #### Curator / Strategy Operator * 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 mints and redemptions per Vault terms (windows, limits, queues) * Mints/burns Vault tokens and maintains the 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/exposures, 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) Each Vault uses segregated onchain wallets, typically including: * **Deposit wallet(s)** * **Collateral/strategy wallet(s)** * **Redemption/processing wallet(s)** Controls and properties: * Transfers execute only based on **authorized instructions** and **policy checks** * Onchain movements preserve an **immutable transaction history** *** ### Exchange sub-accounts (per Vault) Where a Vault uses exchanges for execution, hedging, or yield strategies: * Each Vault has **segregated exchange sub-accounts** * Positions, margin, financing, and P\&L are attributed at the **Vault level** * Venue statements are used to reconcile back into Vault accounting *** ### Vault segregation in operations * Each Vault uses a dedicated MPC wallet set and dedicated exchange sub-accounts * Software modules maintain Vault-specific ledgers and reporting outputs * Asset movements occur only within the Vault’s approved pathways (e.g., **MPC ↔ DeFi**, **MPC ↔ exchange sub-account**) * **Cross-Vault transfers are prohibited** (unless explicitly defined via a controlled, versioned process with disclosures) *** ### Asset movement controls #### Instruction controls * Curator initiates strategy actions and transfers within the Vault mandate * Software enforces policy checks before execution (whitelisted endpoints, limits, timing rules, role permissions) * 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 the internal Vault ledger * Reconcile exchange sub-account balances, positions, and P\&L against the 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, exposures, 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 offchain 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