> 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 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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.goevolve.xyz/dd-questioniare/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.