# Orion Finance Documentation > Complete reference documentation for Orion Finance > > For the complete documentation index, see [llms.txt](/llms.txt). Markdown versions of pages are available by appending `.md` to the URL or sending `Accept: text/markdown`. This file contains all documentation content in a single document following the llmstxt.org standard. # Accessing the App > Orion's app is the entry point for creating, managing, and investing in onchain portfolios. The interface is designed to be intuitive for first-time users while also supporting professional portfolio managers. ## Step 1: Visit the Official App - Open your browser and go to: **[app.orionfinance.ai](https://app.orionfinance.ai)** - Bookmark the page to avoid phishing sites. - Always check that the URL is correct and uses **HTTPS**. ## Step 2: Choose Your Role Once you land on the app, you can navigate as: - **User** - Browse vaults and allocate capital as an investor. - **Manager** - Create and manage vault strategies. ## Step 3: Explore Without Connecting You can view public vaults, performance charts, and protocol stats without connecting a wallet. This is a safe way to familiarize yourself with the interface before interacting with smart contracts. ## Step 4: When You're Ready When you're ready to deposit, withdraw, or create a vault, you'll need to: 1. Connect a compatible wallet (see [Connecting a Wallet](https://docs.orionfinance.ai/user/getting_started/connecting-a-wallet.md)). 2. Approve smart contract interactions through your wallet. 3. Confirm transactions onchain. ## Tips for a Smooth Experience - **Browser** - Use the latest version of Chrome, Brave, or Firefox. - **Network** - Ethereum Mainnet (production) or Sepolia (testnet). No other networks. - **Security** - Never share your private keys or seed phrase with anyone. --- ## Related Pages - [Connecting a Wallet](https://docs.orionfinance.ai/user/getting_started/connecting-a-wallet.md) - [Understanding Vault Metrics](https://docs.orionfinance.ai/user/getting_started/understanding-vault-metrics.md) - [Permissioned Vaults](https://docs.orionfinance.ai/user/key_features/permissioned-vaults.md) --- # Connecting a Wallet > To interact with Orion, deposit into vaults, withdraw, or create strategies, you need to connect a Web3 wallet. While the application supports multiple wallet providers, **Rabby Wallet** is recommended for the best experience with Orion. ## Step 1: Install Rabby Wallet If you don't have Rabby Wallet yet: 1. Visit the official site: **[rabby.io](https://rabby.io/)** 2. Download the extension for your browser. 3. Follow the setup instructions to create a wallet. 4. **Important:** Store your seed phrase securely; never share it with anyone. ## Step 2: Unlock Your Wallet - Click the Rabby Wallet icon in your browser's extensions bar. - Enter your password to unlock your wallet. ## Step 3: Connect to Orion 1. Go to **[app.orionfinance.ai](https://app.orionfinance.ai)**. 2. Click the **"Connect Wallet"** button (top right corner). 3. Select your preferred wallet from the list of wallet options. 4. Approve the connection in your wallet popup. ## Step 4: Select the Correct Network - Orion supports **Ethereum Mainnet** (production) and **Sepolia** (optional testnet). No L2s. - If prompted, approve the network switch in your wallet. - If the network isn't added to your wallet yet, Orion will provide the details for you to add it. ## Step 5: You're Connected Once connected, your wallet address will appear in the top right corner of the app. You can now: - Deposit into vaults. - Withdraw your assets. - Create and manage vaults (if you're a manager). ## Troubleshooting - **Not seeing the connection prompt?** Refresh the page and try again. - **Wrong network?** Manually switch networks in your wallet. - **Using multiple wallets?** Make sure only the one you want to connect is active in your browser. - **Rabby dRPC / free-plan error:** the wallet's Sepolia RPC is rejecting the request. Set a Custom RPC. See [Troubleshooting](https://docs.orionfinance.ai/user/getting_started/troubleshooting.md). - **Need help?** [Schedule a call](https://calendly.com/zoe-orionfinance/30min) with the Orion team. --- ## Related Pages - [Accessing the App](https://docs.orionfinance.ai/user/getting_started/accessing-the-app.md) - [Troubleshooting](https://docs.orionfinance.ai/user/getting_started/troubleshooting.md) - [Getting ETH on Sepolia](https://docs.orionfinance.ai/user/getting_started/getting-eth-sepolia.md) - [Understanding Vault Metrics](https://docs.orionfinance.ai/user/getting_started/understanding-vault-metrics.md) - [Permissioned Vaults](https://docs.orionfinance.ai/user/key_features/permissioned-vaults.md) --- # Depositing and Withdrawing > Investors can deposit assets into Orion vaults and earn returns based on the vault's strategy performance. This guide walks through the complete flow from browsing vaults to withdrawing assets. ## Overview Orion uses an asynchronous execution model, which means deposits and withdrawals are queued and processed during the next rebalancing cycle. ## Step 1: Browse Available Vaults 1. Visit **[app.orionfinance.ai](https://app.orionfinance.ai)** 2. Browse the available vaults without connecting your wallet 3. Review vault metrics: - Performance history (APR, returns) - Total Value Locked (TVL) - Risk profile - Asset allocation - Fee structure For more details on understanding these metrics, see [Understanding Vault Metrics](https://docs.orionfinance.ai/user/getting_started/understanding-vault-metrics.md). ## Step 2: Select a Vault Choose a vault that aligns with your: - Investment goals - Risk tolerance ## Step 3: Connect Your Wallet Before depositing, you'll need to: 1. Connect a compatible wallet (see [Connecting a Wallet](https://docs.orionfinance.ai/user/getting_started/connecting-a-wallet.md)) 2. Ensure your wallet is on the correct network (Ethereum Mainnet or Sepolia). 3. Have sufficient funds for your deposit plus gas fees ## Step 4: Deposit Assets ### Submit Deposit Intent 1. Navigate to your chosen vault in the app 2. Enter the amount you want to deposit 3. Review the transaction details 4. Approve the deposit transaction in your wallet **What happens next:** - Your deposit intent is submitted to the vault - The vault queues your deposit for the next rebalancing cycle ### Execution During the next rebalancing cycle: - The protocol processes all pending deposits in a batch - Your deposit is executed at the current share price - Vault shares are created (minted) to your address - Your deposit appears in your portfolio **Note:** The time until execution depends on the protocol's rebalancing frequency. ## Step 5: Monitor Your Investment Once your deposit is executed: - **Track performance** - View your vault share value in the app - **Monitor returns** - Check how your investment is performing over time - **Review fees** - Understand how management and performance fees affect your returns The vault's share value updates after each rebalancing cycle as the strategy generates profits or losses. ## Step 6: Withdraw Assets ### Submit Withdrawal Intent 1. Navigate to your vault position in the app 2. Enter the amount you want to withdraw (or select "Max") 3. Review the transaction details 4. Approve the withdrawal transaction in your wallet **What happens next:** - Your withdrawal intent is submitted to the vault - The vault queues your withdrawal for the next rebalancing cycle - Your vault shares are marked for redemption ### Execution During the next rebalancing cycle: - The protocol processes all pending withdrawals in a batch - Your vault shares are burned - The underlying assets are transferred to your wallet - The withdrawal appears as completed in the app **Note:** Withdrawals are also subject to the protocol's rebalancing frequency, so there may be a delay between submitting your withdrawal intent and receiving your assets. ## Understanding Asynchronous Execution ### Why Asynchronous? Orion's asynchronous execution model provides several benefits: 1. **Cost Efficiency** - Batch processing reduces gas costs per transaction 2. **Fair Pricing** - All participants in a batch receive the same execution price 3. **Capital Efficiency** - The protocol can net out trades across multiple vaults before executing ### What to Expect - **Deposits** - Queued until the next rebalancing cycle, then executed and shares created (minted) to your address - **Withdrawals** - Queued until the next rebalancing cycle, then executed and assets transferred - **Timing** - Execution happens at predetermined intervals (check protocol config for details on frequency) ## Tips for Success - **Plan ahead** - Account for the rebalancing cycle delay when timing deposits or withdrawals - **Monitor fees** - Understand how performance and management fees impact your returns - **Diversify** - Consider spreading investments across multiple vaults with different strategies - **Stay informed** - Keep track of vault performance and any strategy changes --- ## Related Pages - [Accessing the App](https://docs.orionfinance.ai/user/getting_started/accessing-the-app.md) - [Connecting a Wallet](https://docs.orionfinance.ai/user/getting_started/connecting-a-wallet.md) - [Understanding Vault Metrics](https://docs.orionfinance.ai/user/getting_started/understanding-vault-metrics.md) - [How It Works](https://docs.orionfinance.ai/user/how-it-works.md) - [Vault Fees](https://docs.orionfinance.ai/user/key_features/vault-fees.md) --- # Getting ETH on Sepolia (optional testnet) > Production Orion is **Ethereum Mainnet**. Sepolia is an optional public testnet for development. You only need this page if you are trying flows on Sepolia. Sepolia ETH is testnet ETH used to pay gas. It has no monetary value. ## What is Sepolia? Sepolia is an Ethereum testnet, a separate blockchain that mimics the Ethereum mainnet but uses test tokens that have no real value. It is designed for: - Testing smart contracts before deploying to mainnet - Learning how to use DeFi protocols without financial risk - Development and experimentation **Important:** Sepolia ETH has no monetary value and cannot be converted to real ETH. ## How to Get Sepolia ETH ### Option 1: Use a Public Faucet The easiest way to get Sepolia ETH is through a public faucet: 1. Visit the **[Google Cloud Ethereum Sepolia Faucet](https://cloud.google.com/application/web3/faucet/ethereum/sepolia)** 2. Sign in with your Google account 3. Enter your wallet address (the address you'll use to interact with Orion) 4. Request testnet ETH 5. Wait a few minutes for the ETH to arrive in your wallet **Note:** Most faucets have rate limits (e.g., once per day or week) to prevent abuse. ### Option 2: Contact Us If you're having trouble getting Sepolia ETH from public faucets, or if you need more than the faucet limit: 1. [Schedule a call](https://calendly.com/zoe-orionfinance/30min) with the Orion team 2. Share what you need Sepolia ETH for and roughly how much 3. Our team can help you get the testnet ETH you need ## Before You Start Make sure you have: 1. **A Web3 wallet** - MetaMask or another compatible wallet (see [Connecting a Wallet](https://docs.orionfinance.ai/user/getting_started/connecting-a-wallet.md)) 2. **Your wallet connected to Sepolia** - Switch your wallet network to Sepolia testnet 3. **Your wallet address** - You'll need this to receive Sepolia ETH from faucets ## Switching to Sepolia Network If your wallet isn't already connected to Sepolia: 1. Open your wallet (e.g., MetaMask) 2. Click the network selector (usually shows "Ethereum Mainnet") 3. Select "Sepolia" from the list 4. If Sepolia isn't listed, you may need to add it manually: - Network Name: Sepolia - RPC URL: `https://ethereum-sepolia-rpc.publicnode.com` (or another [public RPC](#public-rpc-endpoints) below) - Chain ID: 11155111 - Currency Symbol: ETH - Block Explorer: `https://sepolia.etherscan.io` ## Public RPC Endpoints These Sepolia HTTPS endpoints returned chain ID `11155111` when checked on 18 August 2026. Public RPCs can rate-limit or go offline; if one fails, try another. - **PublicNode:** `https://ethereum-sepolia-rpc.publicnode.com` (WebSocket: `wss://ethereum-sepolia-rpc.publicnode.com`) - **1RPC:** `https://1rpc.io/sepolia` (privacy-focused) - **1RPC (public):** `https://public.1rpc.io/sepolia` - **Tenderly:** `https://sepolia.gateway.tenderly.co` - **0xrpc:** `https://0xrpc.io/sep` - **Stupidtech:** `https://evm.stupidtech.net/v1/11155111` If you use **Rabby** and Sepolia transactions fail with a dRPC or "free plan" error, point Rabby at one of these URLs. See [Troubleshooting](https://docs.orionfinance.ai/user/getting_started/troubleshooting.md). ## Using Sepolia ETH Once you have Sepolia ETH in your wallet: - You can deposit into Orion vaults on Sepolia - Test withdrawals and other features - Experiment with different strategies - Learn how the protocol works without financial risk **Remember:** All transactions on Sepolia are free to execute (you only pay gas with testnet ETH), but they have no real-world value. --- ## Related Pages - [Connecting a Wallet](https://docs.orionfinance.ai/user/getting_started/connecting-a-wallet.md) - [Troubleshooting](https://docs.orionfinance.ai/user/getting_started/troubleshooting.md) - [Depositing and Withdrawing](https://docs.orionfinance.ai/user/getting_started/depositing-and-withdrawing.md) - [Accessing the App](https://docs.orionfinance.ai/user/getting_started/accessing-the-app.md) --- # Transaction Flow > When depositing USDC into an Orion vault, you'll complete a **2-step transaction process**. This guide explains each step and why it's necessary. ## Why Two Steps? Orion uses the standard ERC-20 token approval pattern: 1. **Step 1: Approve** - Grant the vault permission to transfer your USDC 2. **Step 2: Deposit** - Submit your deposit intent to the vault This two-step process ensures you maintain control over your tokens and explicitly authorize each interaction. ## Step 1: ERC-20 Token Approval Before you can deposit USDC into a vault, you must first **approve** the vault contract to spend your USDC tokens. ### What is Token Approval? ERC-20 tokens (like USDC) require explicit permission before a smart contract can transfer them from your wallet. This is a security feature that prevents unauthorized access to your tokens. ### The Approval Transaction When you click "Approve" in the Orion app: 1. **Your wallet opens** - MetaMask or your connected wallet prompts you to sign 2. **Review the approval** - You'll see: - **Token**: USDC - **Spender**: The vault contract address - **Amount**: The amount you're approving 3. **Sign the transaction** - Confirm in your wallet 4. **Approval recorded** - The approval is recorded onchain ### Understanding Approval Amounts You'll approve a specific amount of USDC that matches the amount you want to deposit. This gives the vault permission to transfer that amount from your wallet. ## Step 2: Deposit Intent Submission After approval, you can submit your deposit intent to the vault. ### The Deposit Transaction When you click "Deposit" in the Orion app: 1. **Your wallet opens** - You'll be prompted to sign the deposit transaction 2. **Review the deposit** - You'll see: - **Vault**: The vault you're depositing into - **Amount**: The USDC amount you're depositing - **Gas fee**: The estimated gas cost 3. **Sign the transaction** - Confirm in your wallet 4. **Intent queued** - Your deposit intent is submitted and queued for the next rebalancing cycle ### After Submission Your deposit intent is now: - **Queued** - Waiting for the next rebalancing cycle - **Recorded** - Recorded immutably on the blockchain - **Secure** - Your USDC is held by the protocol until execution During the next rebalancing cycle, your deposit will be executed and vault shares will be created (minted) to your address. ## Security Benefits of the 2-Step Process ### 1. Explicit Authorization - You must explicitly approve each token contract - No contract can access your tokens without your permission - You maintain full control over your approvals ### 2. Granular Control - You approve specific amounts for each deposit - You can revoke or modify approvals at any time - Each approval is a separate, auditable transaction ### 3. Protection Against Unauthorized Access - Approval transactions are visible onchain for transparency - You can review and revoke approvals through your wallet or block explorer ## First-Time vs. Subsequent Deposits ### First Deposit If this is your first deposit to a vault: 1. **Approve USDC** (Step 1) - Required 2. **Submit deposit** (Step 2) - Required ### Subsequent Deposits If you've already approved USDC: 1. **Approve USDC** (Step 1) - May be skipped if you have sufficient approval 2. **Submit deposit** (Step 2) - Required The app will automatically detect if you need to approve or if you can proceed directly to deposit. ## Checking Your Approvals You can check your USDC approvals at any time: 1. **In your wallet** - Some wallets show token approvals 2. **On block explorers** - View approvals on Etherscan/Sepolia Etherscan 3. **Revoke approvals** - Use tools like [revoke.cash](https://revoke.cash) to manage approvals ## Best Practices 1. **Review approvals** - Always review the spender address before approving 2. **Verify vault addresses** - Ensure you're approving the correct Orion vault contract 3. **Monitor approvals** - Periodically review and clean up unused approvals ## Troubleshooting ### Approval Transaction Failed Common reasons: - Insufficient ETH for gas fees - Network congestion (try again later) - Wrong network (ensure you're on the correct network) ### Deposit Transaction Failed Common reasons: - Insufficient USDC approval (complete Step 1 first) - Insufficient USDC balance - Vault deposit limits reached - Network issues --- ## Related Pages - [Depositing and Withdrawing](https://docs.orionfinance.ai/user/getting_started/depositing-and-withdrawing.md) - [Connecting a Wallet](https://docs.orionfinance.ai/user/getting_started/connecting-a-wallet.md) - [How It Works](https://docs.orionfinance.ai/user/how-it-works.md) --- # Troubleshooting > Known issues when using the Orion app, and how to fix them. ## Rabby Wallet: Sepolia RPC / "chain is not available on free plan" Rabby's built-in Sepolia network uses `https://sepolia.drpc.org`. That endpoint often rejects requests with **chain is not available on free plan**, so Approve or Deposit can fail when Rabby looks up nonce or sends the transaction. You might see: - The Orion app opens a wallet popup, then Rabby shows a dRPC or "free plan" error - Approvals or deposits fail with a network / RPC error, even though your Sepolia ETH balance looks fine This is a wallet RPC setting. The Orion app cannot replace Rabby's built-in Sepolia endpoint for you. ### Fix: set a Custom RPC for Sepolia 1. Open the Rabby extension. 2. Click **More**, then **Custom RPC**. 3. Select **Ethereum Sepolia** (chain ID `11155111`). 4. Replace the RPC URL with a working public endpoint. We recommend: `https://ethereum-sepolia-rpc.publicnode.com` 5. Save, then retry Approve or Deposit in the Orion app. Other Sepolia RPCs that work are listed under [Public RPC Endpoints](https://docs.orionfinance.ai/user/getting_started/getting-eth-sepolia.md#public-rpc-endpoints). :::orion[dRPC free-plan error] If Rabby shows **chain is not available on free plan**, replace the built-in Sepolia URL (`https://sepolia.drpc.org`) with another RPC from [Public RPC Endpoints](https://docs.orionfinance.ai/user/getting_started/getting-eth-sepolia.md#public-rpc-endpoints). That host is Rabby's default; it only needs changing when it returns the free-plan error. ::: ## Wallet won't connect - Refresh the page and click **Connect Wallet** again. - Switch your wallet to Ethereum Sepolia or Ethereum mainnet, depending on which network you intend to use. - If several wallet extensions are installed, keep only the one you want active. See [Connecting a Wallet](https://docs.orionfinance.ai/user/getting_started/connecting-a-wallet.md) for the full connect flow. ## Still stuck? [Schedule a call](https://calendly.com/zoe-orionfinance/30min) with the Orion team. --- ## Related Pages - [Connecting a Wallet](https://docs.orionfinance.ai/user/getting_started/connecting-a-wallet.md) - [Getting ETH on Sepolia](https://docs.orionfinance.ai/user/getting_started/getting-eth-sepolia.md) - [Accessing the App](https://docs.orionfinance.ai/user/getting_started/accessing-the-app.md) --- # Understanding Vault Metrics > Before depositing into a vault, it is useful to understand the key metrics displayed in the Orion app. These metrics help evaluate performance, risk, and suitability for a given investment goal. ## Total Value Locked (TVL) - **What it means:** The total amount of assets currently deposited in the vault. - **Why it matters:** Higher TVL can indicate investor confidence, but may also mean smaller relative returns if capacity is limited. ## Net Asset Value (NAV) - **What it means:** The value of one vault share, calculated as the total value of the vault's assets (minus any liabilities) divided by the number of shares. - **Why it matters:** NAV is the reference point for performance, fee calculations, and what a share of the vault is worth at any time. ## Annual Percentage Rate (APR) - **What it means:** The projected annualized return based on the vault's historical performance. - **Why it matters:** APR is an estimate, a reference point, not a forecast. Actual returns can vary depending on strategy performance and market conditions. ## Asset Allocation - **What it means:** The distribution of assets held by the vault. - **In transparent vaults:** Visible in real time. - **In private vaults:** Confidential. ## Rebalancing Frequency - **What it means:** How often the vault adjusts its asset allocation to match the strategy. - **Why it matters:** More frequent rebalancing can keep the portfolio aligned with its target allocation, but may incur higher trading costs. ## Performance History - **What it means:** Historical returns and volatility over different timeframes (e.g., 7d, 30d, 1y). - **Why it matters:** Past performance can give insight into how the strategy behaves in different market conditions, but is not a guarantee of future results. ## Fees - **Performance Fee:** A percentage of profits taken by the manager when the vault is profitable. - **Management Fee:** An annualized fee taken regardless of performance to cover strategy maintenance. - **Fee Model:** The rule set that defines **how** performance fees are charged (e.g., absolute return, hard hurdle, soft hurdle, or high water mark). - **Why it matters:** Fees and fee models impact net returns and when performance fees are paid. For visuals and detailed examples, see [Vault Fees](https://docs.orionfinance.ai/user/key_features/vault-fees.md). ## Risk Profile - **What it means:** An indication of the vault's risk level based on its asset mix and strategy. - **Why it matters:** A depositor should choose a risk profile that aligns with their investment horizon and tolerance. ## Quick Tip Always evaluate vault metrics in context: a high APR might look attractive, but consider TVL, risk profile, and historical performance before depositing. --- ## Related Pages - [Accessing the App](https://docs.orionfinance.ai/user/getting_started/accessing-the-app.md) - [Connecting a Wallet](https://docs.orionfinance.ai/user/getting_started/connecting-a-wallet.md) - [Permissioned Vaults](https://docs.orionfinance.ai/user/key_features/permissioned-vaults.md) - [Vault Fees](https://docs.orionfinance.ai/user/key_features/vault-fees.md) --- # How It Works > Orion provides the infrastructure for creating, managing, and investing in onchain portfolios. The main components fit together as follows: ## Vaults - The Core Building Block At the heart of Orion are **yield-bearing vaults** (vaults that generate returns). Each vault holds one or more assets and follows a strategy defined by a manager. - Vaults are [ERC-4626](/developer/contract-standards#eips) compliant for compatibility with other DeFi protocols. - They can be **single-asset** or **multi-asset** with automated rebalancing. - Strategies can be transparent or privacy-preserving. ## Managers - Portfolio Managers Managers design and manage the strategies behind vaults: - Define asset allocation, risk parameters, and rebalancing logic. - Use Orion's SDK and familiar development tools to deploy strategies onchain. - Choose between **transparent vaults** with visible asset allocation, or **private vaults** with confidential asset allocation. - Set performance and management fees. ## Investors Investors allocate capital to vaults that match their goals: - Deposit USDC into vaults and receive vault tokens representing their share. - Track performance through Orion's interface. - Withdraw subject to the protocol's asynchronous execution schedule. ## Asynchronous Execution - Privacy & Efficiency by Design In Orion, actions are processed asynchronously to enable privacy and cost optimization. - **Managers** submit intents that define their desired portfolio allocation (transparent or private). - **Users** submit deposit and withdraw intents in the app. - The protocol rebalances all vaults at a set rebalancing frequency. This asynchronous execution engine allows Orion to: - **Protect Privacy** - Conceal strategy details between rebalancing cycles. - **Reduce Costs** - Bundle, batch, and net transactions across multiple vaults and participants. - **Optimize Execution** - Minimize unnecessary trades and gas usage. ## Interoperability - Built for Composability Orion vaults follow common DeFi standards; therefore, they can integrate with: - Aggregators; - Lending protocols; - Other DeFi infrastructure; This composability allows vaults to plug into the wider ecosystem and expand their reach. --- ## TL;DR 1. **Managers** design strategies and launch vaults. 2. **Investors** allocate to vaults that match their goals. 3. **Both** submit intents rather than instant trades. 4. **The protocol** rebalances vaults on a set schedule for privacy and efficiency. 5. **Everyone** benefits from a scalable portfolio management system with manager onboarding for vault creation. --- # What is Orion? > Orion Finance is a **decentralized portfolio management protocol** for creating, managing, and investing in onchain digital asset portfolios. It combines the openness of DeFi with the structure of traditional portfolio management. Managers launch vaults after onboarding; investing remains open, unless otherwise noted. At its core, Orion provides **next-generation infrastructure** that maximizes capital efficiency, protects manager intellectual property (IP), and delivers transparent, verifiable results for investors. ## Why Orion? DeFi offers broad access to onchain markets, but managing portfolios onchain often requires deep technical knowledge, carries higher execution costs, and typically lacks privacy for strategy details. Orion addresses these challenges through: - **Open Investing** - Investors can allocate freely; managers create vaults after onboarding. - **Efficiency** - Advanced execution layers can reduce costs and friction. - **Privacy** - Strategies may remain confidential while results stay verifiable onchain. - **Security** - Safety and reliability are design priorities at each layer. Independent [security audits](https://github.com/OrionFinanceAI/protocol/tree/main/audits) are published in the protocol repository. - **Composability** - Integrate seamlessly with the broader DeFi ecosystem. - **Custom Strategies** - Vaults can be configured to a defined risk/return profile. ## Who is Orion For? - **Users** - Investors who allocate to managed, efficient, and verifiable onchain portfolios (this docs section). - **Managers** - Launch and manage quant strategies while protecting their alpha (competitive advantage or strategy edge). - **Developers** - Integrate Orion’s modular infrastructure to power new applications. ## The Vision Advanced portfolio management that is as accessible as routine onchain payments; a shared ecosystem where investors, managers, and developers can participate on common infrastructure. ## Official Channels | Channel | Role | | ------------------------------------------------------------------- | ------------------------------------------------------ | | **[X / Twitter](https://x.com/OrionFinanceAI)** (`@OrionFinanceAI`) | Primary public status updates | | **[Discord](https://discord.gg/8bAXxPSPdw)** | Community updates from Orion-operated accounts | | **[Telegram](https://t.me/orionfinance_ai)** | Same, from the official Orion channel | | **[LinkedIn](https://www.linkedin.com/company/orionfinance/)** | Company-level notices when used | | **App** ([app.orionfinance.ai](https://app.orionfinance.ai)) | In-app notices when we can show them safely | | **Docs** ([docs.orionfinance.ai](https://docs.orionfinance.ai)) | Standing security pages; incident notes when published | | **[security@orionfinance.ai](mailto:security@orionfinance.ai)** | Private reports and researcher contact | For a suspected vulnerability or an active incident, use [Security](/developer/security/overview) and [Incident Response](/developer/security/incident-response). Ignore DMs. --- # Bundling, Batching & Netting > Orion's execution layer is designed to make portfolio management more efficient and cost-effective. Three core techniques, **bundling**, **batching**, and **netting**, work together to lower costs, improve scalability, and support privacy. ## Bundling: One Transaction, Many Actions Instead of executing each rebalancing order separately, Orion **bundles** multiple actions into a single onchain transaction. - Reduces gas usage for managers and users. - Enables multi-asset rebalancing in one step. - Works for both transparent and private vault strategies. ## Batching: Sharing Costs Across Vaults Orion groups (**batches**) transactions from multiple vaults and executes them together. - Gas fees are shared across all participants in the batch. - Larger batches improve cost savings for participants. - Works alongside bundling for additional efficiency. ## Netting: Matching Orders Before Execution **Netting** offsets buy and sell orders between participants before hitting the open market. - Reduces the total number of trades. - Can minimize price impact and slippage. - Cuts gas costs by avoiding unnecessary transfers. --- ## Related Pages - [How It Works](https://docs.orionfinance.ai/user/how-it-works.md) - [Key Features - Privacy](https://docs.orionfinance.ai/user/key_features/privacy.md) - [Key Features - Permissioned Vaults](https://docs.orionfinance.ai/user/key_features/permissioned-vaults.md) --- # Financial Machine Learning > Orion is built on the principle that **Financial Machine Learning can make portfolio management more accessible onchain**. By combining data-driven insights with automated execution, Orion supports investment strategies that a broader range of participants can access. ## Why It Matters In traditional finance, advanced portfolio optimization tools are commonly reserved for institutions and hedge funds. Orion brings these capabilities onchain, so: - **Everyday investors** can access strategies that simplify allocation decisions. - **Experienced managers** can enhance performance with data-driven insights. - **All participants** can benefit from automated allocation. ## Two Core Approaches Orion supports two main styles of portfolio management: 1. **Passive Portfolios** - Simple, rules-based strategies (e.g., indexes) that automatically rebalance. - Suitable for investors who prefer hands-off, predictable exposure. 2. **Active, Machine-Learning-Driven Strategies** - Models that adjust allocations in response to data. - Suitable for investors seeking more dynamic, performance-oriented portfolios. ## Powered by skfolio Under the hood, Orion integrates [**skfolio**](https://skfolio.org/), an open-source portfolio management library for quantitative finance. This allows vault strategies to leverage advanced statistical techniques, from covariance analysis to risk-adjusted optimization, while keeping execution verifiable and onchain. ## What This Means for Investors With Financial Machine Learning-powered vaults, an investor can choose a strategy that matches their preferences: - Stay passive with transparent, rules-based allocations. - Use active, private models that seek to improve risk-adjusted returns. In both cases, Orion handles execution in the background, rebalancing at set intervals, keeping costs lower through batching, and protecting strategy details where configured. --- ## Related Pages - [Permissioned Vaults](https://docs.orionfinance.ai/user/key_features/permissioned-vaults.md) - [How It Works](https://docs.orionfinance.ai/user/how-it-works.md) - [Privacy](https://docs.orionfinance.ai/user/key_features/privacy.md) --- # Permissioned Vaults > Orion vault creation is permissioned. Portfolio managers must complete onboarding to receive permissions required to create and operate vaults. Investing remains open, unless otherwise noted in the app. ## What Makes Orion's Vaults Different? Managers must complete onboarding before creating and operating vaults. Vaults are **intent-based**, meaning managers and users submit desired actions (allocation changes, deposits, withdrawals) that the protocol executes in optimized batches, making them **highly capital-efficient**. Vaults can also be **privacy-preserving**, with allocations kept confidential between rebalancing cycles while performance remains verifiable onchain. This allows managers to protect their alpha (competitive advantage or strategy edge) and investors to allocate without revealing their positions. ## Vault Standards - **ERC-4626 Compliant** - Orion vaults follow the [ERC-4626 Tokenized Vault Standard](/developer/contract-standards#eips), making them interoperable with the wider DeFi ecosystem. - **Multi-Asset Support** - Vaults can hold one or multiple assets and rebalance between them according to the strategy. - **Automated Execution** - Strategies are executed via Orion's asynchronous execution layer for efficiency and privacy. ## Transparent vs. Private Vaults When launching a vault, managers can choose: - **Transparent Vaults** - Asset allocation is fully visible onchain. - **Private Vaults** - Asset allocation remains confidential between rebalancing cycles, while performance remains verifiable. ## Customization Vault creators can define: - Asset universe and allocation rules. - Risk and return targets. - Rebalancing frequency. - Performance and management fees. - Transparency level (transparent or private). --- ## Related Pages - [How It Works](https://docs.orionfinance.ai/user/how-it-works.md) - [Key Features - Financial Machine Learning](https://docs.orionfinance.ai/user/key_features/financial-machine-learning.md) --- # Privacy > Orion is designed to protect **manager alpha** (competitive advantage or strategy edge), while still keeping performance results fully verifiable onchain. ## Why Privacy Matters In DeFi, transparency is the default. Without privacy, anyone can see a vault's holdings and trades in real time, making it easier for competitors to copy strategies or front-run transactions (execute trades ahead of others to profit from price movements). This forces portfolio managers into a trade-off between protecting their edge and staying onchain. Orion addresses this by letting managers choose between **transparent** and **private (encrypted)** vaults. ## How Privacy Works in Orion Managers pick a vault type at creation: - **Transparent vaults:** Allocation weights and holdings are visible onchain. - **Private (encrypted) vaults:** Allocation weights and holdings are sealed with HPKE before they are stored onchain. Performance metrics (TVL, share price) and deposit/redeem activity remain visible. What stays public vs private on encrypted vaults: | Visible onchain | Sealed (not publicly readable) | | --------------------------------- | ------------------------------ | | TVL and share price | Target allocation (intent) | | Deposit and redeem activity | Current holdings (portfolio) | | Fee parameters and vault metadata | Per-asset weights and shares | Private vault pages in the app hide allocation charts for this reason. Rebalancing still runs through Orion's asynchronous execution layer, which also helps reduce exposure to frontrunning and sandwich attacks. --- ## Learn More For managers and developers interested in the cryptographic model behind sealed intents and portfolios, see: - [Manager Docs - Privacy & Confidential Execution](/manager/advanced/privacy-and-confidential-execution) --- # Vault Fees > When investing in an Orion vault, an investor may pay **fees to the manager** (the portfolio manager who runs the strategy). > These fees compensate the manager for their work and are always shown in the app before a deposit is confirmed. Orion vaults can have two main types of fees: - **Management fee** - a recurring fee on total value locked (TVL) - assets under management (AUM), capped at **3%** per year. - **Performance fee** - a fee on generated returns, capped at **30%** of profits. Both fee types: - Are subject to **protocol-level limits** to protect investors; charges cannot exceed these caps. - Are subject to an **immutable 7-day delay** before changes take effect; if a manager updates management fees, performance fees, or fee type/model, those changes are announced in the app and take effect after 7 days. If the manager makes another change before the 7 days are up, the timer resets for the new change, giving depositors time to react to pending changes. Current fee settings are always visible on the vault page before deposit. ## Management Fees **Management fees** compensate managers for ongoing portfolio design, monitoring, and operations. - **Basis**: Charged as an annualized percentage of vault assets under management (AUM) (e.g., 1-2% per year), accrued continuously and settled onchain at defined intervals. Management fees are independent of performance; they accrue even if the vault is flat or down, within the configured thresholds. ## Performance Fees **Performance fees** align manager incentives with depositors by rewarding positive returns. - **Basis**: Charged as a percentage of realized gains over a reference level. - **Timing**: Charged (crystallized) on predefined events (e.g., rebalance, fee calculation period, or withdrawal), depending on the strategy and vault configuration. - **Reference**: Gains are always computed relative to a **fee model** that defines _when_ and _on what basis_ performance is measured. In the app, the performance fee appears as a percentage with the fee model (for example, "20% performance fee, high-water mark"). ## Fee Models (How Performance Fees Are Calculated) Managers can choose different **fee models** that define when a performance fee is charged. Here are the main models an investor may see. ### Absolute Return In the **absolute** model, performance is measured against a flat baseline: any positive return from the starting point is fee-eligible. - **Reference level**: Starting Net Asset Value (NAV) or the last fee calculation point. - **Fees trigger when**: The vault's value is above this baseline; all positive Profit & Loss (P&L) since the last fee calculation can be charged. ![Absolute fee model](https://docs.orionfinance.ai/img/ABSOLUTE.jpg) ### Hard Hurdle A **hard hurdle** introduces a minimum required return before any performance fee can be charged. - **Reference level**: Starting NAV plus a hurdle rate (e.g., +5%). - **Fees trigger when**: - The vault's performance exceeds the hurdle level, and - Only the return **above the hurdle** is fee-eligible. ![Hard hurdle fee model](https://docs.orionfinance.ai/img/HARDHURDLE.jpg) ### High Water Mark A **high water mark (HWM)** ensures managers only earn performance fees on _new_ highs in the vault's value. - **Reference level**: The highest historical NAV on which a performance fee has previously been charged (the "high water mark"). - **Fees trigger when**: - The vault's value rises above the prior HWM, and - Only gains **above the previous peak** are fee-eligible. - **Drawdown behavior**: After a drawdown, no performance fees are charged until the vault value has recovered past the old HWM. ![High water mark fee model](https://docs.orionfinance.ai/img/HIGHWATERMARK.jpg) ### Soft Hurdle A **soft hurdle** combines aspects of hurdle-based and absolute models. - **Reference level**: Starting NAV plus a hurdle rate. - **Fees trigger when**: - Once the vault's value exceeds the hurdle, performance fees can apply to **all gains**, not just the excess above the hurdle. ![Soft hurdle fee model](https://docs.orionfinance.ai/img/SOFTHURDLE.jpg) ### Hurdle High Water Mark A **hurdle high water mark (Hurdle HWM)** combines a hurdle rate with a high water mark, providing both a minimum return threshold and protection against charging fees on recovered losses. - **Reference level**: The higher of: - Starting NAV plus a hurdle rate (e.g., +5%), or - The highest historical NAV on which a performance fee has previously been charged (the high water mark). - **Fees trigger when**: - The vault's value exceeds both the hurdle-adjusted starting NAV and the prior HWM, and - Only gains **above the reference level** are fee-eligible. - **Drawdown behavior**: After a drawdown, no performance fees are charged until the vault value has recovered past both the hurdle-adjusted starting NAV and the old HWM. ## Protocol Fees ### Protocol Revenue Share - **Revenue-share model:** Orion earns a **protocol fee as a share of Vault fees**. - **Default setting:** The protocol currently takes **10% of the Vault's fee take** (i.e., 10% of the total % of profits earned as fees). - **Accounting:** This split is handled automatically at the protocol level; managers configure gross fees, and the protocol retains its share from that amount. - **Maximum Protocol Fee:** 20% (currently configured at **10%**). ### Withdrawing Accrued Fees The protocol and manager can periodically **withdraw their accrued fees**: - They may withdraw **some or all** of the fees that have built up over time. - This withdrawal is part of normal vault operations and does not introduce extra charges beyond the configured fees already shown. ## What This Means for Investors Before depositing into a vault: - **Review the fee section** on the vault page, check both the management and performance fee percentages. - **Understand the fee model**, look for whether the vault uses absolute, hard hurdle, high water mark, soft hurdle, or hurdle high water mark. - **Track updates**, if a manager changes their fees, those changes will be visible in the app and should be clearly communicated to depositors. The decision to accept a vault's fee terms stays with the depositor. --- # Security > The official Orion app is **[app.orionfinance.ai](https://app.orionfinance.ai)**. Bookmark it and always confirm the URL uses HTTPS before connecting a wallet. For security-related questions or to report a vulnerability, contact **[security@orionfinance.ai](mailto:security@orionfinance.ai)**. Do not open a public GitHub issue. During a protocol incident, follow **[Incident Response](/developer/security/incident-response)** and treat only [official channels](/developer/security/incident-response#official-channels) as authentic. Ignore DMs that ask you to sign, "validate," or visit a new URL. ## Before you Connect - **[Accessing the App](/user/getting_started/accessing-the-app)** - official URL, bookmarking, HTTPS - **[Connecting a Wallet](/user/getting_started/connecting-a-wallet)** - supported wallets and connect flow ## Transactions and Approvals - **[Transaction Flow](/user/getting_started/transaction-flow)** - what each wallet prompt means, exact-amount approvals, vault as spender, and revoking allowances on [revoke.cash](https://revoke.cash) ## Protocol Security - **[Security overview](/developer/security/overview)** - disclosure, audits, and trust assumptions - **[Incident Response](/developer/security/incident-response)** - public response plan and communication channels - **[Risks](/developer/security/risks)** - smart contract, execution, oracle, and user-side security risks --- # Financial Machine Learning > Orion supports **financial machine learning (FML)** as one approach to portfolio construction and rebalancing. FML can simplify allocation decisions, inform systematic rebalancing, and automate intent generation under defined rules, though model output remains a candidate allocation, not a guarantee of future performance. Orion enables two core approaches: - **Passive portfolio construction**, powered by DeFi-native indexing and onchain metrics; - **Active, ML-driven management**, where models inform allocation and rebalancing. This dual system lets vaults range from **hands-off, rules-based strategies** to **model-informed allocations** within Orion's unified framework. ## DeFi-Native Indexing Orion enables a marketplace for **onchain indexes**: passive portfolios based on predefined rulesets, rebalanced automatically, and tokenized as ERC-20s. In this model: - Managers define index weights based on asset classes, themes, or rulesets; - Managers may use APIs from [skfolio](https://skfolio.org/) to define **quantitative finance metrics** (e.g., covariance, tail risk, train-test split) that inform **strategist intents** submitted to the Protocol; - Index logic may be referenced onchain via **IPFS CIDs** pointing to [dockerized](https://www.docker.com/) portfolio management logic, supporting **design goals** for verifiable index construction.
Example of a ruleset ```python from skfolio import RiskMeasure from skfolio.optimization import MeanRisk, ObjectiveFunction X = get_universe_returns() model = MeanRisk( risk_measure=RiskMeasure.STANDARD_DEVIATION, objective_function=ObjectiveFunction.MAXIMIZE_RATIO, portfolio_params=dict(name="Max Sharpe"), ) model.fit(X) model.weights_ ```
This supports user-defined indexes based on financial machine learning rulesets, with methodology pinned for reproducibility. ![Cards](https://docs.orionfinance.ai/img/Cards.png) ### Trust Guarantees Each step of this process is **verifiable and reproducible**: - **Provenance**: Methodology + data pinned on IPFS and CID pinned onchain; - **Reproducibility**: Anyone can rerun the pipeline and validate the output; - **Audit Trail**: All updates and rebalances are logged transparently onchain. ## Active Management: ML-Optimized Vaults For managers seeking more sophisticated exposure, Orion supports **financial machine learning (FML)** pipelines that inform allocation, rebalancing, and dynamic optimization. Common model families include: - Hierarchical risk parity; - Expected return models; - Online learning for portfolio allocation. These models are either: - **Hardcoded into the vault strategy**, based on parameterized ML outputs, or - **Queried dynamically** via oracles or offchain computation layers (e.g., zkML, verifiable compute). Orion abstracts this complexity for users, providing data, SDKs and tooling, while allowing managers and strategists to tune model parameters, override logic, or compose hybrid strategies. --- # Privacy & Confidential Execution > DeFi is transparent by default, which supports auditability but can limit how portfolio managers protect proprietary allocation logic. ## Why Privacy Matters for Portfolio Managers **Vault management** on public blockchains is a viable business model, but its long-term viability can be constrained when real-time portfolio composition and trading behavior are visible to anyone. **Vault tokenization standards** commonly expose holdings and rebalance activity. Observers can monitor, reverse-engineer, and replicate strategies without bearing the associated research and execution costs. Without confidentiality options, managers who wish to avoid liquidity fragmentation face a trade-off between: - Sharing allocation moves and risking loss of edge, or - Operating off-chain, which reduces onchain auditability and composability. For professional portfolio management to scale onchain, **confidentiality** is treated as a first-class primitive alongside composability and security. ## HPKE-Sealed Encrypted Vaults Managers can create either a **transparent** or a **private (encrypted)** vault. Encrypted vaults store strategist intents and portfolio state as **opaque ciphertexts** sealed with Orion's HPKE profile. | Payload | HPKE info label | Onchain surface | | -------------------------- | -------------------- | ------------------------------------------------------------------------ | | Target allocation (intent) | `ORION_INTENT_V1` | Stored as ciphertext; submit emits `ConfidentialOrderSubmitted` | | Holdings (portfolio) | `ORION_PORTFOLIO_V1` | Stored as ciphertext; epoch updates emit `ConfidentialVaultStateUpdated` | Sealing happens offchain (app or SDK) before `submitIntent`. The vault stores the ciphertext; it does not accept plaintext allocation vectors for encrypted vaults. ### Public vs private surfaces Still public on encrypted vaults: - Performance: TVL (`totalAssets`), share price, high-water mark - Deposit and redeem request activity - Vault configuration (fees, strategist, access control) Sealed (not publicly readable as plaintext): - Allocation weights in the intent - Per-asset holdings in the portfolio Transparent vaults continue to emit plaintext `OrderSubmitted` and `VaultStateUpdated` events, including assets, weights, and shares. Encrypted vaults instead emit the confidential variants, without revealing those arrays. This keeps allocation details hidden from public observers between epochs. Trade execution continues to run through Orion's asynchronous orchestrator and adapters, while batching and netting help reduce the frontrunning surface. --- # From Intent to Trades > With prices available, Orion translates the strategist's intent into a concrete rebalance plan: the system compares the vault's current holdings to the target allocation implied by the intent. For each asset, it determines whether the vault is over- or under-allocated and computes the corresponding amount to **sell** or **buy**. ## Deterministic Trade Generation This process is **deterministic**: given the same intent, prices, and vault state, the same set of trades will always be produced. There is no discretion, optimization, or routing logic at this stage, only a mechanical conversion from desired portfolio weights to required asset movements. ## Sequential Failure Recalibration Orion implements a **sequential failure recalibration** mechanism: the order generation engine is a deterministic state machine that handles execution failures while preserving critical invariants: ### Core Invariants - **Index ordering**: Failures are processed one at a time in ascending order. Once an asset fails at a given index, all subsequent recalibration logic applies only to assets with higher indices. Assets that have already been processed (including failed ones) are never modified, ensuring deterministic state progression. - **Self-financing**: The system preserves the self-financing property. This ensures the portfolio remains fully invested without requiring external capital. - **Reproducibility**: The entire recalibration process is reproducible from onchain states. ### Failure Handling Mechanisms **Sell failures**: When a sell order fails, the system applies two-leg scaling: - The scaling factor is calculated as the ratio of the failed sell notional to the sum of total sell and buy notional - All remaining sell orders are scaled up proportionally, while all buy orders are scaled down proportionally - This preserves the self-financing property while adjusting for the failed sell **Buy failures**: When a buy order fails: - The failed asset is locked (no further trades attempted) - Its notional is reallocated to the underlying asset index as buy shares - This ensures capital remains deployed while respecting execution constraints ### Security Properties Assumptions made during this step are later **revalidated during execution**. If market conditions change or constraints are violated, execution will revert rather than silently deviating from the intent. The sequential, index-ordered processing ensures that: - State transitions are deterministic and verifiable onchain; - No partial state corruption can occur; - The system can recover from individual asset failures without compromising the overall rebalance; - All recalibrations maintain the self-financing invariant, protecting against capital leakage. --- # Price Discovery > Once an intent is submitted, Orion must determine current prices to translate target weights into executable trades. Price discovery is handled through dedicated **price adapters**, which provide the value of each asset in terms of the vault's underlying asset. This is particularly important when dealing with yield-bearing instruments or vault shares, where the price is not simply a spot market quote. By isolating pricing logic into adapters, Orion avoids embedding assumptions directly into execution. This makes pricing transparent, auditable, and easier to evolve over time. --- # Settlement and Vault Updates > Once all trades complete successfully, the system finalizes the rebalance by updating the vault's state. The vault's portfolio holdings are rewritten to reflect the new allocation, and total assets are recalculated based on post-execution balances. The share price is updated accordingly, and performance fee logic, such as high-water mark tracking, is applied if relevant. All of this happens **atomically**: either the entire rebalance settles cleanly, or no state changes occur at all. After settlement, the vault returns to an **idle state**, ready for new intents, deposits, or withdrawals. The full rebalance cycle remains permanently recorded onchain, providing a transparent and auditable history of strategy decisions and execution outcomes. --- # Slippage and Buffer > Execution risk is one of the primary sources of hidden cost in portfolio management. Orion addresses this risk at the level of individual trades and at the system level. Slippage controls and execution buffers are part of a framework designed to manage execution variance, preserve capital efficiency, and reduce market impact across multiple vaults. ## Slippage as a Risk Control Mechanism In Orion, slippage is treated as a hard risk constraint: for every trade derived from an intent, the system **atomically** compares the expected execution outcome with the actual amount required or received at execution time. If the deviation exceeds the configured tolerance, execution reverts entirely. This ensures that the vault never unknowingly accepts worse-than-expected prices due to liquidity fragmentation, adverse selection, or sudden market movement. ## Buffers and Deterministic Execution In practice, the prices used to _plan a rebalance_ and the prices encountered during _execution_ are never perfectly identical. Orion computes portfolio targets using oracle-based price adapters, while execution interacts with live protocol state. Execution buffers exist to absorb this inevitable mismatch between planning prices and execution prices. ## Capital Efficiency Through Netting When multiple vaults submit intents concurrently, Orion can net buy and sell flows across vaults at the system level before touching external liquidity. Internal netting reduces the amount of capital that must be moved onchain and limits exposure to external execution venues. This improves capital efficiency while preserving strict intent fidelity for each vault. When opposing flows cancel internally, fewer assets need to be bought or sold externally. This lowers price impact and reduces the slippage pressure associated with each vault rebalancing independently. --- # Trade Execution > Actual asset movements are performed by the **Liquidity Orchestrator**, using specialized **execution adapters**. Execution adapters encapsulate the logic required to interact with specific asset types or protocols. Execution is atomic and tightly controlled: only the **Liquidity Orchestrator** can call execution adapters, and every trade revalidates asset compatibility and execution assumptions. If assumptions are not met (e.g., high slippage), the system skips that position without deploying capital, while other positions in the portfolio continue to execute normally. This modular design allows Orion to support a range of assets without compromising security or clarity. Strategists never interact with execution adapters directly, and adapters cannot alter portfolio intent. --- # Verifiable Execution (zkVM) > Orion uses a zero-knowledge virtual machine (zkVM), powered by [Succinct](https://succinct.xyz/), so that heavy order-generation logic runs offchain while the chain verifies a small proof. Many vaults and assets can be rebalanced in one epoch with verification cost that does not scale linearly with order count. ## How It Fits in the Flow 1. The **Liquidity Orchestrator** reads prices from oracles and commits the current **protocol state** onchain (a compact commitment, not the full state). 2. An **offchain keeper** runs the order-generation logic inside a zkVM circuit. The circuit computes both an **input commitment** (from the committed state and prices) and an **output commitment** (from the generated orders). 3. The zkVM produces a **zero-knowledge proof** that attests: "the output commitment is the correct result of running the order-generation logic on the input commitment." The proof does **not** take the raw orders as input, only the commitments, so **proof size and verification cost stay constant** even as the number of vaults and orders grows. 4. The state machine that drives this process is **fault tolerant**: if a step fails, the system can recover and retry without corrupting state. 5. Onchain, the **Liquidity Orchestrator** receives the proof plus the actual order payload. It **validates** the proof using the verification key, the proof, and the committed state (checking that the output commitment matches). **Only after validation** does it use the payload to move liquidity and update vault accounting. ## Why This Matters for Managers - **Verifiability**: Every rebalance is cryptographically verified onchain; the chain does not apply the keeper's output without a valid proof. - **Scalability**: Expensive computation stays offchain; the chain verifies a small proof, so verification cost does not grow with the number of vaults or orders. - **Safety**: Validation (verification key, proof, and state) happens before any liquidity movement or accounting change, so invalid or tampered orders are not applied. --- # Role of a Manager in Orion > In Orion, a **manager** is a portfolio manager who designs, launches, and maintains onchain investment strategies. Managers can range from individual traders to professional teams. A manager's responsibilities include: - Designing portfolio strategies that align with a specific objective (e.g., passive index, active trading, sector-based allocation). - Choosing the vault type: **transparent** (visible allocation) or **private** (confidential allocation). - Setting performance and management fees. - Managing the vault over time, including monitoring performance and adjusting allocations at each rebalance. Orion handles execution, fee accounting, performance tracking, and, when enabled, privacy-preserving trade settlement. Independent [security audits](https://github.com/OrionFinanceAI/protocol/tree/main/audits) are published in the public repository. For disclosure and incident communications, see [Security](/developer/security/overview) and [Incident Response](/developer/security/incident-response). ## Two starting points Vault creation is **permissioned**. The path forward depends on whether the manager's wallet address is already whitelisted. ### Not yet whitelisted A manager cannot create vaults until onboarding is complete. 1. Optional: skim the product from an investor's view; [What is Orion?](/user/intro), [How it works](/user/how-it-works), [Accessing the app](/user/getting_started/accessing-the-app), [Connecting a wallet](/user/getting_started/connecting-a-wallet). 2. Complete [Manager onboarding](https://docs.orionfinance.ai/manager/portfolio-manager-onboarding.md) to get manager wallet addresses approved. 3. Return here and continue under **Already whitelisted**. ### Already whitelisted The rest of the manager docs assume a whitelisted wallet. Follow this order: 1. Optional: understand [fee models](https://docs.orionfinance.ai/manager/setup/fee-model.md) before setting fee type when creating a vault. Production is Ethereum Mainnet; Sepolia is an optional testnet, see [Getting ETH on Sepolia](/user/getting_started/getting-eth-sepolia). 2. [Create a vault](https://docs.orionfinance.ai/manager/setup/vault-creation.md) (app or SDK) 3. [Submit intents as strategist](https://docs.orionfinance.ai/manager/setup/strategist-role.md) 4. Optional: explore [execution and rebalancing](https://docs.orionfinance.ai/manager/execution/from-intent-to-trades.md), [transaction costs](https://docs.orionfinance.ai/manager/setup/transaction-costs.md), and [vault access control](https://docs.orionfinance.ai/manager/setup/access-controller.md) --- # Manager Onboarding > Orion vault creation is permissioned. A manager must complete onboarding before creating or operating vaults. User investing generally remains open unless otherwise noted in the app. This page covers managers who are **not yet whitelisted**. After approval, continue with [Vault creation](https://docs.orionfinance.ai/manager/setup/vault-creation.md). Managers new to Orion may skim the [manager introduction](https://docs.orionfinance.ai/manager/intro.md) and optional [user docs](/user/intro) so the infrastructure is clear before requesting access. ## Who should onboard? - Professional portfolio managers and teams - Independent managers who intend to create and operate vaults ## Wallet compatibility Orion requires an **EVM wallet address** for vault management. Managers may use the custody and signing setup that matches their operational needs: - **Hot wallets** - **Cold wallets** - **Multisig / Safe** - **MPC wallets** The same onboarding and whitelisting flow applies regardless of wallet type. For day-to-day app use, see [Connecting a wallet](/user/getting_started/connecting-a-wallet). ## Onboarding steps 1. Request access - Contact the Orion team by [scheduling a call](https://calendly.com/zoe-orionfinance/30min) to start onboarding, providing a brief description of strategy focus and operational setup. 2. Organization verification (KYB/KYC) - Complete standard compliance checks for the organization and authorized signers. 3. Wallet verification - Share the onchain addresses that will be used for vault administration. - Orion will verify control and associate them with the organization. 4. Role assignment and whitelisting - Whitelisted addresses are granted manager/portfolio manager permissions required to deploy and manage vaults. 5. Sandbox access (optional but recommended) - Test flows on Sepolia using the app or SDK before Ethereum Mainnet. - Use [Accessing the app](/user/getting_started/accessing-the-app) and [Getting ETH on Sepolia](/user/getting_started/getting-eth-sepolia). 6. Production enablement - After validation, addresses are enabled to create vaults in production. ## After you are whitelisted Once whitelisted, create and operate vaults here: - [Vault creation](https://docs.orionfinance.ai/manager/setup/vault-creation.md): app screenshots, Create Vault video, and Python SDK demo - [Strategist role](https://docs.orionfinance.ai/manager/setup/strategist-role.md): submit allocation intents - [Fee model](https://docs.orionfinance.ai/manager/setup/fee-model.md): performance and management fees (also see [Vault fees for users](/user/key_features/vault-fees)) ## Updating whitelisted addresses - To add or remove manager addresses, [schedule a call](https://calendly.com/zoe-orionfinance/30min) with the Orion team. Changes will be applied after verification. ## Support - For onboarding or operational questions, reach out to the Orion team through [official channels](/user/intro#official-channels). --- # Vault Access Control > Orion vaults support three **optional** access-control slots. Each slot is an independent smart contract. Managers use them to restrict who may deposit, who may hold vault shares, and who may transfer shares between wallets without changing core vault logic. `address(0)` on a slot means that dimension is **permissionless**. ## Three access-control slots | Slot | Protocol interface | Checked when | | ------------ | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------- | | **Deposit** | [`IOrionDepositAccessControl`](/developer/smart-contracts/interfaces/IOrionAccessControl) | An address calls `requestDeposit` | | **Holder** | [`IOrionHolderAccessControl`](/developer/smart-contracts/interfaces/IOrionAccessControl) | Shares are minted to an account or transferred **to** an account | | **Transfer** | [`IOrionTransferAccessControl`](/developer/smart-contracts/interfaces/IOrionAccessControl) | Shares are transferred **from** an account (P2P transfers) | Redemptions are **not** gated by access control. ## Configuring access control Set all three addresses at [vault creation](https://docs.orionfinance.ai/manager/setup/vault-creation.md) (`depositAccessControl`, `holderAccessControl`, `transferAccessControl`). The manager may update any slot later via `setDepositAccessControl`, `setHolderAccessControl`, and `setTransferAccessControl`. A single contract may implement one, two, or all three interfaces. Pass the same address to multiple slots when the policy should apply uniformly (e.g. whitelist on deposit, hold, and transfer). ## Deploying a controller Implementations live in [`protocol-plugins`](https://github.com/OrionFinanceAI/protocol-plugins) (`contracts/access_controllers/`, `contracts/strategies/`). Deploy with that repo’s CLI: copy `.env.example` to `.env` in `protocol-plugins` and set `PRIVATE_KEY` plus `SEPOLIA_RPC_URL` or `MAINNET_RPC_URL` for the target chain. Then, for example: ```bash PLUGIN=whitelist OWNER=0x... pnpm deploy:sepolia PLUGIN=whitelist OWNER=0x... pnpm deploy:mainnet ``` `WhitelistAccessControl` can be passed to deposit, holder, and transfer. Stateless gates such as `manager-only` and `non-transferable` are safe to reuse network-wide; whitelist instances are typically per-manager. ## Related Pages - [Vault creation](https://docs.orionfinance.ai/manager/setup/vault-creation.md) - [IOrionAccessControl API](/developer/smart-contracts/interfaces/IOrionAccessControl) - [Roles and permissions](/developer/security/permissions) - [protocol-plugins](https://github.com/OrionFinanceAI/protocol-plugins) --- # Vault Fees > **Vault fees** are the management and performance charges a manager **configures** when creating or operating a vault on Orion. Fee configuration remains a manager responsibility even when rebalancing is delegated to a separate strategist (or when the manager acts as the strategist). At vault creation, a manager configures: - **Management fee** - a recurring fee on total value locked (TVL) - assets under management (AUM), with a protocol-enforced maximum of **3%** per year. - **Performance fee** - a fee on generated returns, with a protocol-enforced maximum of **30%** of profits. These caps are protocol guardrails that limit how high fees can be set across Orion vaults. Both fee types: - Are subject to **protocol-level maximums and guardrails** - the UI and SDK prevent you from setting fees above these caps. - Are subject to an **immutable 7-day delay** before changes take effect: when you change management fees, performance fees, or fee type/model, the change takes effect after 7 days. You can make additional changes at any time; if you make a new change before the 7 days are up, the timer resets for the new change, giving depositors time to react to pending changes. Users will see updated values in the app before they take effect. ## Management Fees **Management fees** compensate managers for ongoing portfolio design, monitoring, and operations. - **Basis**: Charged as an annualized percentage of vault assets under management (AUM) (e.g., 1-2% per year), accrued continuously and settled onchain at defined intervals. Management fees are independent of performance; they accrue even if the vault is flat or down, within the configured thresholds. ## Performance Fees **Performance fees** align manager incentives with depositors by rewarding positive returns. - **Basis**: Charged as a percentage of realized gains over a reference level. - **Timing**: Crystallized on predefined events (e.g., rebalance, crystallization epoch, or withdrawal), depending on the strategy and vault configuration. - **Reference**: Gains are always computed relative to a **fee model** that defines _when_ and _on what basis_ performance is measured. Orion supports multiple performance fee models so managers can match their business model and investor expectations. ## Supported Performance Fee Models ### Absolute Return In the **absolute** model, performance is measured against a flat baseline: any positive return from the starting point is fee-eligible. - **Reference level**: Starting Net Asset Value (NAV) or the last crystallization point. - **Fees trigger when**: The vault’s value is above this baseline; all positive Profit & Loss (P&L) since the last crystallization can be charged. ![Absolute fee model](https://docs.orionfinance.ai/img/ABSOLUTE.jpg) ### Hard Hurdle A **hard hurdle** introduces a minimum required return before any performance fee can be charged. - **Reference level**: Starting NAV plus a hurdle rate (e.g., +5%). - **Fees trigger when**: - The vault’s performance exceeds the hurdle level, and - Only the return **above the hurdle** is fee-eligible. ![Hard hurdle fee model](https://docs.orionfinance.ai/img/HARDHURDLE.jpg) ### High Water Mark A **high water mark (HWM)** ensures managers only earn performance fees on _new_ highs in the vault’s value. - **Reference level**: The highest historical NAV on which a performance fee has previously been charged (the “high water mark”). - **Fees trigger when**: - The vault’s value rises above the prior HWM, and - Only gains **above the previous peak** are fee-eligible. - **Drawdown behavior**: After a drawdown, no performance fees are charged until the vault value has recovered past the old HWM. ![High water mark fee model](https://docs.orionfinance.ai/img/HIGHWATERMARK.jpg) ### Soft Hurdle A **soft hurdle** combines aspects of hurdle-based and absolute models. - **Reference level**: Starting NAV plus a hurdle rate. - **Fees trigger when**: - Once the vault’s value exceeds the hurdle, performance fees can apply to **all gains**, not just the excess above the hurdle. ![Soft hurdle fee model](https://docs.orionfinance.ai/img/SOFTHURDLE.jpg) ### Hurdle High Water Mark A **hurdle high water mark (Hurdle HWM)** combines a hurdle rate with a high water mark, providing both a minimum return threshold and protection against charging fees on recovered losses. - **Reference level**: The higher of: - Starting NAV plus a hurdle rate (e.g., +5%), or - The highest historical NAV on which a performance fee has previously been charged (the high water mark). - **Fees trigger when**: - The vault's value exceeds both the hurdle-adjusted starting NAV and the prior HWM, and - Only gains **above the reference level** are fee-eligible. - **Drawdown behavior**: After a drawdown, no performance fees are charged until the vault value has recovered past both the hurdle-adjusted starting NAV and the old HWM. ## Protocol Fees ### Protocol Revenue Share - **Revenue-share model:** Orion earns a **protocol fee as a share of Vault fees**. - **Default setting:** The protocol currently takes **10% of the manager’s fee take** (i.e., 10% of the total % of profits you earn as fees). - **Accounting:** This split is handled automatically at the protocol level; you configure your gross fees, and the protocol retains its share from that amount. - **Maximum Protocol Fee:** 20% (currently configured at **10%**). ### Withdrawing Accrued Fees Both **managers and the protocol** can withdraw accrued fees: - You may request to withdraw **all or part** of the fees that have accumulated. - Withdrawals follow the protocol’s accounting and crystallization logic and do not affect user-facing fee percentages beyond what has already accrued. - Operationally, this allows you to realize fee revenue while keeping vault accounting clean and verifiable onchain. ## Choosing Your Fee Configuration When configuring a vault: - **Set fees for**: - Management; - Performance; - **Choose the fee type**: absolute, hard hurdle, high water mark, soft hurdle, or hurdle high water mark. Considerations when choosing a fee configuration: - **Align incentives** - choose fee levels that are attractive to depositors while reflecting your strategy’s complexity and cost. - **Communicate clearly** - proactively communicate any future fee changes to existing and prospective depositors. - **Consider volatility** - strategies with high volatility often pair well with HWM or hurdle-based structures to avoid over-charging in choppy markets. Fee accounting and crystallization are handled by the protocol; managers configure fees at vault creation and when submitting fee changes. --- # Strategist Role > This page assumes you are already **whitelisted** and have [created a vault](https://docs.orionfinance.ai/manager/setup/vault-creation.md). ## Overview Each Orion vault is managed by a **Strategist**. The strategist defines the portfolio allocation by submitting an **intent**. An intent is a target portfolio allocation across a set of assets. It expresses _what_ the portfolio should look like, not _how_ trades are executed. Execution and settlement are handled by the Orion orchestration layer. Strategists can be implemented in two ways: - **Active Strategist**: an externally owned account (EOA) submitting intents manually. - **Passive Strategist**: a smart contract that computes and submits intents programmatically. Both approaches use the same vault interface and execution pipeline. ## Strategist Types ### Active Strategist (EOA) In the simplest setup, the strategist is a wallet address. Characteristics: - Submits intents directly to the vault (plaintext for transparent vaults; HPKE-sealed ciphertext for private vaults). - Suitable for discretionary or semi-manual portfolio management. - Can be automated off-chain (e.g. [quant pipelines](https://docs.orionfinance.ai/manager/advanced/financial-machine-learning.md)). This approach offers flexibility but relies on off-chain logic. For how sealing works on private vaults, see [Privacy & Confidential Execution](https://docs.orionfinance.ai/manager/advanced/privacy-and-confidential-execution.md). ### Passive Strategist (Smart Contract) A passive strategist is a smart contract that implements the `IOrionStrategist` interface. Characteristics: - Computes portfolio allocations on-demand. - Encodes allocation logic directly onchain. - Enables transparent, auditable, and trust-minimized strategies. This model suits systematic strategies (e.g. TVL-weighted, volatility-adjusted, factor-based) and encoding index logic onchain. ## What Is an Intent? In Orion, execution always begins with an **intent**: a list of `(asset, weight)` pairs that defines the desired portfolio composition. Key properties: - Only whitelisted assets can be included. - Weights are positive-definite and sum to 100%. Note that strategies can still achieve leveraged or short exposure by holding leveraged tokens, short tokens, or other derivative assets in the investment universe. - Intents are validated onchain before being accepted. Once submitted, an intent becomes the authoritative target state for the vault until a new intent is provided by the strategist. ## Submit an intent As an active strategist, you can submit intents from the **Orion app** or the **[Orion SDK](https://sdk.orionfinance.ai/)**. Both set the same onchain target allocation for the vault. ### In the app Open **Manage** on a vault, choose **Rebalance**, set the target allocation, and confirm onchain. #### Open Manage You can reach the manage flow from either place: **From My Portfolio** - In **Managed Vaults**, open the gear icon under **Actions** for an active vault. ![Open Manage from My Portfolio](/img/manage_from_my_portfolio.png) **From the vault page** - Open the vault and click **Manage**. ![Open Manage from the vault page](/img/manage_from_your_vault.png) #### Choose Rebalance In **Manage Vault**, select **Rebalance** to submit a new portfolio allocation intent. ![Select Rebalance in Manage Vault](/img/manage_rebalance_option.png) #### Set allocation and submit Add assets, set weights so the total is **100%**, then submit. The composition chart updates as you edit. ![Submit your intent portfolio](/img/rebalance_complete_intent.png) After the transaction confirms, you see an **Intent Submitted** confirmation with the vault address, transaction hash, and allocation summary. ![Intent submitted confirmation](/img/rebalance_intent_submission_confirmation.png) For **private (encrypted) vaults**, the app seals the allocation with HPKE before the onchain call. Plaintext weights are not stored onchain for those vaults; investor-facing vault pages also hide allocation charts. ### With the SDK Submit the same `(asset, weight)` intent programmatically via the [Orion SDK](https://sdk.orionfinance.ai/). For private vaults, seal the intent with the SDK (or another HPKE-compatible client) before `submitIntent`. See also the [SDK vault-creation demo](https://docs.orionfinance.ai/manager/setup/vault-creation.md#create-a-vault-with-the-sdk) for related setup. The submitted intent remains the vault's target allocation until you submit a new one. For how intents become trades, see [From intent to trades](https://docs.orionfinance.ai/manager/execution/from-intent-to-trades.md). --- # Transaction Cost Considerations > **Transaction costs** in on-chain execution decompose into two components that can be **analyzed separately**, even though both can apply to the same trade: - **Execution cost (gas)**, driven by computational complexity - **Market impact (slippage)**, driven by trade size and liquidity These components have different drivers and should be reasoned about on their own terms. ## Gas Costs: Computation-Driven Gas represents the cost of executing transactions on-chain. - Operation-based pricing. Each instruction (transfers, swaps, contract calls) consumes gas. - Independent of notional size. Moving \$1,000 or \$1,000,000 through the same execution path incurs the same gas cost. - Scales with computational complexity. More steps, interactions, or contracts increase total gas usage. As a result, gas behaves like a fixed cost per execution path, not a function of capital deployed. ## Market Impact: Liquidity-Driven Market impact captures how execution affects price. - **Market impact** - Large trades can move prices, especially in less liquid markets. - **Price deviation** - The execution price may differ from the expected price due to market conditions. - **Liquidity constraints** - Insufficient liquidity can result in worse execution prices. Orion addresses slippage through: - **Slippage controls** - Hard limits on acceptable price deviation during execution. - **Batching and netting** - Grouping transactions reduces individual market impact. - **Execution buffers** - Absorbing small price differences between planning and execution. See [Slippage and Buffer](https://docs.orionfinance.ai/manager/execution/slippage-and-buffer.md) for more details on how Orion manages execution risk. ## Cost Efficiency Through Orion's Architecture Orion's design further optimizes transaction costs through: - **Bundling** - Multiple operations in a single transaction reduce total gas usage. - **Batching** - Sharing gas costs across multiple vaults and participants. - **Netting** - Internal matching of buy/sell orders before external execution reduces unnecessary trades. These mechanisms are intended to keep transaction costs comparatively lower and more predictable relative to isolated per-vault execution, though actual costs still depend on network conditions and liquidity. --- ## Related Pages - [Slippage and Buffer](https://docs.orionfinance.ai/manager/execution/slippage-and-buffer.md) - [Trade Execution](https://docs.orionfinance.ai/manager/execution/trade-execution.md) - [Vault Fees](https://docs.orionfinance.ai/manager/setup/fee-model.md) --- # Vault Creation > This page assumes you are already **whitelisted** as a manager. If you are not, complete [Manager onboarding](https://docs.orionfinance.ai/manager/portfolio-manager-onboarding.md) first. In Orion, a vault is an [ERC-7540](/developer/contract-standards#eips) smart contract that acts as a container for strategy parameters, fee structure, access controls, and accounting. There are two main types: - **Transparent vaults**: Portfolio allocations are visible onchain. - **Private (encrypted) vaults**: Allocation weights and holdings are HPKE-sealed offchain before `submitIntent`, and the resulting ciphertext is stored onchain, while performance (TVL, share price) and deposit/redeem activity remain verifiable, protecting manager alpha (competitive advantage or strategy edge). How vaults appear to investors: [Permissioned vaults](/user/key_features/permissioned-vaults), [Understanding vault metrics](/user/getting_started/understanding-vault-metrics), and [Privacy](/user/key_features/privacy). You can create vaults in the **app** or with the **Python SDK**. Both configure the same parameters. ## Create a vault in the app Connect your whitelisted wallet **on the chain where the vault should live** (Ethereum Mainnet for production, Sepolia for testnet), then open **Create Vault** from your wallet menu in the top right. ![Open Create Vault from the wallet menu](/img/create_vault_button.png) The flow has three steps: **Identity**, **Access**, and **Fees**. A live preview on the right updates as you go. ### 1. Identity Choose vault type (transparent or private), then set the vault name and symbol. ![Create Vault - Identity step](/img/create_vault_identity.png) ### 2. Access Set the [strategist](https://docs.orionfinance.ai/manager/setup/strategist-role.md) address (defaults to your connected wallet; use **My Address** to fill it) and optional [access control](https://docs.orionfinance.ai/manager/setup/access-controller.md) contracts for deposits, share holding, and transfers. Leave each slot empty or use **Permissionless** for open access on that dimension. ![Create Vault - Access step](/img/create_vault_access.png) ### 3. Fees Choose a [fee model](https://docs.orionfinance.ai/manager/setup/fee-model.md) and set performance and management fees within protocol caps (up to **30%** performance and **3%** management). Confirm with **Create Vault**. ![Create Vault - Fees step](/img/create_vault_fees.png) ### App video walkthrough Video of the Create Vault flow in the Orion app. After the vault is deployed, submit an allocation intent as the strategist; see [Strategist role](https://docs.orionfinance.ai/manager/setup/strategist-role.md#submit-an-intent). ## Create a vault with the SDK Programmatic vault deployment uses the same parameters as the app. GIF walkthrough of the Python SDK flow: ![Manager SDK Demo](/img/manager_sdk.gif) Full API reference: [Orion SDK](https://sdk.orionfinance.ai/). ## Configuration parameters | Parameter | Description | | ----------------------- | ---------------------------------------------------------------------------------------------- | | `strategist` | The address of the [Strategist](https://docs.orionfinance.ai/manager/setup/strategist-role.md). | | `name` | The human-readable name of the vault. | | `symbol` | The symbol of the token representing the vault shares. | | `feeType` | The [Vault Fees](https://docs.orionfinance.ai/manager/setup/fee-model.md) Model. | | `performanceFee` | The performance fee in basis points. | | `managementFee` | The management fee in basis points. | | `depositAccessControl` | Optional [deposit access controller](https://docs.orionfinance.ai/manager/setup/access-controller.md) (`address(0)` = permissionless). | | `holderAccessControl` | Optional [holder access controller](https://docs.orionfinance.ai/manager/setup/access-controller.md) (`address(0)` = permissionless). | | `transferAccessControl` | Optional [transfer access controller](https://docs.orionfinance.ai/manager/setup/access-controller.md) (`address(0)` = permissionless). | **Note:** 1 basis point = 0.01% --- # Contract Addresses > --- ## Ethereum Mainnet | Name | Contract Address | | ----------- | --------------------------------------------------------------------------------------------------------------------- | | Admin | [0x227c0703952b559404FDBEec32bbd8C8224187eD](https://etherscan.io/address/0x227c0703952b559404FDBEec32bbd8C8224187eD) | | OrionConfig | [0xAba49f4eb48659fCb1f891b55D7a7b835C05af5E](https://etherscan.io/address/0xAba49f4eb48659fCb1f891b55D7a7b835C05af5E) | ## Ethereum Sepolia | Name | Contract Address | | ----------- | ----------------------------------------------------------------------------------------------------------------------------- | | Admin | [0x63Fc3BaF5286d929e932baf8876fC428cb5c9CB1](https://sepolia.etherscan.io/address/0x63Fc3BaF5286d929e932baf8876fC428cb5c9CB1) | | OrionConfig | [0xbDe3025d08681a02a1c6cf70375baBe2152DD06f](https://sepolia.etherscan.io/address/0xbDe3025d08681a02a1c6cf70375baBe2152DD06f) | --- ## Related Pages - [Roles and Permissions](https://docs.orionfinance.ai/developer/security/permissions.md) --- # Contract Standards > This section lists [Ethereum Improvement Proposals (EIPs)](https://eips.ethereum.org/) that Orion Finance implements or interoperates with. Each entry summarizes the standard's role; Orion's use of a standard does not imply full compliance with every optional extension in the EIP text. ## EIPs Standard | Description ERC-20 | A standard API for fungible tokens: transfer, allowance, and balance queries. Underlying assets and many portfolio tokens in Orion are ERC-20 compatible. ERC-165 | Interface detection: contracts publish and expose which interfaces they implement. ERC-1967 | Fixed storage slots for proxy implementations and proxy-specific metadata. ERC-3643 | Security-token interfaces for compliant transfer and lifecycle management of permissioned assets. ERC-4626 | Tokenized vault API over a single underlying ERC-20 token: deposit, withdraw, and share accounting. Orion vaults extend this base with asynchronous settlement. ERC-5115 | Interface for wrapped yield-bearing tokens. ERC-7528 | Placeholder address for native ETH when treated alongside ERC-20 tokens in the same call path. ERC-7540 | ERC-4626 extension with asynchronous deposit and redemption flows. ERC-7575 | Extended ERC-4626 interface for multi-asset vaults. ERC-7621 | Collateralized, tokenized funds with adjustable weights, reserves, and LP token mint/burn. ERC-7726 | Interface for data feeds that report relative asset values. ERC-7845 | Universal data model an orchestrator can consume to fulfill wallet or system requests. ERC-7887 | ERC-7540 extension with request cancellation support. ERC-7984 | Confidential fungible tokens using account-based accounting while hiding transfer amounts and balances. --- ## Related Pages - [Protocol Summary](https://docs.orionfinance.ai/developer/intro.md) - [Core Protocol](https://docs.orionfinance.ai/developer/smart-contracts/OrionConfig.md) - [Contract Addresses](https://docs.orionfinance.ai/developer/contract-addresses.md) --- # Diagrams > This page walks through the main Orion protocol flows as sequence diagrams: how liquidity providers deposit and redeem, how managers create vaults and submit intents, how third-party distributors attribute deposits, and how the zkVM keeper drives epoch execution. The diagrams describe intended behavior at a high level. They omit timing edge cases, failure paths, partial fills, and the full escrow path when a holder check fails at fulfillment. ## Liquidity Provider (LP) Journey Orion vaults follow an asynchronous ERC-7540-style model: LPs call `requestDeposit` or `requestRedeem`, requests queue until the next epoch, and the Liquidity Orchestrator fulfills them in batch. Share tokens mint only after `fulfillDeposit` runs at epoch end. Vaults may optionally configure deposit and holder access controllers. At `requestDeposit`, the vault checks both `canRequestDeposit` and `canHoldShares` for the beneficiary. At `fulfillDeposit`, the vault re-checks `canHoldShares` so a mid-epoch policy revoke cannot mint shares; failed checks escrow underlying instead of minting. Transfer access control applies only to P2P share transfers, not to the deposit or redeem paths shown here. Third-party distributors route deposits through `requestDepositFor`; see [Distribution](#distribution) below. ```mermaid sequenceDiagram actor LP as Liquidity Provider participant App as Orion DApp participant Vault participant DepositAC as DepositAccessControl participant HolderAC as HolderAccessControl participant LO as LiquidityOrchestrator LP->>App: Browse available products LP->>App: Select vault and deposit amount App->>Vault: requestDeposit(assets) opt depositAccessControl set Vault->>DepositAC: canRequestDeposit(LP, data) DepositAC-->>Vault: allowed end opt holderAccessControl set Vault->>HolderAC: canHoldShares(LP) HolderAC-->>Vault: allowed end Vault->>LO: Queue deposit for next epoch Note over LO: Asynchronous execution cycle LO->>Vault: fulfillDeposit(depositTotalAssets) opt holderAccessControl set Vault->>HolderAC: canHoldShares(LP) HolderAC-->>Vault: allowed end Vault->>LP: Mint vault shares Note over LP, LO: Ongoing: vault generates profits and losses LO->>Vault: Update share value Note over LP, LO: Withdrawal process LP->>App: Request withdrawal App->>Vault: requestRedeem(shares) Vault->>LO: Queue redemption for next epoch Note over LO: Asynchronous execution cycle LO->>Vault: fulfillRedeem(redeemTotalAssets) Vault->>LP: Burn vault shares Vault->>LP: Transfer underlying assets ``` ## Manager Journey A whitelisted manager deploys a vault through a factory, registers it with the protocol, and assigns a strategist. The strategist submits allocation intents (plaintext on transparent vaults, HPKE-sealed on encrypted vaults). Each rebalancing epoch updates portfolio state, accrues fees, and lets the manager claim vault fees. ```mermaid sequenceDiagram actor Manager participant Strategist participant SDK as Orion SDK participant Factory as Vault Factory participant Vault as Vault participant Protocol as Orion Protocol participant LPs as Liquidity Providers Note over Strategist: Define asset universe,
allocation rules, etc. Manager->>SDK: Define fee model SDK->>Factory: Deploy new vault Factory->>Vault: Create vault Vault->>Protocol: Register vault Note over Manager, LPs: Vault goes live LPs->>Vault: Deposit assets Strategist->>SDK: Submit allocation intents alt Encrypted vault SDK->>SDK: HPKE-seal intent to protocol pkR SDK->>Vault: Submit encrypted intent else Transparent vault SDK->>Vault: Submit plaintext intent end Note over Manager, Protocol: Rebalancing cycle Vault->>Protocol: Update asset allocation Protocol->>Vault: Update States Protocol->>Vault: Calculate & accrue fees Manager->>Vault: Claim Vault fees Protocol->>Vault: Transfer Vault fees Vault->>Manager: Transfer Vault fees ``` ## Distribution **Distribution** lets third parties route user deposits into Orion vaults while attributing flow to a **distributor** identity. Attribution is recorded onchain for analytics, fee sharing, or partner reporting. The reference implementation is [`OrionDistributionRouter`](https://github.com/OrionFinanceAI/protocol-plugins/blob/main/contracts/depositors/OrionDistributionRouter.sol). ### How it works 1. A distributor integrates with `OrionDistributionRouter` (or a front end that calls it). 2. The end user approves underlying assets and calls `requestDepositWithDistribution(vault, distributorId, assets)`. 3. The router verifies the vault is registered in `OrionConfig`, pulls assets from the user, and calls `requestDepositFor(user, assets)` on the vault. 4. The router emits `DistributionDeposit(distributorId, vault, user, assets)` for offchain indexing. ```mermaid sequenceDiagram participant User participant Router as OrionDistributionRouter participant Vault as OrionVault participant Indexer as Offchain indexer User->>Router: requestDepositWithDistribution(vault, distributorId, assets) Router->>Vault: requestDepositFor(user, assets) Router-->>Indexer: DistributionDeposit event Note over Vault: Deposit queued for next epoch ``` ### Relationship to access control Distribution routing does not bypass vault access control. When the router calls `requestDepositFor`, the vault runs the same `_requireCanRequestDeposit` path as a direct LP deposit: both `canRequestDeposit` and `canHoldShares` must pass for the beneficiary. At `fulfillDeposit`, the vault re-checks `canHoldShares` before minting shares. ## zkVM-based Keeper An offchain keeper polls the Liquidity Orchestrator via `checkUpkeep`. When upkeep is needed, it fetches epoch state, runs the zkVM program offchain to decrypt portfolios, generate orders, and produce a proof, then submits the result onchain for verification and execution. ```mermaid sequenceDiagram actor Keeper participant LO as LiquidityOrchestrator participant SP1 as ProverClient participant PROG as zkVM loop Keeper->>LO: checkUpkeep LO-->>Keeper: upkeepNeeded (true/false) alt false Keeper->>Keeper: retry end end Note over Keeper,LO: upkeepNeeded == true, process starts Keeper->>LO: fetch_epoch_state LO-->>Keeper: EpochStateInput Keeper->>SP1: execute SP1->>PROG: run zkVM with EpochStateInput rect rgb(235, 245, 255) PROG->>PROG: decrypt portfolio and intent blobs PROG->>PROG: compute_epoch_state_commit(epoch_state) end PROG->>PROG: generate_orders(epoch_state) rect rgb(235, 245, 255) PROG->>PROG: seal final encrypted portfolios PROG->>PROG: compute_output_commitment(epoch_state) end PROG-->>SP1: Orders, SP1Proof, vk SP1-->>Keeper: Orders, SP1Proof, vk Note over Keeper,LO: State transition generation complete ``` --- ## Related Documentation - [Protocol Summary](./intro) - [Vault access control](/manager/setup/access-controller) - [IOrionVault API](./smart-contracts/interfaces/IOrionVault) - [IOrionAccessControl API](./smart-contracts/interfaces/IOrionAccessControl) - [OrionConfig](https://docs.orionfinance.ai/developer/smart-contracts/OrionConfig.md) --- # LLMs Integration > Orion Finance documentation is published in machine-readable formats for LLM-based tools. ## Index and full corpus | File | URL | | ------------- | ------------------------------------------ | | Page index | https://docs.orionfinance.ai/llms.txt | | Full snapshot | https://docs.orionfinance.ai/llms-full.txt | | Agent skill | https://docs.orionfinance.ai/skill.md | The SDK publishes its own corpus at https://sdk.orionfinance.ai/llms-full.txt. `llms.txt` lists markdown URLs that match the HTML page path with a `.md` suffix (for example `/user/intro` → `/user/intro.md`). Older `/docs/
/...md` URLs remain available as copies. ## Per-page markdown Request markdown in either of these ways: 1. Append `.md` to the HTML path. 2. Send `Accept: text/markdown` on the HTML URL. Examples: | Page | Markdown | | ------------------ | ----------------------------------------------- | | `/user/intro` | https://docs.orionfinance.ai/user/intro.md | | `/manager/intro` | https://docs.orionfinance.ai/manager/intro.md | | `/developer/intro` | https://docs.orionfinance.ai/developer/intro.md | On each documentation page, **Copy page** copies this markdown to the clipboard. **Ask AI** opens Claude or ChatGPT with the same per-page URL. ## Agent skill A `skill.md` capability summary is served at `/skill.md` and advertised at `/.well-known/skills/index.json` and `/.well-known/agent-skills/index.json`. It describes what the docs can answer. It does not submit transactions or replace onboarding. There is no MCP server on this documentation site. Agents should use `llms.txt`, per-page markdown, and `skill.md`. --- # Protocol Summary > The Orion protocol is portfolio management infrastructure for creating and managing investment vaults. It runs on an **epoch-based** schedule: two orchestrator contracts batch deposits, redemptions, and portfolio rebalancing into discrete cycles rather than processing each request immediately. The architecture is modular. Core contracts live in the [protocol](https://github.com/OrionFinanceAI/protocol) repository; optional strategists, access controllers, and distribution helpers live in [protocol-plugins](https://github.com/OrionFinanceAI/protocol-plugins). The sections below describe the main protocol components and how they interact. Security disclosure, audits, and the public incident response plan live under [Security](https://docs.orionfinance.ai/developer/security/overview.md). ## Orion Vaults Orion vaults implement **ERC-4626** with asynchronous deposits and redemptions. Liquidity providers (LPs) deposit a single underlying asset; deposit and redemption requests are queued and settled at the end of each epoch. Batching reduces gas cost per operation and limits front-running within an epoch. It does not remove market risk or guarantee same-block settlement. ## Strategists and Intents Each vault has a **Strategist**, who defines the investment strategy by submitting an **intent**: a target portfolio allocation. A strategist may be **active** (an externally owned account submitting intents: plaintext on transparent vaults, HPKE-sealed ciphertext on encrypted vaults) or **passive** (a smart contract implementing the _[IOrionStrategist](https://docs.orionfinance.ai/developer/smart-contracts/interfaces/IOrionStrategist.md)_ interface that computes the intent on demand). ## Internal State Orchestrator The Internal State Orchestrator coordinates vault-level accounting. An external keeper triggers it on a schedule. It reads each vault's current portfolio and pending strategist intents, calculates fees, processes queued deposits and redemptions to update total assets, and computes the trades required to align portfolios with target intents. It then aggregates those trades into a single net list of buy and sell orders for the protocol. ## Liquidity Orchestrator The Liquidity Orchestrator executes rebalancing. It reads prices from oracles and commits the current protocol state onchain. Order generation runs offchain in a **zkVM** (zero-knowledge virtual machine, powered by [Succinct](https://succinct.xyz/)): the circuit computes commitments to both the input state and the output orders, so the resulting proof attests to the output commitment rather than the full order list, keeping **proof size and verification cost constant** as the number of vaults and orders grows. The offchain state machine that drives this process is **fault tolerant**. Onchain, the Liquidity Orchestrator **validates** the generated orders using the verification key, the proof, and the committed state; **only after validation** does it use the order payload to move liquidity and update vault accounting. It executes trades through modular Execution Adapters, holds a central pool of the protocol's underlying asset (netting across vaults before external markets), and maintains a liquidity buffer for slippage. When rebalancing completes, it finalizes the epoch by settling queued deposit and redemption requests in each vault where fulfillment is possible. Settlement may be **partial**: failed or unfilled requests can remain pending for a later epoch. Proof verification attests that order generation matched the committed state; it does not by itself guarantee favorable execution prices or full intent fulfillment. ## Adapters and Registries **Price Adapters** supply asset pricing data; **Execution Adapters** implement trade logic for specific asset types. Dedicated registry contracts govern which adapters the protocol may use. This modular layout allows multiple vaults to share infrastructure and batch operations across a diverse asset set. Extensibility depends on adapter quality, oracle behavior, and external market conditions. The registries permission components; they do not validate every downstream failure mode. --- # Incident Response > This is Orion's **public** incident response plan. It tells users, managers, and researchers where to look, what to do, and what we will (and will not) say while an incident is active. It is not a complete internal playbook. It does not promise recovery timing, restoration of funds, or compensation. Binding limitations are in the [Terms of Service](https://www.orionfinance.ai/terms-of-service). ## What counts as an incident An incident is any situation that may lead to a considerable loss of funds for users, the protocol, or contracts deployed by Orion. Examples include: - A bug or exploit in vault, orchestrator, adapter, or related protocol code - A bug or exploit in an underlying protocol that Orion vaults or adapters rely on - Loss or compromise of a privileged key (for example Admin, Guardian, or a vault manager/strategist key) - A credible vulnerability report that requires emergency action - An active exploit in progress Routine app bugs, wallet support issues, and strategy underperformance are not incidents. Use [Troubleshooting](/user/getting_started/troubleshooting) or community channels for those. ## Official channels During an incident, treat **only** the following as official. Ignore direct messages, unofficial Telegram/Discord accounts, and lookalike websites. | Channel | Role | | ------------------------------------------------------------------- | ------------------------------------------------------ | | **[X / Twitter](https://x.com/OrionFinanceAI)** (`@OrionFinanceAI`) | Primary public status updates | | **[Discord](https://discord.gg/8bAXxPSPdw)** | Community updates from Orion-operated accounts | | **[Telegram](https://t.me/orionfinance_ai)** | Same, from the official Orion channel | | **[LinkedIn](https://www.linkedin.com/company/orionfinance/)** | Company-level notices when used | | **App** ([app.orionfinance.ai](https://app.orionfinance.ai)) | In-app notices when we can show them safely | | **Docs** ([docs.orionfinance.ai](https://docs.orionfinance.ai)) | Standing security pages; incident notes when published | | **[security@orionfinance.ai](mailto:security@orionfinance.ai)** | Private reports and researcher contact | The official app URL is **[app.orionfinance.ai](https://app.orionfinance.ai)**. Bookmark it. Do not follow links from DMs or search ads. If official channels disagree, prefer a later post on X from `@OrionFinanceAI` and the app URL above. ## What Users and Managers Should Do 1. **Watch the official channels above.** Do not rely on screenshots or forwarded messages. 2. **Follow any interaction guidance we publish** (for example: do not deposit, do not sign unexpected transactions, wait for settlement). 3. **Do not sign transactions you do not understand.** "Support" accounts that ask you to "validate," "sync," or "claim" are not Orion. 4. **Do not discuss suspected exploits in public** if doing so could help an attacker. Email [security@orionfinance.ai](mailto:security@orionfinance.ai) instead. 5. **Verify the URL** before connecting a wallet. See [User Security](/user/security). If the protocol is paused, epoch execution (rebalancing and settlement) stops until Admin unpauses. Pending deposits or redemptions may remain pending. Pause is a protective measure. ## How we Respond The objective is to limit loss of funds, then to inform users as soon as we can do so without making the situation worse. | Phase | What you can expect | | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Assess** | We confirm the report, identify affected surfaces, and decide whether funds are at risk. Early information may be incomplete. | | **Contain** | We may pause the Liquidity Orchestrator (Guardian or Admin), restrict the app, or take other onchain steps already described in [Roles and Permissions](https://docs.orionfinance.ai/developer/security/permissions.md). We will not publish a live exploit write-up while funds remain at risk. | | **Communicate** | We post on official channels: that we are aware, whether users should stop interacting, and whether pause or similar controls are in use. First notices can be short. | | **Remediate** | We work a fix or operational path. Admin, not Guardian, unpauses. Timing is not guaranteed. | | **Disclose** | After it is safe, we publish a summary of what happened, what we did, and what changes as a result. We may withhold exploit details that would help copycats. | We may skip or compress phases when speed matters. We may also stay quiet for a short period if a public post would increase harm (for example, while a pause transaction is still being signed). ## Emergency Controls These onchain controls are already documented. - **Guardian or Admin** may call `LiquidityOrchestrator.pause()`, which stops epoch upkeep. - **Admin only** may unpause. - Guardian may also retune the emergency parameters listed in [Roles and Permissions](https://docs.orionfinance.ai/developer/security/permissions.md). Guardian cannot unpause, upgrade contracts, or move protocol admin. Onchain pause does not by itself disable every wallet interaction with every contract. Any extra app or operational restrictions will be stated on official channels. ## After an Incident When it is safe, we intend to publish a public summary: timeline at a high level, user impact as we understand it, containment steps, and follow-up work. That summary is informational. It is not an admission of liability and does not create an entitlement to compensation. To report a vulnerability, see [Security](https://docs.orionfinance.ai/developer/security/overview.md). ## Related Pages - [Security](https://docs.orionfinance.ai/developer/security/overview.md) - [Risks](https://docs.orionfinance.ai/developer/security/risks.md) - [Roles and Permissions](https://docs.orionfinance.ai/developer/security/permissions.md) - [User Security](/user/security) - [Terms of Service](https://www.orionfinance.ai/terms-of-service) --- # Security > This section describes how Orion handles security publicly: how to report issues, where audit reports live, which trust assumptions the protocol makes, and how incidents are communicated. Internal runbooks, tooling, and signer operations are not published here. :::orion[Report privately] Do not open a public GitHub issue for a suspected vulnerability. Email **[security@orionfinance.ai](mailto:security@orionfinance.ai)**. ::: ## Vulnerability Disclosure Send reports to **[security@orionfinance.ai](mailto:security@orionfinance.ai)**. Include enough for us to reproduce the issue: - A short description of the suspected vulnerability - Affected contracts, networks, or app surfaces, if known - Steps or transactions that demonstrate the issue - A way to reach you Do not exploit the issue on production deployments, and do not share a working exploit publicly before we have had a chance to respond. We aim to acknowledge reports and to coordinate any public disclosure so that users are not put at further risk. Acknowledgement, severity, and any discretionary recognition are decided case by case. This page is not a bug-bounty program and does not promise payment. For user-facing safety (official app URL, wallet hygiene), see [User Security](/user/security). ## Third-party Audits Independent audit reports for core protocol contracts are published in the protocol repository: [Security Audits](https://github.com/OrionFinanceAI/protocol/tree/main/audits). Audits reduce, but do not eliminate, smart-contract and integration risk. See [Risks](https://docs.orionfinance.ai/developer/security/risks.md). ## Security Assumptions Using Orion means accepting these conditions. They are stated here so they are explicit, not so they can be removed. - **Admin is trusted.** Protocol Admin is `OrionConfig.owner()`, held by a multi-signature Gnosis Safe. A compromised or malicious Admin can cause severe damage. See [Roles and Permissions](https://docs.orionfinance.ai/developer/security/permissions.md). - **Guardian is an emergency brake, not a recovery guarantee.** Guardian may pause the Liquidity Orchestrator and retune a small set of emergency parameters. Guardian cannot unpause. Pause does not restore lost funds. - **Users custody their own keys.** Orion does not hold wallet keys. Phishing, malware, and mistaken transactions are user-side risks. - **Integrations can fail.** Execution, pricing, and yield depend on third-party protocols and oracles. Those systems can bug, halt, or be exploited. Upgradeable contracts may be placed behind an upgrade timelock after it is set. Until then, Admin bootstraps that control. Details are in [Roles and Permissions](https://docs.orionfinance.ai/developer/security/permissions.md). ## Related Pages - [Incident Response](https://docs.orionfinance.ai/developer/security/incident-response.md) - [Risks](https://docs.orionfinance.ai/developer/security/risks.md) - [Roles and Permissions](https://docs.orionfinance.ai/developer/security/permissions.md) - [Protocol Invariants](https://docs.orionfinance.ai/developer/security/protocol-invariants.md) - [User Security](/user/security) - [Security Audits](https://github.com/OrionFinanceAI/protocol/tree/main/audits) - [Terms of Service](https://www.orionfinance.ai/terms-of-service) --- # Roles and Permissions > This page defines protocol roles, access modifiers, and which addresses may call each privileged function across the Orion Finance protocol smart contracts. --- ## Vault-Level Roles ### Manager The **Manager** is the vault's administrative owner. The manager address is set at vault creation and may update fees, access control, and the assigned strategist. ### Strategist The **Strategist** submits portfolio allocation intents. A strategist may be: - A wallet address (**active** management); or - A smart contract implementing `IOrionStrategist` (**passive** management). Intent submission sets a target allocation; fulfillment depends on epoch execution, liquidity, and adapter behavior. ### User A **User** is any address that may interact with a vault to deposit assets, redeem shares, and manage pending deposit or redemption requests. Vaults configure user access as **permissionless** or **permissioned** through three optional slots (deposit, holder, and transfer) each an independent contract (`address(0)` = permissionless on that slot). See [Vault Access Control](/manager/setup/access-controller). ## Protocol-Level Roles Each protocol role below has **exactly one** on-chain authoritative definition. ### Admin | | | | -------------------------- | ------------------------------------------------------------------------------ | | **Authoritative identity** | `OrionConfig.owner()` | | **How it is set** | Config 2-step ownership transfer (`transferOwnership()` / `acceptOwnership()`) | The admin role is held by a multi-signature Gnosis Safe. ### Guardian | | | | -------------------------- | --------------------------- | | **Authoritative identity** | `OrionConfig.guardian()` | | **How it is set** | `OrionConfig.setGuardian()` | The **Guardian** is a designated address for **emergency response** under [Terms of Service §7.4](https://www.orionfinance.ai/terms-of-service). On-chain guardian authority is limited to: - `LiquidityOrchestrator.pause()` and `LiquidityOrchestrator.updateEpochDuration()` - `OrionConfig.setMinDepositAmount()` and `OrionConfig.setMinRedeemAmount()` Guardian **cannot** unpause the protocol, change fulfill batch size, or retune other operational parameters. Pause freezes protocol interaction; it does not restore lost funds or guarantee a specific recovery timeline. ### Automation Registry | | | | -------------------------- | -------------------------------------------------- | | **Authoritative identity** | `LiquidityOrchestrator.automationRegistry()` | | **How it is set** | `LiquidityOrchestrator.updateAutomationRegistry()` | The **Automation Registry** is the address authorized to call `performUpkeep`. It is the intended off-chain automation caller that monitors `checkUpkeep()` and submits upkeep when conditions are met. ### Upgrade Timelock The **Upgrade Timelock** is set once per upgradeable contract via `setUpgradeTimelock`. Until it is set, Admin may call `setUpgradeTimelock`. After it is set, only the timelock address may replace the timelock or authorize UUPS upgrades on `OrionConfig`, `LiquidityOrchestrator`, `TransparentVaultFactory`, `EncryptedVaultFactory`, and `PriceAdapterRegistry`. Each upgradeable contract stores its own `upgradeTimelock` address; Admin still means Config.owner when bootstrapping. --- ## Permission Matrix ### Vault-Level Functions | Function | Manager | Strategist | User | | ------------------------------ | ------- | ---------- | ------- | | `updateFeeModel` | **Yes** | No | No | | `claimVaultFees` | **Yes** | No | No | | `setDepositAccessControl` | **Yes** | No | No | | `setHolderAccessControl` | **Yes** | No | No | | `setTransferAccessControl` | **Yes** | No | No | | `updateStrategist` | **Yes** | No | No | | `submitIntent` | No\* | **Yes** | No | | `requestDeposit` | No | No | **Yes** | | `requestDepositFor` | No | No | **Yes** | | `cancelDepositRequest` | No | No | **Yes** | | `requestRedeem` | No | No | **Yes** | | `cancelRedeemRequest` | No | No | **Yes** | | `claimUnderlying` | No | No | **Yes** | | `redeem` (decommissioned only) | No | No | **Yes** | > **Notes:** > > - A manager can set themselves as the strategist via `updateStrategist`, which allows them to submit intents. > - **User** means any address, subject to optional deposit/holder/transfer access-control modules. Managers and > strategists may call user functions when acting as ordinary users. > - `requestDepositFor` applies deposit/holder ACL to the **beneficiary**, not the payer. > - Synchronous `redeem` is enabled only for **decommissioned** vaults. Standard ERC-4626 `deposit` / `mint` / > `withdraw` always revert. ### Factory Functions Applies to both `TransparentVaultFactory` and `EncryptedVaultFactory`. | Function | Whitelisted Manager | Admin | Upgrade Timelock | | -------------------- | ------------------- | --------- | ---------------- | | `createVault` | **Yes** | No | No | | `setVaultBeacon` | No | **Yes** | No | | `setUpgradeTimelock` | No | **Yes**\* | **Yes**\* | > **Notes:** > > - The `createVault` caller becomes the vault manager. Whitelisting is enforced via `OrionConfig.isWhitelistedManager`. > - \*`setUpgradeTimelock`: Admin if unset; Upgrade Timelock thereafter. ### `OrionConfig` Functions | Function | Admin | Guardian | Manager | | ------------------------------ | --------- | -------- | ------- | | `setLiquidityOrchestrator` | **Yes** | No | No | | `setVaultFactory` | **Yes** | No | No | | `setEncryptedVaultFactory` | **Yes** | No | No | | `setPriceAdapterRegistry` | **Yes** | No | No | | `setProtocolRiskFreeRate` | **Yes** | No | No | | `setMinDepositAmount` | **Yes** | **Yes** | No | | `setMinRedeemAmount` | **Yes** | **Yes** | No | | `setFeeChangeCooldownDuration` | **Yes** | No | No | | `setMaxFulfillBatchSize` | **Yes** | No | No | | `setGuardian` | **Yes** | No | No | | `setHpkePublicKey` | **Yes** | No | No | | `addWhitelistedAsset` | **Yes** | No | No | | `removeWhitelistedAsset` | **Yes** | No | No | | `addWhitelistedManager` | **Yes** | No | No | | `removeWhitelistedManager` | **Yes** | No | No | | `removeOrionVault` | **Yes** | No | **Yes** | | `updateProtocolFees` | **Yes** | No | No | | `setUpgradeTimelock` | **Yes**\* | No | No | > **Notes:** > > - `addWhitelistedAsset` also registers the price adapter on `PriceAdapterRegistry` and the execution adapter on > `LiquidityOrchestrator`. > - \*`setUpgradeTimelock`: Admin if unset; Upgrade Timelock thereafter (Timelock column omitted for brevity; same > pattern as factories). > - For `removeOrionVault`, Manager means that vault's manager. ### `LiquidityOrchestrator` Functions | Function | Admin | Guardian | Automation Registry | Anyone | | ------------------------------- | --------- | -------- | ------------------- | ------- | | `pause` | **Yes** | **Yes** | No | No | | `unpause` | **Yes** | No | No | No | | `updateEpochDuration` | **Yes** | **Yes** | No | No | | `updateMinibatchSize` | **Yes** | No | No | No | | `updateExecutionMinibatchSize` | **Yes** | No | No | No | | `updateCommitmentMinibatchSize` | **Yes** | No | No | No | | `updateAutomationRegistry` | **Yes** | No | No | No | | `updateVerifier` | **Yes** | No | No | No | | `updateVKey` | **Yes** | No | No | No | | `setTargetBufferRatio` | **Yes** | No | No | No | | `setSlippageTolerance` | **Yes** | No | No | No | | `depositLiquidity` | No | No | No | **Yes** | | `withdrawLiquidity` | **Yes** | No | No | No | | `claimProtocolFees` | **Yes** | No | No | No | | `performUpkeep` | **Yes** | No | **Yes** | No | | `setUpgradeTimelock` | **Yes**\* | No | No | No | > **Notes:** > > - \*`setUpgradeTimelock`: Admin if unset; Upgrade Timelock thereafter. ### Execution Adapter Functions | Function | Contract | Admin | Liquidity Orchestrator | Anyone | | -------------- | --------------------------- | ------- | ---------------------- | ------- | | `setAssetFee` | `UniswapV3ExecutionAdapter` | **Yes** | No | No | | `buy` / `sell` | `UniswapV3ExecutionAdapter` | No | No | **Yes** | | `buy` / `sell` | `ERC4626ExecutionAdapter` | No | **Yes** | No | ### Price Adapter and Registry Functions | Function | Contract | Admin | Upgrade Timelock | | -------------------- | --------------------------- | --------- | ---------------- | | `setUpgradeTimelock` | `PriceAdapterRegistry` | **Yes**\* | **Yes**\* | | `setPool` | `UniswapV3PoolPriceAdapter` | **Yes** | No | | `configureFeed` | `ChainlinkPriceAdapter` | **Yes** | No | | `setFallbackAdapter` | `ChainlinkPriceAdapter` | **Yes** | No | > **Notes:** > > - \*`setUpgradeTimelock`: Admin if unset; Upgrade Timelock thereafter. --- ## Related Pages - [Protocol Summary](https://docs.orionfinance.ai/developer/intro.md) - [Security](https://docs.orionfinance.ai/developer/security/overview.md) - [Incident Response](https://docs.orionfinance.ai/developer/security/incident-response.md) - [Security Audits](https://github.com/OrionFinanceAI/protocol/tree/main/audits) - [Protocol Invariants](https://docs.orionfinance.ai/developer/security/protocol-invariants.md) - [Contract Standards](https://docs.orionfinance.ai/developer/contract-standards.md) - [Contract Addresses](https://docs.orionfinance.ai/developer/contract-addresses.md) --- # Protocol Invariants > This page describes the conditions Orion relies on so that vault accounting, custody balances, and epoch execution stay consistent. Those conditions are checked in two complementary ways: - **Live monitoring (watchdogs)** inspect the chain as it runs. - **Epoch prove-time checks (zkVM)** validate the proposed state transition before it is committed. Production monitoring focuses on three live checks. Separately, the orchestration path also requires prove-time checks to pass before an epoch can be committed. > **Protocol invariants** are conditions that must hold for accounting to remain internally consistent. Monitoring exists to surface exploits or unexpected behavior when they stop holding. --- ## Two enforcement layers | Layer | What it inspects | How time / phase is modeled | | --------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Live monitoring** | Current onchain state | Follows the orchestrator’s public phase | | **Prove-time (zkVM)** | The proposed epoch transition | Treats the result as a **post-epoch idle** snapshot. Mid-epoch trading is accounted for conceptually via estimated underlying and already-settled legs. | --- ## Shared vault model Checks apply to both **transparent** and **privacy-preserving (encrypted)** vaults. | Vault type | How holdings are read | | ----------- | ------------------------------------------------------------- | | Transparent | Portfolio is public onchain (token list and per-asset shares) | | Encrypted | Portfolio is stored as ciphertext | The active set for an epoch is the union of registered transparent and encrypted vaults. Live Liquidity Orchestrator (LO) Balance and Prices Consistency checks (and their prove-time counterparts) need the HPKE recipient key whenever encrypted vaults are in scope. Exchange Rate Consistency does not: it only uses public ERC-4626 views (`totalSupply`, `totalAssets`, conversion helpers), which encrypted vaults still expose. ### Key ideas | Idea | Meaning | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Liquidity Orchestrator** | Contract that holds custody of whitelisted assets during execution | | **Underlying** | The protocol’s base asset | | **Whitelisted assets** | Investment universe for the epoch | | **Active vaults** | Transparent and encrypted vaults currently registered and in scope | | **Decommissioned vaults** | Vaults leaving the protocol; they still contribute to underlying custody accounting via remaining assets and pending fees/deposits, not via a live multi-asset portfolio mark | ### Share-asset conversions (ERC-4626) Vaults convert between shares and assets with virtual offsets so rounding stays well-behaved: - Virtual supply and assets add a small offset to supply and `+ 1` to assets. - Conversions use floor division in both directions. - A full-supply round-trip (`shares → assets → shares`) may lose a bounded number of shares; that bound is the maximum deficit allowed by the double floor. ### Pricing Asset prices come from protocol price adapters. A position’s mark is price × shares, scaled by adapter precision and converted into underlying decimals. A vault’s portfolio mark is the sum of those position marks. --- ## Summary ### Live monitoring | Invariant | Scope | | ----------------------------------------------------------------------------------------- | ------------------------------------------ | | [Exchange Rate Consistency](#exchange-rate-consistency) | All active vaults | | [Liquidity Orchestrator Balance Consistency](#liquidity-orchestrator-balance-consistency) | Whitelisted assets; portfolios over vaults | | [Prices Consistency](#prices-consistency) | All active vaults | --- ## Exchange Rate Consistency Ensures each vault’s share price arithmetic stays within ERC-4626 floor-rounding bounds: converting the entire supply to assets and back must not invent shares or lose more shares than the theoretical maximum from double flooring. ### Condition For every active vault with positive share supply: - Convert full supply to assets, then those assets back to shares. - The share deficit must be non-negative and at most the ERC-4626 bound derived from virtual supply and assets. - Converted shares must never exceed the original supply (no inflation under floor math). **If the bound is exceeded:** accounting or `totalAssets` is inconsistent with a correct vault. **If shares increase:** impossible under floor rounding; usually inflated assets. ### Live enforcement Runs across all active vaults registered in protocol config. ### Prove-time counterpart Same inequality, evaluated on the **post-epoch** reconstructed supply (after processing redemptions then deposits) and the emit’s final total assets. The decimals offset follows the underlying’s decimals rather than a hardcoded constant. Applies to every emitted vault with nonzero reconstructed supply. --- ## Liquidity Orchestrator Balance Consistency Ensures the orchestrator’s actual token balances match what protocol accounting says should be held: active vault portfolios (including opened encrypted holdings), decommissioned remaining assets, free buffer, protocol and vault fees still owed, and pending deposits. ### Non-underlying assets For every whitelisted asset other than the underlying, the orchestrator’s balance must **exactly** equal the sum of that asset across all active vault portfolios. ### Underlying Accounting sums: - Underlying held in active vault portfolios - Remaining assets on decommissioned vaults - Current free buffer - Pending protocol fees - Pending vault fees (active and decommissioned) - Pending deposits (active and decommissioned) --- ## Prices Consistency While the orchestrator is idle, each vault’s reported total assets must equal the mark of its portfolio under current protocol prices. **Live scope:** all active vaults. Encrypted vaults contribute opened holdings; prices and total assets remain public. ### Condition For each active vault: mark every holding with epoch prices and decimal conversion into underlying; the sum must equal `totalAssets`. --- ## Related Pages - [Diagrams](https://docs.orionfinance.ai/developer/diagrams.md) - [Security](https://docs.orionfinance.ai/developer/security/overview.md) - [Incident Response](https://docs.orionfinance.ai/developer/security/incident-response.md) - [Security Audits](https://github.com/OrionFinanceAI/protocol/tree/main/audits) - [Roles and Permissions](https://docs.orionfinance.ai/developer/security/permissions.md) - [Privacy & Confidential Execution](/manager/advanced/privacy-and-confidential-execution) --- # Risks > **Security Contact**: For security-related matters, please contact **security@orionfinance.ai**. See [Security](https://docs.orionfinance.ai/developer/security/overview.md) and [Incident Response](https://docs.orionfinance.ai/developer/security/incident-response.md). :::orion[Important] The Orion Finance Protocol and its vaults are offered as-is. By using Orion Finance, you assume all associated risks. Always conduct your own research and only invest what you can afford to lose. For complete terms and conditions, please refer to the [Terms of Service](https://www.orionfinance.ai/terms-of-service). ::: This page catalogs risks associated with the Orion Finance Protocol: smart contract defects, execution and orchestration behavior, third-party dependencies, oracle and data feeds, governance actions, and user-side security. Each category states the failure mode and the mitigations the protocol applies. Mitigations are **best-effort controls**, not guarantees, unless onchain logic explicitly requires an outcome. See the [Terms of Service](https://www.orionfinance.ai/terms-of-service) for binding limitations. Independent audit reports live in the public protocol repository: [Security Audits](https://github.com/OrionFinanceAI/protocol/tree/main/audits). --- ## Smart Contract Risks Smart contracts may contain bugs, vulnerabilities, or unexpected behaviors that could result in loss of funds. Testing and audits reduce but do not eliminate that exposure. Mitigations in place: - Core smart contracts undergo independent [security audits](https://github.com/OrionFinanceAI/protocol/tree/main/audits) prior to deployment. - [Protocol invariants](https://docs.orionfinance.ai/developer/security/protocol-invariants.md) are monitored in the production environment. - Upgrade and deployment procedures follow conservative review steps. - Emergency pause mechanisms exist (see [Governance Risks](#governance-risks)). ## Execution and Orchestration Risks | Risk | Description | Mitigation / Controls | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Latency** | Transactions are not instant. There is a delay between submitting an intent and its execution. | Managers and users are informed about the asynchronous nature of execution. Deterministic epoch-based batching provides **predictable, not guaranteed**, execution windows. Future protocol upgrades may support optional synchronous execution. | | **Slippage** | Prices for order generation are measured seconds before order execution within [asynchronous epoch batching](/user/how-it-works), introducing the risk of inconsistent accounting between planning and settlement. | Atomic slippage limits are enforced per asset where configured. A protocol-controlled [buffer reserve](/manager/execution/slippage-and-buffer) provides **best-effort** absorption of planning-vs-execution variance. Batching and netting **may** reduce market impact but do not eliminate slippage risk. | | **Failing Orders** | If an order fails to execute via the Liquidity Orchestrator (e.g., due to low liquidity or revert errors), rebalancing may proceed without full intent fulfillment. Deposits, redemptions, or settlements may remain pending longer. | **Best-effort** [sequential failure recalibration](/manager/execution/from-intent-to-trades#sequential-failure-recalibration) may bypass problematic assets, finalize the epoch, and retry later. This is **not** a guarantee of redemption timing or full intent execution. | ## Third-Party Protocol Risks The Orion Finance Protocol interacts with or relies on third-party decentralized protocols to execute trades or generate yield. Orion Finance does not own, control, or operate these third-party protocols. | Risk | Description | Mitigation / Controls | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Third-Party Protocol Risks** | Integrations with third-party protocols make the system directly impacted by bugs and exploits in those protocols. | The Orion investment universe is permissioned: due diligence is performed before adding assets. This vetting is **best-effort** and does not eliminate third-party failure risk. | | **Liquidity Risk** | Lack of liquidity on external DEXs or lending protocols can prevent execution or cause significant slippage. | Vetting is performed to monitor liquidity and market depth of investment universe assets. The same **best-effort** mitigations discussed in [Execution and Orchestration Risks](#execution-and-orchestration-risks) apply; execution is not guaranteed. | ## Oracle and Data Risks The Internal State Orchestrator relies on price feeds ("Oracles") to calculate Net Asset Value (NAV) and facilitate accounting. Oracle failures, manipulation, or incorrect data can lead to incorrect NAV calculations, improper rebalancing, or accounting errors. | Risk | Description | Mitigation / Controls | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Oracle Failure** | Price feeds may become stale, unavailable, or provide incorrect data, leading to inaccurate NAV calculations and potential accounting errors. | Oracle health is monitored on a **best-effort** basis. TWAPs, staleness checks, circuit breakers, and price deviation checks **may** reduce risk but do not guarantee correct pricing at all times. | ## Governance Risks | Risk | Description | Mitigation / Controls | | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Emergency Powers** | The **Guardian** may invoke `LiquidityOrchestrator.pause()` to temporarily freeze deposits, redemptions, and vault interactions in anomalous states. Per the [OrionConfig permission matrix](https://docs.orionfinance.ai/developer/security/permissions.md#orionconfig-functions), Guardian may also call `setMinDepositAmount`, `setMinRedeemAmount`, and `setMaxFulfillBatchSize`. The **Admin** retains broader protocol controls, including pause and unpause. Neither role guarantees recovery timing or compensation for pause-related disruption. | Guardian authority under policy is intended for **emergency response**, not discretionary operational tuning. Emergency actions are intended for broken invariants and anomalous states and are communicated publicly when exercised. Pause is a **best-effort** protective measure, not insurance against loss. | | **Automation Dependencies** | The Protocol relies on off-chain keepers (via the Automation Registry) to trigger rebalancing and related upkeep. If automation fails or is delayed, vaults may remain pending or fail to rebalance for an indeterminate period. | Third parties or operators **may** attempt upkeep; the Protocol does **not** guarantee timing or continuity. Redundant keeper infrastructure and monitoring are maintained on a **best-effort** basis. Any operational fallback is **discretionary** and **not** a user entitlement or assured service. Manual intervention, if any, is disclosed as operational risk, not guaranteed remediation. | | **Governance Changes** | Protocol governance may change parameters, fees, or functionality in ways that affect open positions. | Timelock mechanisms **may** provide advance notice where configured; community input is solicited for significant changes. Parameter changes are **not** guaranteed to benefit any particular position. | ## User Error and Security Risks | Risk | Description | Mitigation / Controls | | ----------------------- | -------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | **User Error** | Forgotten passwords, incorrectly constructed transactions, or mistyped addresses. | User interfaces provide warnings and confirmations where available. These features are **best-effort** and do not prevent all user error. | | **Unauthorized Access** | Unauthorized access to Wallets or devices, including through the use of viruses, phishing, or other means of attack. | Security best practices documentation and phishing awareness. Users remain responsible for wallet and device security; the Protocol does not custody keys. | --- ## Related Pages - [Security](https://docs.orionfinance.ai/developer/security/overview.md) - [Incident Response](https://docs.orionfinance.ai/developer/security/incident-response.md) - [Security Audits](https://github.com/OrionFinanceAI/protocol/tree/main/audits) - [Roles and Permissions](https://docs.orionfinance.ai/developer/security/permissions.md) - [Protocol Invariants](https://docs.orionfinance.ai/developer/security/protocol-invariants.md) - [Slippage and Buffer](/manager/execution/slippage-and-buffer) - [Terms of Service](https://www.orionfinance.ai/terms-of-service) --- # LiquidityOrchestrator > Contract that orchestrates liquidity operations _This contract is responsible for: - Executing actual buy and sell orders on investment universe; - Processing withdrawal requests from LPs; - Handling slippage and market execution differences from adapter price estimates via liquidity buffer._ ### BASIS_POINTS_FACTOR ```solidity uint16 BASIS_POINTS_FACTOR ``` Basis points factor ### automationRegistry ```solidity address automationRegistry ``` Chainlink Automation Registry address ### config ```solidity contract IOrionConfig config ``` Orion Config contract address ### underlyingAsset ```solidity address underlyingAsset ``` Underlying asset address ### verifier ```solidity contract ISP1Verifier verifier ``` The address of the SP1 verifier contract. ### vKey ```solidity bytes32 vKey ``` The verification key for the Orion Internal State Orchestrator. ### priceAdapterRegistry ```solidity contract IPriceAdapterRegistry priceAdapterRegistry ``` Price Adapter Registry contract ### executionAdapterOf ```solidity mapping(address => contract IExecutionAdapter) executionAdapterOf ``` Execution adapters mapping for assets ### epochDuration ```solidity uint32 epochDuration ``` Epoch duration ### executionMinibatchSize ```solidity uint8 executionMinibatchSize ``` Execution minibatch size ### minibatchSize ```solidity uint8 minibatchSize ``` Minibatch size for fulfill deposit and redeem processing ### currentPhase ```solidity enum ILiquidityOrchestrator.LiquidityUpkeepPhase currentPhase ``` Upkeep phase ### currentMinibatchIndex ```solidity uint8 currentMinibatchIndex ``` Current minibatch index ### targetBufferRatio ```solidity uint256 targetBufferRatio ``` Target buffer ratio ### slippageTolerance ```solidity uint256 slippageTolerance ``` Slippage tolerance ### epochCounter ```solidity uint256 epochCounter ``` Epoch counter ### bufferAmount ```solidity uint256 bufferAmount ``` Live buffer amount [assets] ### pendingProtocolFees ```solidity uint256 pendingProtocolFees ``` Pending protocol fees [assets] ### _failedEpochTokens ```solidity address[] _failedEpochTokens ``` Tokens that failed during the current epoch's sell/buy execution (cleared at epoch end) ### initialEpochBufferAmount ```solidity uint256 initialEpochBufferAmount ``` Buffer snapshot captured at epoch start and used as deterministic proof input anchor [assets] ### _epochDeltaAmount ```solidity int256 _epochDeltaAmount ``` Epoch delta amount to apply when transitioning to ProcessVaultOperations. ### EpochState Struct to hold epoch state data ```solidity struct EpochState { address[] vaultsEpoch; mapping(address => uint256) pricesEpoch; uint16 activeNettingFeeCoefficient; uint16 activeRsFeeCoefficient; mapping(address => struct IOrionVault.FeeModel) feeModel; bytes32 epochStateCommitment; } ``` ### _currentEpoch ```solidity struct LiquidityOrchestrator.EpochState _currentEpoch ``` Current epoch state ### upgradeTimelock ```solidity address upgradeTimelock ``` Address of the upgrade timelock that must authorise all implementation upgrades ### commitmentMinibatchSize ```solidity uint8 commitmentMinibatchSize ``` Number of vault leaves folded into the commitment per StateCommitment upkeep step ### _commitmentBatchIndex ```solidity uint16 _commitmentBatchIndex ``` Number of vault leaves already folded this epoch ### completedInCurrentMinibatch ```solidity uint16 completedInCurrentMinibatch ``` On-chain resume cursor for the active sell/buy minibatch window. ### onlyAuthorizedTrigger ```solidity modifier onlyAuthorizedTrigger() ``` _Restricts function to only owner or automation registry_ ### onlyConfig ```solidity modifier onlyConfig() ``` _Restricts function to only Orion Config contract_ ### onlyOwnerOrGuardian ```solidity modifier onlyOwnerOrGuardian() ``` _Restricts function to only owner or guardian_ ### onlySelf ```solidity modifier onlySelf() ``` _Restricts function to only self Used on _executeSell and _executeBuy so they can stay external (required for try/catch)_ ### constructor ```solidity constructor() public ``` Constructor that disables initializers for the implementation contract ### initialize ```solidity function initialize(address initialOwner, address config_, address automationRegistry_, address verifier_, bytes32 vKey_) public ``` Initializes the contract #### Parameters | Name | Type | Description | | ------------------- | ------- | -------------------------------------------------------------- | | initialOwner | address | The address of the initial owner | | config_ | address | The address of the OrionConfig contract | | automationRegistry_ | address | The address of the Chainlink Automation Registry | | verifier_ | address | The address of the SP1 verifier contract | | vKey_ | bytes32 | The verification key for the Orion Internal State Orchestrator | ### updateEpochDuration ```solidity function updateEpochDuration(uint32 newEpochDuration) external ``` Updates the epoch duration #### Parameters | Name | Type | Description | | ---------------- | ------ | --------------------------------- | | newEpochDuration | uint32 | The new epoch duration in seconds | ### updateExecutionMinibatchSize ```solidity function updateExecutionMinibatchSize(uint8 _executionMinibatchSize) external ``` Updates the execution minibatch size #### Parameters | Name | Type | Description | | ----------------------- | ----- | -------------------------------- | | _executionMinibatchSize | uint8 | The new execution minibatch size | ### updateMinibatchSize ```solidity function updateMinibatchSize(uint8 _minibatchSize) external ``` Updates the minibatch size for fulfill deposit and redeem processing #### Parameters | Name | Type | Description | | -------------- | ----- | ---------------------- | | _minibatchSize | uint8 | The new minibatch size | ### updateCommitmentMinibatchSize ```solidity function updateCommitmentMinibatchSize(uint8 _commitmentMinibatchSize) external ``` Updates the number of vault leaves folded per StateCommitment upkeep step. #### Parameters | Name | Type | Description | | ------------------------ | ----- | --------------------------------- | | _commitmentMinibatchSize | uint8 | The new commitment minibatch size | ### updateAutomationRegistry ```solidity function updateAutomationRegistry(address newAutomationRegistry) external ``` Updates the Chainlink Automation Registry address #### Parameters | Name | Type | Description | | --------------------- | ------- | ----------------------------------- | | newAutomationRegistry | address | The new automation registry address | ### updateVerifier ```solidity function updateVerifier(address newVerifier) external ``` Updates the verifier contract address _Callable mid-epoch for maintenance. The owner must coordinate with the zk-orchestrator so proofs submitted after this change are verified by the new contract._ #### Parameters | Name | Type | Description | | ----------- | ------- | ---------------------------------------- | | newVerifier | address | The address of the new verifier contract | ### updateVKey ```solidity function updateVKey(bytes32 newvKey) external ``` Updates the internal state orchestrator verification key _Callable mid-epoch for maintenance. Reverts with InvalidArguments if newvKey is bytes32(0). The owner must coordinate with the zk-orchestrator so proofs submitted after this change match the new verification key and current epoch commitments._ #### Parameters | Name | Type | Description | | ------- | ------- | ------------------------ | | newvKey | bytes32 | The new verification key | ### setTargetBufferRatio ```solidity function setTargetBufferRatio(uint256 _targetBufferRatio) external ``` Sets the target buffer ratio #### Parameters | Name | Type | Description | | ------------------ | ------- | --------------------------- | | _targetBufferRatio | uint256 | The new target buffer ratio | ### setSlippageTolerance ```solidity function setSlippageTolerance(uint256 _slippageTolerance) external ``` Sets the slippage tolerance #### Parameters | Name | Type | Description | | ------------------ | ------- | -------------------------- | | _slippageTolerance | uint256 | The new slippage tolerance | ### depositLiquidity ```solidity function depositLiquidity(uint256 amount) external ``` Deposits underlying assets to the liquidity orchestrator buffer _Increases the buffer amount by the deposited amount._ #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------------------ | | amount | uint256 | The amount of underlying assets to deposit | ### withdrawLiquidity ```solidity function withdrawLiquidity(uint256 amount) external ``` Withdraws underlying assets from the liquidity orchestrator buffer _Can only be called by the owner. Decreases the buffer amount by the withdrawn amount. Includes safety checks to prevent predatory withdrawals that could break protocol operations._ #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------------------- | | amount | uint256 | The amount of underlying assets to withdraw | ### claimProtocolFees ```solidity function claimProtocolFees(uint256 amount) external ``` Claim protocol fees with specified amount _Called by the Owner to claim a specific amount of protocol fees_ #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------------ | | amount | uint256 | The amount of protocol fees to claim | ### getEpochState ```solidity function getEpochState() external view returns (struct ILiquidityOrchestrator.EpochStateView) ``` Returns the full epoch state _Returns all epoch state data in a single struct. Use this instead of individual getters._ #### Return Values | Name | Type | Description | | ---- | -------------------------------------------- | ----------------------------- | | [0] | struct ILiquidityOrchestrator.EpochStateView | The complete epoch state view | ### getFailedEpochTokens ```solidity function getFailedEpochTokens() external view returns (address[]) ``` Returns tokens that failed during the current epoch's sell/buy execution #### Return Values | Name | Type | Description | | ---- | --------- | ----------------------------------- | | [0] | address[] | List of token addresses that failed | ### setExecutionAdapter ```solidity function setExecutionAdapter(address asset, contract IExecutionAdapter adapter) external ``` Register or replace the execution adapter for an asset. _Can only be called by the Orion Config contract._ #### Parameters | Name | Type | Description | | ------- | -------------------------- | ------------------------------------ | | asset | address | The address of the asset. | | adapter | contract IExecutionAdapter | The execution adapter for the asset. | ### pause ```solidity function pause() external ``` Pauses protocol operations for the orchestrator _Can only be called by guardian or owner for emergency situations_ ### unpause ```solidity function unpause() external ``` Unpauses protocol operations for the orchestrator _Can only be called by owner after resolving emergency (not guardian: requires owner approval to resume)_ ### returnDepositFunds ```solidity function returnDepositFunds(address user, uint256 amount) external ``` Return deposit funds to a user who cancelled their deposit request _Called by vault contracts when users cancel deposit requests_ #### Parameters | Name | Type | Description | | ------ | ------- | --------------------------- | | user | address | The user to return funds to | | amount | uint256 | The amount to return | ### transferVaultFees ```solidity function transferVaultFees(uint256 amount) external ``` Transfer pending fees to manager _Called by vault contracts when managers claim their fees_ #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------ | | amount | uint256 | The amount of fees to transfer | ### transferRedemptionFunds ```solidity function transferRedemptionFunds(address user, uint256 amount) external ``` Transfer redemption funds to a user after shares are burned _Called by vault contracts when processing redemption requests_ #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------------------- | | user | address | The user to transfer funds to | | amount | uint256 | The amount of underlying assets to transfer | ### withdraw ```solidity function withdraw(uint256 assets, address receiver) external ``` Synchronous redemption for decommissioned vaults _Called by vault contracts to process synchronous redemptions for LPs with share tokens_ #### Parameters | Name | Type | Description | | -------- | ------- | -------------------------------------------- | | assets | uint256 | The amount of underlying assets to withdraw | | receiver | address | The address to receive the underlying assets | ### checkUpkeep ```solidity function checkUpkeep() external view returns (bool upkeepNeeded) ``` Checks if upkeep is needed _the API is inspired but different from the Chainlink Automation interface._ #### Return Values | Name | Type | Description | | ------------ | ---- | ------------------------ | | upkeepNeeded | bool | Whether upkeep is needed | ### performUpkeep ```solidity function performUpkeep(bytes _publicValues, bytes proofBytes, bytes statesBytes) external ``` Performs the upkeep _the API is inspired but different from the Chainlink Automation interface._ #### Parameters | Name | Type | Description | | ------------- | ----- | ------------------------------------------------------------------ | | _publicValues | bytes | Encoded PublicValuesStruct containing input and output commitments | | proofBytes | bytes | The zk-proof bytes | | statesBytes | bytes | Encoded StatesStruct containing state transition payload. | ### _shouldTriggerUpkeep ```solidity function _shouldTriggerUpkeep() internal view returns (bool) ``` Checks if upkeep should be triggered based on time #### Return Values | Name | Type | Description | | ---- | ---- | ---------------------------------- | | [0] | bool | True if upkeep should be triggered | ### _handleStart ```solidity function _handleStart() internal ``` Handles the start of the upkeep _No need to delete prices as they are either overwritten or associated with non-whitelisted assets._ ### _buildVaultsEpoch ```solidity function _buildVaultsEpoch() internal ``` Build vaults list for the epoch ### _processCommitmentMinibatch ```solidity function _processCommitmentMinibatch() internal ``` Folds the next batch of vault leaves into the running accumulator. ### _buildProtocolStateHash ```solidity function _buildProtocolStateHash() internal returns (bytes32 protocolStateHash) ``` Builds the protocol state hash from static epoch parameters. #### Return Values | Name | Type | Description | | ----------------- | ------- | ----------------------- | | protocolStateHash | bytes32 | The protocol state hash | ### _aggregateAssetLeaves ```solidity function _aggregateAssetLeaves(address[] assets, uint256[] assetPrices) internal pure returns (bytes32) ``` Aggregates asset leaves using sequential folding #### Parameters | Name | Type | Description | | ----------- | --------- | ------------------------ | | assets | address[] | Array of asset addresses | | assetPrices | uint256[] | Array of asset prices | #### Return Values | Name | Type | Description | | ---- | ------- | -------------------------- | | [0] | bytes32 | The aggregated assets hash | ### getAssetPrices ```solidity function getAssetPrices(address[] assets) public view returns (uint256[] assetPrices) ``` Gets asset prices for the epoch #### Parameters | Name | Type | Description | | ------ | --------- | ------------------------ | | assets | address[] | Array of asset addresses | #### Return Values | Name | Type | Description | | ----------- | --------- | --------------------- | | assetPrices | uint256[] | Array of asset prices | ### _verifyPerformData ```solidity function _verifyPerformData(bytes _publicValues, bytes proofBytes, bytes statesBytes) internal view returns (struct ILiquidityOrchestrator.StatesStruct states) ``` Verifies the perform data #### Parameters | Name | Type | Description | | ------------- | ----- | ------------------------------------------------------------------ | | _publicValues | bytes | Encoded PublicValuesStruct containing input and output commitments | | proofBytes | bytes | The zk-proof bytes | | statesBytes | bytes | Encoded StatesStruct containing state transition payload. | #### Return Values | Name | Type | Description | | ------ | ------------------------------------------ | ------------------------ | | states | struct ILiquidityOrchestrator.StatesStruct | The decoded StatesStruct | ### _processMinibatchSell ```solidity function _processMinibatchSell(struct ILiquidityOrchestrator.SellLegOrders sellLeg) internal ``` Handles the sell action #### Parameters | Name | Type | Description | | ------- | ------------------------------------------- | ------------------- | | sellLeg | struct ILiquidityOrchestrator.SellLegOrders | The sell leg orders | ### _processMinibatchBuy ```solidity function _processMinibatchBuy(struct ILiquidityOrchestrator.BuyLegOrders buyLeg) internal ``` Handles the buy action #### Parameters | Name | Type | Description | | ------ | ------------------------------------------ | ------------------ | | buyLeg | struct ILiquidityOrchestrator.BuyLegOrders | The buy leg orders | ### _processMinibatchLeg ```solidity function _processMinibatchLeg(address[] tokens, uint256[] amounts, uint256[] estimatedUnderlyingAmounts, bool isSell) internal ``` Processes the next sell or buy minibatch window with resume support #### Parameters | Name | Type | Description | | -------------------------- | --------- | ------------------------------------ | | tokens | address[] | Leg token addresses | | amounts | uint256[] | Leg share amounts | | estimatedUnderlyingAmounts | uint256[] | Leg underlying estimates | | isSell | bool | True for sell leg, false for buy leg | ### _handleMinibatchLegFailure ```solidity function _handleMinibatchLegFailure(address token) internal ``` Records a failed minibatch leg and refreshes the epoch commitment without advancing the minibatch index #### Parameters | Name | Type | Description | | ----- | ------- | ----------------------------------------------------------- | | token | address | The address of the token for which the minibatch leg failed | ### _finalizeMinibatchLeg ```solidity function _finalizeMinibatchLeg(bool isSell, bool legFinished) internal ``` Applies phase transitions after a minibatch window completes successfully #### Parameters | Name | Type | Description | | ----------- | ---- | ---------------------------------------------- | | isSell | bool | Whether this was the sell leg of the operation | | legFinished | bool | Whether the minibatch leg has completed | ### _applyBuyLegSettlement ```solidity function _applyBuyLegSettlement(uint256 bufferIncrease, uint256 epochProtocolFees) internal ``` Applies bufferIncrease, accrued exec dust, and epoch protocol fees at Buy→PVO. #### Parameters | Name | Type | Description | | ----------------- | ------- | ------------------------------------------------------- | | bufferIncrease | uint256 | Nominal buffer increase from the completing buy payload | | epochProtocolFees | uint256 | Epoch protocol fees from the completing buy payload | ### _updateBufferAmount ```solidity function _updateBufferAmount(int256 deltaAmount) internal ``` Updates the buffer amount based on execution vs estimated amounts #### Parameters | Name | Type | Description | | ----------- | ------ | ------------------------------------------------------------ | | deltaAmount | int256 | The amount to add/subtract from the buffer (can be negative) | ### _calculateMaxWithSlippage ```solidity function _calculateMaxWithSlippage(uint256 estimatedAmount) internal view returns (uint256) ``` Calculate maximum amount with slippage applied #### Parameters | Name | Type | Description | | --------------- | ------- | -------------------- | | estimatedAmount | uint256 | The estimated amount | #### Return Values | Name | Type | Description | | ---- | ------- | ---------------------------------------- | | [0] | uint256 | The maximum amount with slippage applied | ### _calculateMinWithSlippage ```solidity function _calculateMinWithSlippage(uint256 estimatedAmount) internal view returns (uint256) ``` Calculate minimum amount with slippage applied #### Parameters | Name | Type | Description | | --------------- | ------- | -------------------- | | estimatedAmount | uint256 | The estimated amount | #### Return Values | Name | Type | Description | | ---- | ------- | ---------------------------------------- | | [0] | uint256 | The minimum amount with slippage applied | ### _executeSell ```solidity function _executeSell(address asset, uint256 sharesAmount, uint256 estimatedUnderlyingAmount) external ``` Executes a sell order #### Parameters | Name | Type | Description | | ------------------------- | ------- | ------------------------------------------ | | asset | address | The asset to sell | | sharesAmount | uint256 | The amount of shares to sell | | estimatedUnderlyingAmount | uint256 | The estimated underlying amount to receive | ### _executeBuy ```solidity function _executeBuy(address asset, uint256 sharesAmount, uint256 estimatedUnderlyingAmount) external ``` Executes a buy order #### Parameters | Name | Type | Description | | ------------------------- | ------- | ---------------------------------------- | | asset | address | The asset to buy | | sharesAmount | uint256 | The amount of shares to buy | | estimatedUnderlyingAmount | uint256 | The estimated underlying amount to spend | ### _processMinibatchVaultsOperations ```solidity function _processMinibatchVaultsOperations(struct ILiquidityOrchestrator.VaultState[] vaultStates) internal ``` Handles the vault operations _vaultStates[] shall match _currentEpoch.vaultsEpoch[] in order_ #### Parameters | Name | Type | Description | | ----------- | ------------------------------------------ | ---------------- | | vaultStates | struct ILiquidityOrchestrator.VaultState[] | The vault states | ### _processSingleVaultOperations ```solidity function _processSingleVaultOperations(address vaultAddress, struct ILiquidityOrchestrator.VaultState vaultState) internal ``` Processes deposit and redeem operations for a single vault #### Parameters | Name | Type | Description | | ------------ | ---------------------------------------- | -------------------------------------------------------------------------------- | | vaultAddress | address | The vault address | | vaultState | struct ILiquidityOrchestrator.VaultState | Epoch output state for this vault (plaintext portfolio and/or sealed ciphertext) | ### setUpgradeTimelock ```solidity function setUpgradeTimelock(address newTimelock) external ``` Sets the upgrade timelock address. _If no timelock is set yet, only the owner may call this. Once a timelock is active, only the timelock itself may replace it, preventing the owner from bypassing the delay._ #### Parameters | Name | Type | Description | | ----------- | ------- | ----------------------------------------------------------------------------------------- | | newTimelock | address | The new timelock address (e.g. OpenZeppelin TimelockController); address(0) not permitted | ### _authorizeUpgrade ```solidity function _authorizeUpgrade(address) internal view ``` Authorizes an upgrade to a new implementation _Requires the caller to be the upgrade timelock (if set) or the owner (during initial bootstrapping before a timelock has been configured)._ --- # OrionConfig > Configuration contract for Orion protocol using UUPS upgradeable pattern ### guardian ```solidity address guardian ``` Guardian address for emergency pausing ### underlyingAsset ```solidity contract IERC20 underlyingAsset ``` Underlying asset address ### liquidityOrchestrator ```solidity address liquidityOrchestrator ``` Address of the liquidity orchestrator ### transparentVaultFactory ```solidity address transparentVaultFactory ``` Address of the transparent vault factory ### priceAdapterRegistry ```solidity address priceAdapterRegistry ``` Address of the price adapter registry ### strategistIntentDecimals ```solidity uint8 strategistIntentDecimals ``` Decimals for strategist intent ### priceAdapterDecimals ```solidity uint8 priceAdapterDecimals ``` Decimals for price adapter ### riskFreeRate ```solidity uint16 riskFreeRate ``` Risk-free rate in basis points. Same decimals as BASIS_POINTS_FACTOR ### minDepositAmount ```solidity uint256 minDepositAmount ``` Minimum deposit amount in underlying asset units ### minRedeemAmount ```solidity uint256 minRedeemAmount ``` Minimum redeem amount in share units ### feeChangeCooldownDuration ```solidity uint256 feeChangeCooldownDuration ``` Fee change cooldown duration in seconds (7 days default) ### maxFulfillBatchSize ```solidity uint256 maxFulfillBatchSize ``` Maximum number of requests to process per fulfill calls ### tokenDecimals ```solidity mapping(address => uint8) tokenDecimals ``` Mapping of token address to its decimals ### nettingFeeCoefficient ```solidity uint16 nettingFeeCoefficient ``` Netting fee coefficient (bps of netted rebalance volume) ### rsFeeCoefficient ```solidity uint16 rsFeeCoefficient ``` Revenue share fee coefficient ### newProtocolFeeRatesTimestamp ```solidity uint256 newProtocolFeeRatesTimestamp ``` Timestamp when new protocol fee rates become effective ### upgradeTimelock ```solidity address upgradeTimelock ``` Address of the upgrade timelock that must authorise all implementation upgrades ### hpkePublicKey ```solidity bytes32 hpkePublicKey ``` HPKE recipient public key ### encryptedVaultFactory ```solidity address encryptedVaultFactory ``` Address of the encrypted vault factory ### onlyFactories ```solidity modifier onlyFactories() ``` ### onlyLiquidityOrchestrator ```solidity modifier onlyLiquidityOrchestrator() ``` ### constructor ```solidity constructor() public ``` Constructor that disables initializers for the implementation contract ### initialize ```solidity function initialize(address initialOwner, address underlyingAsset_) public ``` Initializer function (replaces constructor) _The underlying asset is automatically added to the investment universe whitelist because: - Strategists may decide to be underleveraged in their active positions; - removeWhitelistedAsset could trigger forced liquidations._ #### Parameters | Name | Type | Description | | ---------------- | ------- | -------------------------------------------- | | initialOwner | address | The address that will own this contract | | underlyingAsset_ | address | The address of the underlying asset contract | ### updateProtocolFees ```solidity function updateProtocolFees(uint16 _nettingFeeCoefficient, uint16 _rsFeeCoefficient) external ``` Updates the protocol fees _If called while a previous fee change is still in cooldown, the prior scheduled change is cancelled: activeProtocolFees() returns the current (old) rates, which are stored as old coefficients, then the new coefficients overwrite the prior schedule. The previously scheduled intermediate fees never take effect._ #### Parameters | Name | Type | Description | | ---------------------- | ------ | ---------------------------------------------------------------- | | _nettingFeeCoefficient | uint16 | The new netting fee coefficient (bps of netted rebalance volume) | | _rsFeeCoefficient | uint16 | The new revenue share fee coefficient | ### activeProtocolFees ```solidity function activeProtocolFees() public view returns (uint16 nettingFee, uint16 rsFee) ``` Returns the active protocol fees (old during cooldown, new after) #### Return Values | Name | Type | Description | | ---------- | ------ | ---------------------------------------- | | nettingFee | uint16 | The active netting fee coefficient | | rsFee | uint16 | The active revenue share fee coefficient | ### setLiquidityOrchestrator ```solidity function setLiquidityOrchestrator(address orchestrator) external ``` Sets the liquidity orchestrator for the protocol _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | ------------ | ------- | ----------------------------------------- | | orchestrator | address | The address of the liquidity orchestrator | ### setVaultFactory ```solidity function setVaultFactory(address transparentFactory) external ``` Sets the vault factory for the protocol _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | ------------------ | ------- | -------------------------------------------- | | transparentFactory | address | The address of the transparent vault factory | ### setEncryptedVaultFactory ```solidity function setEncryptedVaultFactory(address encryptedFactory) external ``` Sets the encrypted vault factory for the protocol _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | ---------------- | ------- | ------------------------------------------ | | encryptedFactory | address | The address of the encrypted vault factory | ### setPriceAdapterRegistry ```solidity function setPriceAdapterRegistry(address registry) external ``` Sets the price adapter registry for the protocol _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | -------- | ------- | ----------------------------------------- | | registry | address | The address of the price adapter registry | ### setProtocolRiskFreeRate ```solidity function setProtocolRiskFreeRate(uint16 _riskFreeRate) external ``` Sets the protocol risk-free rate _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | ------------- | ------ | ----------- | | _riskFreeRate | uint16 | | ### setMinDepositAmount ```solidity function setMinDepositAmount(uint256 amount) external ``` Sets the minimum deposit amount _Can be called by the contract owner or guardian_ #### Parameters | Name | Type | Description | | ------ | ------- | -------------------------------------------------------- | | amount | uint256 | The new minimum deposit amount in underlying asset units | ### setMinRedeemAmount ```solidity function setMinRedeemAmount(uint256 amount) external ``` Sets the minimum redeem amount _Can be called by the contract owner or guardian_ #### Parameters | Name | Type | Description | | ------ | ------- | -------------------------------------------- | | amount | uint256 | The new minimum redeem amount in share units | ### setFeeChangeCooldownDuration ```solidity function setFeeChangeCooldownDuration(uint256 duration) external ``` Sets the fee change cooldown duration _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | -------- | ------- | ------------------------------------ | | duration | uint256 | The new cooldown duration in seconds | ### setMaxFulfillBatchSize ```solidity function setMaxFulfillBatchSize(uint256 size) external ``` Sets the maximum fulfill batch size _Can be called by the contract owner or guardian_ #### Parameters | Name | Type | Description | | ---- | ------- | ---------------------------------- | | size | uint256 | The new maximum fulfill batch size | ### setGuardian ```solidity function setGuardian(address _guardian) external ``` Sets the guardian address for emergency pausing _Only owner can set the guardian_ #### Parameters | Name | Type | Description | | --------- | ------- | ------------------------ | | _guardian | address | The new guardian address | ### setHpkePublicKey ```solidity function setHpkePublicKey(bytes32 _hpkePublicKey) external ``` Sets the HPKE recipient public key #### Parameters | Name | Type | Description | | -------------- | ------- | ---------------------------------- | | _hpkePublicKey | bytes32 | X25519 public key as 32 raw octets | ### addWhitelistedAsset ```solidity function addWhitelistedAsset(address asset, address priceAdapter, address executionAdapter) external ``` Adds an asset to the whitelist _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | ---------------- | ------- | ------------------------------------- | | asset | address | The address of the asset to whitelist | | priceAdapter | address | The address of the price adapter | | executionAdapter | address | The address of the execution adapter | ### removeWhitelistedAsset ```solidity function removeWhitelistedAsset(address asset) external ``` Removes an asset from the whitelist _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | ----- | ------- | ------------------------------------------------- | | asset | address | The address of the asset to remove from whitelist | ### whitelistedAssetsLength ```solidity function whitelistedAssetsLength() external view returns (uint16) ``` Returns the total number of whitelisted assets #### Return Values | Name | Type | Description | | ---- | ------ | ------------------------------- | | [0] | uint16 | The count of whitelisted assets | ### getAllWhitelistedAssets ```solidity function getAllWhitelistedAssets() external view returns (address[] assets) ``` Returns all whitelisted assets #### Return Values | Name | Type | Description | | ------ | --------- | --------------------------------------- | | assets | address[] | An array of whitelisted asset addresses | ### decommissioningAssets ```solidity function decommissioningAssets() external view returns (address[]) ``` Decommissioning assets (pending liquidation) #### Return Values | Name | Type | Description | | ---- | --------- | ------------------------------------------- | | [0] | address[] | An array of decommissioning asset addresses | ### completeAssetsRemoval ```solidity function completeAssetsRemoval(address[] failedTokens) external ``` Completes assets removal; only callable by liquidity orchestrator. Assets that appear in failedTokens were not successfully processed this epoch and are kept in the decommissioning list for retry next epoch. #### Parameters | Name | Type | Description | | ------------ | --------- | ------------------------------------------------------------------- | | failedTokens | address[] | Tokens whose sell or buy execution failed during the current epoch. | ### getAllWhitelistedAssetNames ```solidity function getAllWhitelistedAssetNames() external view returns (string[] names) ``` Returns ERC20 human-readable names for all whitelisted assets #### Return Values | Name | Type | Description | | ----- | -------- | --------------------------------------------------------------- | | names | string[] | Array of token names in same order as getAllWhitelistedAssets() | ### getAllTokenDecimals ```solidity function getAllTokenDecimals() external view returns (uint8[] decimals) ``` Returns the token decimals for all whitelisted assets _Returns decimals in the same order as getAllWhitelistedAssets()_ #### Return Values | Name | Type | Description | | -------- | ------- | ----------------------------------------------------------- | | decimals | uint8[] | Array of token decimals corresponding to whitelisted assets | ### isWhitelisted ```solidity function isWhitelisted(address asset) external view returns (bool) ``` Checks if an asset is whitelisted #### Parameters | Name | Type | Description | | ----- | ------- | --------------------------------- | | asset | address | The address of the asset to check | #### Return Values | Name | Type | Description | | ---- | ---- | ------------------------------------------------- | | [0] | bool | True if the asset is whitelisted, false otherwise | ### addWhitelistedManager ```solidity function addWhitelistedManager(address manager) external ``` Adds a manager to the whitelist _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | ------- | ------- | --------------------------------------- | | manager | address | The address of the manager to whitelist | ### removeWhitelistedManager ```solidity function removeWhitelistedManager(address manager) external ``` Removes a manager from the whitelist _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | ------- | ------- | --------------------------------------------------- | | manager | address | The address of the manager to remove from whitelist | ### isWhitelistedManager ```solidity function isWhitelistedManager(address manager) external view returns (bool) ``` Checks if a manager is whitelisted #### Parameters | Name | Type | Description | | ------- | ------- | ----------------------------------- | | manager | address | The address of the manager to check | #### Return Values | Name | Type | Description | | ---- | ---- | --------------------------------------------------- | | [0] | bool | True if the manager is whitelisted, false otherwise | ### getAllOrionManagers ```solidity function getAllOrionManagers() external view returns (address[] managers) ``` Returns all Orion manager addresses #### Return Values | Name | Type | Description | | -------- | --------- | ----------------------------------- | | managers | address[] | An array of Orion manager addresses | ### addOrionVault ```solidity function addOrionVault(address vault, enum EventsLib.VaultType vaultType) external ``` Adds a new Orion vault to the protocol registry _Only callable by the vault factories contracts_ #### Parameters | Name | Type | Description | | --------- | ------------------------ | ----------------------------------------------- | | vault | address | The address of the vault to add to the registry | | vaultType | enum EventsLib.VaultType | Whether the vault is encrypted or transparent | ### removeOrionVault ```solidity function removeOrionVault(address vault) external ``` Deregisters an Orion vault from the protocol's registry _Callable by the contract owner or by the vault's manager. This action does not destroy the vault itself; it merely disconnects the vault from the protocol, which causes the share price to stale and renders strategist intents inactive. The vault remains in both active and decommissioning states, allowing orchestrator to process it one last time to liquidate all positions before final removal._ #### Parameters | Name | Type | Description | | ----- | ------- | -------------------------------------------------------- | | vault | address | The address of the vault to be removed from the registry | ### getAllOrionVaults ```solidity function getAllOrionVaults(enum EventsLib.VaultType vaultType) external view returns (address[]) ``` Returns all Orion vault addresses #### Parameters | Name | Type | Description | | --------- | ------------------------ | ------------------------------------------------- | | vaultType | enum EventsLib.VaultType | Whether to return encrypted or transparent vaults | #### Return Values | Name | Type | Description | | ---- | --------- | --------------------------------- | | [0] | address[] | An array of Orion vault addresses | ### isOrionVault ```solidity function isOrionVault(address vault) external view returns (bool) ``` Checks if an address is a registered Orion vault _This function checks both encrypted and transparent vaults_ #### Parameters | Name | Type | Description | | ----- | ------- | --------------------------------- | | vault | address | The address of the vault to check | #### Return Values | Name | Type | Description | | ---- | ---- | ---------------------------------------------------------------- | | [0] | bool | True if the address is a registered Orion vault, false otherwise | ### isEncryptedVault ```solidity function isEncryptedVault(address vault) external view returns (bool) ``` Checks if an address is a registered encrypted Orion vault #### Parameters | Name | Type | Description | | ----- | ------- | --------------------------------- | | vault | address | The address of the vault to check | #### Return Values | Name | Type | Description | | ---- | ---- | ---------------------------------------------------------------- | | [0] | bool | True if the address is an encrypted Orion vault, false otherwise | ### isDecommissioningVault ```solidity function isDecommissioningVault(address vault) external view returns (bool) ``` Checks if an address is a decommissioning Orion vault #### Parameters | Name | Type | Description | | ----- | ------- | --------------------------------- | | vault | address | The address of the vault to check | #### Return Values | Name | Type | Description | | ---- | ---- | --------------------------------------------------------------------- | | [0] | bool | True if the address is a decommissioning Orion vault, false otherwise | ### isDecommissionedVault ```solidity function isDecommissionedVault(address vault) external view returns (bool) ``` Checks if an address is a decommissioned Orion vault #### Parameters | Name | Type | Description | | ----- | ------- | --------------------------------- | | vault | address | The address of the vault to check | #### Return Values | Name | Type | Description | | ---- | ---- | -------------------------------------------------------------------- | | [0] | bool | True if the address is a decommissioned Orion vault, false otherwise | ### getAllDecommissionedVaults ```solidity function getAllDecommissionedVaults() external view returns (address[] vaults) ``` Returns all decommissioned Orion vault addresses #### Return Values | Name | Type | Description | | ------ | --------- | ------------------------------------------ | | vaults | address[] | An array of decommissioned vault addresses | ### completeVaultDecommissioning ```solidity function completeVaultDecommissioning(address vault) external ``` Completes the decommissioning process for a vault _This function removes the vault from the active vault lists and moves it to decommissioned vaults Only callable by the liquidity orchestrator after vault liquidation is complete_ #### Parameters | Name | Type | Description | | ----- | ------- | -------------------------------------------------------- | | vault | address | The address of the vault to complete decommissioning for | ### isSystemIdle ```solidity function isSystemIdle() public view returns (bool) ``` Checks if the system is idle _This function checks if both the liquidity orchestrator and the internal state orchestrator are idle_ #### Return Values | Name | Type | Description | | ---- | ---- | ------------------------------------------- | | [0] | bool | True if the system is idle, false otherwise | ### getTokenDecimals ```solidity function getTokenDecimals(address token) external view returns (uint8) ``` Returns the stored decimals for a whitelisted token _Alias of `tokenDecimals` for backward-compatible ABI._ #### Parameters | Name | Type | Description | | ----- | ------- | ----------------- | | token | address | The token address | #### Return Values | Name | Type | Description | | ---- | ----- | ------------------------------------ | | [0] | uint8 | The number of decimals for the token | ### setUpgradeTimelock ```solidity function setUpgradeTimelock(address newTimelock) external ``` Sets the upgrade timelock address. _If no timelock is set yet, only the owner may call this. Once a timelock is active, only the timelock itself may replace it, preventing the owner from bypassing the delay._ #### Parameters | Name | Type | Description | | ----------- | ------- | ----------------------------------------------------------------------------------------- | | newTimelock | address | The new timelock address (e.g. OpenZeppelin TimelockController); address(0) not permitted | ### _authorizeUpgrade ```solidity function _authorizeUpgrade(address) internal ``` Authorizes an upgrade to a new implementation _Requires the caller to be the upgrade timelock (if set) or the owner (during initial bootstrapping before a timelock has been configured)._ --- # ERC4626ExecutionAdapter > Execution adapter for ERC-4626 vaults with generic underlying asset. _Architecture: - Handles same-asset flows: protocolUnderlying=vaultUnderlying → vaultShares - Handles cross-asset flows: protocolUnderlying → ExecutionAdapter → vaultUnderlying → vaultShares_ ### CONFIG ```solidity contract IOrionConfig CONFIG ``` Orion protocol configuration contract ### UNDERLYING_ASSET ```solidity contract IERC20 UNDERLYING_ASSET ``` Protocol underlying asset ### LIQUIDITY_ORCHESTRATOR ```solidity contract ILiquidityOrchestrator LIQUIDITY_ORCHESTRATOR ``` Liquidity orchestrator contract ### onlyLiquidityOrchestrator ```solidity modifier onlyLiquidityOrchestrator() ``` _Restricts state-changing adapter functions to the liquidity orchestrator_ ### constructor ```solidity constructor(address configAddress) public ``` Constructor #### Parameters | Name | Type | Description | | ------------- | ------- | ---------------------------- | | configAddress | address | OrionConfig contract address | ### _validateExecutionAdapter ```solidity function _validateExecutionAdapter(address asset) internal view ``` Internal validation function that performs compatibility checks #### Parameters | Name | Type | Description | | ----- | ------- | ------------------------------------ | | asset | address | The address of the asset to validate | ### validateExecutionAdapter ```solidity function validateExecutionAdapter(address asset) external view ``` Validates that the given asset is compatible with this adapter #### Parameters | Name | Type | Description | | ----- | ------- | ------------------------------------ | | asset | address | The address of the asset to validate | ### previewBuy ```solidity function previewBuy(address vaultAsset, uint256 sharesAmount) external returns (uint256 underlyingAmount) ``` Previews the underlying amount required to buy a given amount of an asset _Particularly useful in keeping execution adapters composable with each other, making refunding unnecessary when higher-level adapters use the previewed amount for downstream buy() calls._ #### Parameters | Name | Type | Description | | ------------ | ------- | --------------------------------- | | vaultAsset | address | | | sharesAmount | uint256 | The amount of asset shares to buy | #### Return Values | Name | Type | Description | | ---------------- | ------- | ------------------------------ | | underlyingAmount | uint256 | The underlying amount required | ### sell ```solidity function sell(address vaultAsset, uint256 sharesAmount) external returns (uint256 receivedUnderlyingAmount) ``` Executes a sell operation by converting asset shares to underlying assets #### Parameters | Name | Type | Description | | ------------ | ------- | ---------------------------------- | | vaultAsset | address | | | sharesAmount | uint256 | The amount of asset shares to sell | #### Return Values | Name | Type | Description | | ------------------------ | ------- | ----------- | | receivedUnderlyingAmount | uint256 | | ### buy ```solidity function buy(address vaultAsset, uint256 sharesAmount) external returns (uint256 spentUnderlyingAmount) ``` Executes a buy operation by converting underlying assets to asset shares #### Parameters | Name | Type | Description | | ------------ | ------- | --------------------------------- | | vaultAsset | address | | | sharesAmount | uint256 | The amount of asset shares to buy | #### Return Values | Name | Type | Description | | --------------------- | ------- | ----------- | | spentUnderlyingAmount | uint256 | | --- # UniswapV3ExecutionAdapter > Execution adapter for Uniswap V3 pools _amountOutMinimum is set to 0 at the Uniswap level because slippage protection is enforced by the LiquidityOrchestrator. This avoids duplicating slippage checks._ ### UNISWAP_V3_FACTORY ```solidity contract IUniswapV3Factory UNISWAP_V3_FACTORY ``` Uniswap V3 Factory contract ### SWAP_ROUTER ```solidity contract ISwapRouter SWAP_ROUTER ``` Uniswap V3 SwapRouter contract ### QUOTER ```solidity contract IQuoterV2 QUOTER ``` Uniswap V3 QuoterV2 contract ### CONFIG ```solidity contract IOrionConfig CONFIG ``` Orion Config contract ### UNDERLYING_ASSET ```solidity address UNDERLYING_ASSET ``` Protocol underlying asset ### LIQUIDITY_ORCHESTRATOR ```solidity contract ILiquidityOrchestrator LIQUIDITY_ORCHESTRATOR ``` Liquidity orchestrator contract ### assetFee ```solidity mapping(address => uint24) assetFee ``` asset => Uniswap V3 pool fee tier ### onlyOwnerOrGuardian ```solidity modifier onlyOwnerOrGuardian() ``` _Restricts function to only owner or guardian_ ### constructor ```solidity constructor(address initialOwner_, address factoryAddress, address swapRouterAddress, address quoterAddress, address configAddress) public ``` Constructor #### Parameters | Name | Type | Description | | ----------------- | ------- | -------------------------------- | | initialOwner_ | address | The address of the initial owner | | factoryAddress | address | Uniswap V3 Factory address | | swapRouterAddress | address | Uniswap V3 SwapRouter address | | quoterAddress | address | Uniswap V3 QuoterV2 address | | configAddress | address | OrionConfig contract address | ### setAssetFee ```solidity function setAssetFee(address asset, uint24 fee) external ``` Sets the fee tier for a given asset #### Parameters | Name | Type | Description | | ----- | ------- | ------------------------ | | asset | address | The address of the asset | | fee | uint24 | The fee tier to set | ### validateExecutionAdapter ```solidity function validateExecutionAdapter(address asset) external view ``` Validates that the given asset is compatible with this adapter #### Parameters | Name | Type | Description | | ----- | ------- | ------------------------------------ | | asset | address | The address of the asset to validate | ### previewBuy ```solidity function previewBuy(address asset, uint256 amount) external returns (uint256 underlyingAmount) ``` Previews the underlying amount required to buy a given amount of an asset _Particularly useful in keeping execution adapters composable with each other, making refunding unnecessary when higher-level adapters use the previewed amount for downstream buy() calls._ #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------- | | asset | address | The address of the asset to buy | | amount | uint256 | | #### Return Values | Name | Type | Description | | ---------------- | ------- | ------------------------------ | | underlyingAmount | uint256 | The underlying amount required | ### sell ```solidity function sell(address asset, uint256 amount) external returns (uint256 receivedAmount) ``` Executes a sell operation by converting asset shares to underlying assets #### Parameters | Name | Type | Description | | ------ | ------- | -------------------------------- | | asset | address | The address of the asset to sell | | amount | uint256 | | #### Return Values | Name | Type | Description | | -------------- | ------- | ----------- | | receivedAmount | uint256 | | ### buy ```solidity function buy(address asset, uint256 amount) external returns (uint256 spentAmount) ``` Executes a buy operation by converting underlying assets to asset shares #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------- | | asset | address | The address of the asset to buy | | amount | uint256 | | #### Return Values | Name | Type | Description | | ----------- | ------- | ----------- | | spentAmount | uint256 | | --- # EncryptedVaultFactory > A factory contract for creating Orion encrypted vaults using Beacon Proxy pattern _This contract deploys BeaconProxy instances that point to a shared encrypted vault implementation._ ### config ```solidity contract IOrionConfig config ``` Orion Config contract address ### vaultBeacon ```solidity contract UpgradeableBeacon vaultBeacon ``` UpgradeableBeacon for encrypted vaults ### upgradeTimelock ```solidity address upgradeTimelock ``` Address of the upgrade timelock that must authorise all implementation upgrades ### constructor ```solidity constructor() public ``` Constructor that disables initializers for the implementation contract ### initialize ```solidity function initialize(address initialOwner, address configAddress, address vaultBeaconAddress) public ``` Initialize the contract #### Parameters | Name | Type | Description | | ------------------ | ------- | ----------------------------------------------- | | initialOwner | address | The address of the initial owner | | configAddress | address | The address of the OrionConfig contract | | vaultBeaconAddress | address | The address of the UpgradeableBeacon for vaults | ### createVault ```solidity function createVault(address strategist, string name, string symbol, uint8 feeType, uint16 performanceFee, uint16 managementFee, address depositAccessControl, address holderAccessControl, address transferAccessControl) external returns (address vault) ``` Creates a new encrypted vault #### Parameters | Name | Type | Description | | --------------------- | ------- | ----------------------------------------------------- | | strategist | address | The address of the vault strategist | | name | string | The name of the vault | | symbol | string | The symbol of the vault | | feeType | uint8 | The fee type | | performanceFee | uint16 | The performance fee | | managementFee | uint16 | The management fee | | depositAccessControl | address | Deposit access control (address(0) = permissionless) | | holderAccessControl | address | Holder access control (address(0) = permissionless) | | transferAccessControl | address | Transfer access control (address(0) = permissionless) | #### Return Values | Name | Type | Description | | ----- | ------- | -------------------------------------- | | vault | address | The address of the new encrypted vault | ### setVaultBeacon ```solidity function setVaultBeacon(address newVaultBeacon) external ``` Updates the vault beacon address #### Parameters | Name | Type | Description | | -------------- | ------- | --------------------------------- | | newVaultBeacon | address | The new UpgradeableBeacon address | ### setUpgradeTimelock ```solidity function setUpgradeTimelock(address newTimelock) external ``` Sets the upgrade timelock address. _If no timelock is set yet, only the owner may call this. Once a timelock is active, only the timelock itself may replace it, preventing the owner from bypassing the delay._ #### Parameters | Name | Type | Description | | ----------- | ------- | ----------------------------------------------------------------------------------------- | | newTimelock | address | The new timelock address (e.g. OpenZeppelin TimelockController); address(0) not permitted | ### _authorizeUpgrade ```solidity function _authorizeUpgrade(address) internal ``` Authorizes an upgrade to a new implementation _Requires the caller to be the upgrade timelock (if set) or the owner (during initial bootstrapping before a timelock has been configured)._ --- # TransparentVaultFactory > A factory contract for creating Orion transparent vaults using Beacon Proxy pattern _This contract deploys BeaconProxy instances that point to a shared transparent vault implementation._ ### config ```solidity contract IOrionConfig config ``` Orion Config contract address ### vaultBeacon ```solidity contract UpgradeableBeacon vaultBeacon ``` UpgradeableBeacon for transparent vaults ### upgradeTimelock ```solidity address upgradeTimelock ``` Address of the upgrade timelock that must authorise all implementation upgrades ### constructor ```solidity constructor() public ``` Constructor that disables initializers for the implementation contract ### initialize ```solidity function initialize(address initialOwner, address configAddress, address vaultBeaconAddress) public ``` Initialize the contract #### Parameters | Name | Type | Description | | ------------------ | ------- | ----------------------------------------------- | | initialOwner | address | The address of the initial owner | | configAddress | address | The address of the OrionConfig contract | | vaultBeaconAddress | address | The address of the UpgradeableBeacon for vaults | ### createVault ```solidity function createVault(address strategist, string name, string symbol, uint8 feeType, uint16 performanceFee, uint16 managementFee, address depositAccessControl, address holderAccessControl, address transferAccessControl) external returns (address vault) ``` Creates a new transparent vault #### Parameters | Name | Type | Description | | --------------------- | ------- | ----------------------------------------------------- | | strategist | address | The address of the vault strategist | | name | string | The name of the vault | | symbol | string | The symbol of the vault | | feeType | uint8 | The fee type | | performanceFee | uint16 | The performance fee | | managementFee | uint16 | The management fee | | depositAccessControl | address | Deposit access control (address(0) = permissionless) | | holderAccessControl | address | Holder access control (address(0) = permissionless) | | transferAccessControl | address | Transfer access control (address(0) = permissionless) | #### Return Values | Name | Type | Description | | ----- | ------- | ---------------------------------------- | | vault | address | The address of the new transparent vault | ### setVaultBeacon ```solidity function setVaultBeacon(address newVaultBeacon) external ``` Updates the vault beacon address #### Parameters | Name | Type | Description | | -------------- | ------- | --------------------------------- | | newVaultBeacon | address | The new UpgradeableBeacon address | ### setUpgradeTimelock ```solidity function setUpgradeTimelock(address newTimelock) external ``` Sets the upgrade timelock address. _If no timelock is set yet, only the owner may call this. Once a timelock is active, only the timelock itself may replace it, preventing the owner from bypassing the delay._ #### Parameters | Name | Type | Description | | ----------- | ------- | ----------------------------------------------------------------------------------------- | | newTimelock | address | The new timelock address (e.g. OpenZeppelin TimelockController); address(0) not permitted | ### _authorizeUpgrade ```solidity function _authorizeUpgrade(address) internal ``` Authorizes an upgrade to a new implementation _Requires the caller to be the upgrade timelock (if set) or the owner (during initial bootstrapping before a timelock has been configured)._ --- # IExecutionAdapter > Interface for execution adapters that handle asset trading operations _Execution adapters are responsible for converting between the Orion protocol's underlying token and various asset types (ERC-4626 vaults, ERC-20 tokens, etc.). All buy/sell operations use the Orion underlying token as the base currency, regardless of the token standard of the target asset. The underlying token is defined in the OrionConfig contract and serves as the protocol's base asset._ ### validateExecutionAdapter ```solidity function validateExecutionAdapter(address asset) external view ``` Validates that the given asset is compatible with this adapter #### Parameters | Name | Type | Description | | ----- | ------- | ------------------------------------ | | asset | address | The address of the asset to validate | ### previewBuy ```solidity function previewBuy(address asset, uint256 sharesAmount) external returns (uint256 underlyingAmount) ``` Previews the underlying amount required to buy a given amount of an asset _Particularly useful in keeping execution adapters composable with each other, making refunding unnecessary when higher-level adapters use the previewed amount for downstream buy() calls._ #### Parameters | Name | Type | Description | | ------------ | ------- | --------------------------------- | | asset | address | The address of the asset to buy | | sharesAmount | uint256 | The amount of asset shares to buy | #### Return Values | Name | Type | Description | | ---------------- | ------- | ------------------------------ | | underlyingAmount | uint256 | The underlying amount required | ### sell ```solidity function sell(address asset, uint256 sharesAmount) external returns (uint256 executionUnderlyingAmount) ``` Executes a sell operation by converting asset shares to underlying assets #### Parameters | Name | Type | Description | | ------------ | ------- | ---------------------------------- | | asset | address | The address of the asset to sell | | sharesAmount | uint256 | The amount of asset shares to sell | #### Return Values | Name | Type | Description | | ------------------------- | ------- | ----------------------------------------------- | | executionUnderlyingAmount | uint256 | The actual execution underlying amount received | ### buy ```solidity function buy(address asset, uint256 sharesAmount) external returns (uint256 executionUnderlyingAmount) ``` Executes a buy operation by converting underlying assets to asset shares #### Parameters | Name | Type | Description | | ------------ | ------- | --------------------------------- | | asset | address | The address of the asset to buy | | sharesAmount | uint256 | The amount of asset shares to buy | #### Return Values | Name | Type | Description | | ------------------------- | ------- | -------------------------------------------- | | executionUnderlyingAmount | uint256 | The actual execution underlying amount spent | --- # ILiquidityOrchestrator > Interface for the liquidity orchestrator ### LiquidityUpkeepPhase Upkeep phase enum for liquidity orchestration ```solidity enum LiquidityUpkeepPhase { Idle, StateCommitment, SellingLeg, BuyingLeg, ProcessVaultOperations } ``` ### PublicValuesStruct ```solidity struct PublicValuesStruct { bytes32 inputCommitment; bytes32 outputCommitment; } ``` ### StatesStruct ```solidity struct StatesStruct { struct ILiquidityOrchestrator.VaultState[] vaults; struct ILiquidityOrchestrator.SellLegOrders sellLeg; struct ILiquidityOrchestrator.BuyLegOrders buyLeg; uint256 bufferIncrease; uint256 epochProtocolFees; uint256 nettedRebalanceVolumeUnderlying; } ``` ### VaultState ```solidity struct VaultState { bool processRedeem; uint256 totalAssetsForRedeem; uint256 totalAssetsForDeposit; uint256 finalTotalAssets; uint256 managementFee; uint256 performanceFee; address[] tokens; uint256[] shares; bytes portfolioCiphertext; } ``` ### SellLegOrders ```solidity struct SellLegOrders { address[] sellingTokens; uint256[] sellingAmounts; uint256[] sellingEstimatedUnderlyingAmounts; } ``` ### BuyLegOrders ```solidity struct BuyLegOrders { address[] buyingTokens; uint256[] buyingAmounts; uint256[] buyingEstimatedUnderlyingAmounts; } ``` ### currentPhase ```solidity function currentPhase() external view returns (enum ILiquidityOrchestrator.LiquidityUpkeepPhase) ``` Returns the current upkeep phase #### Return Values | Name | Type | Description | | ---- | ------------------------------------------------ | -------------------------------- | | [0] | enum ILiquidityOrchestrator.LiquidityUpkeepPhase | The current LiquidityUpkeepPhase | ### completedInCurrentMinibatch ```solidity function completedInCurrentMinibatch() external view returns (uint16) ``` Returns how many leg slots were already processed in the active minibatch window #### Return Values | Name | Type | Description | | ---- | ------ | --------------------------------------------------------- | | [0] | uint16 | Leg slots completed since `currentMinibatchIndex` was set | ### targetBufferRatio ```solidity function targetBufferRatio() external view returns (uint256) ``` Returns the target buffer ratio #### Return Values | Name | Type | Description | | ---- | ------- | ----------------------- | | [0] | uint256 | The target buffer ratio | ### slippageTolerance ```solidity function slippageTolerance() external view returns (uint256) ``` Returns the slippage tolerance #### Return Values | Name | Type | Description | | ---- | ------- | ---------------------- | | [0] | uint256 | The slippage tolerance | ### bufferAmount ```solidity function bufferAmount() external view returns (uint256) ``` Returns the current buffer amount #### Return Values | Name | Type | Description | | ---- | ------- | ------------------------- | | [0] | uint256 | The current buffer amount | ### initialEpochBufferAmount ```solidity function initialEpochBufferAmount() external view returns (uint256) ``` Returns the epoch-start buffer snapshot used as deterministic proof input anchor #### Return Values | Name | Type | Description | | ---- | ------- | ------------------------------- | | [0] | uint256 | The initial epoch buffer amount | ### pendingProtocolFees ```solidity function pendingProtocolFees() external view returns (uint256) ``` Returns the pending protocol fees #### Return Values | Name | Type | Description | | ---- | ------- | ------------------------- | | [0] | uint256 | The pending protocol fees | ### epochDuration ```solidity function epochDuration() external view returns (uint32) ``` Returns the epoch duration #### Return Values | Name | Type | Description | | ---- | ------ | ----------------------------- | | [0] | uint32 | The epoch duration in seconds | ### updateEpochDuration ```solidity function updateEpochDuration(uint32 newEpochDuration) external ``` Updates the epoch duration #### Parameters | Name | Type | Description | | ---------------- | ------ | --------------------------------- | | newEpochDuration | uint32 | The new epoch duration in seconds | ### EpochStateView Struct representing the full epoch state view _This struct contains all epoch state data in a returnable format_ ```solidity struct EpochStateView { address[] vaultsEpoch; uint16 activeNettingFeeCoefficient; uint16 activeRsFeeCoefficient; struct IOrionVault.FeeModel[] vaultFeeModels; bytes32 epochStateCommitment; } ``` ### getEpochState ```solidity function getEpochState() external view returns (struct ILiquidityOrchestrator.EpochStateView) ``` Returns the full epoch state _Returns all epoch state data in a single struct. Use this instead of individual getters._ #### Return Values | Name | Type | Description | | ---- | -------------------------------------------- | ----------------------------- | | [0] | struct ILiquidityOrchestrator.EpochStateView | The complete epoch state view | ### getFailedEpochTokens ```solidity function getFailedEpochTokens() external view returns (address[]) ``` Returns tokens that failed during the current epoch's sell/buy execution #### Return Values | Name | Type | Description | | ---- | --------- | ----------------------------------- | | [0] | address[] | List of token addresses that failed | ### getAssetPrices ```solidity function getAssetPrices(address[] assets) external view returns (uint256[] assetPrices) ``` Gets asset prices for the epoch #### Parameters | Name | Type | Description | | ------ | --------- | ------------------------ | | assets | address[] | Array of asset addresses | #### Return Values | Name | Type | Description | | ----------- | --------- | --------------------- | | assetPrices | uint256[] | Array of asset prices | ### updateExecutionMinibatchSize ```solidity function updateExecutionMinibatchSize(uint8 _executionMinibatchSize) external ``` Updates the execution minibatch size #### Parameters | Name | Type | Description | | ----------------------- | ----- | -------------------------------- | | _executionMinibatchSize | uint8 | The new execution minibatch size | ### updateMinibatchSize ```solidity function updateMinibatchSize(uint8 _minibatchSize) external ``` Updates the minibatch size for fulfill deposit and redeem processing #### Parameters | Name | Type | Description | | -------------- | ----- | ---------------------- | | _minibatchSize | uint8 | The new minibatch size | ### updateCommitmentMinibatchSize ```solidity function updateCommitmentMinibatchSize(uint8 _commitmentMinibatchSize) external ``` Updates the number of vault leaves folded per StateCommitment upkeep step. #### Parameters | Name | Type | Description | | ------------------------ | ----- | --------------------------------- | | _commitmentMinibatchSize | uint8 | The new commitment minibatch size | ### updateAutomationRegistry ```solidity function updateAutomationRegistry(address newAutomationRegistry) external ``` Updates the Chainlink Automation Registry address #### Parameters | Name | Type | Description | | --------------------- | ------- | ----------------------------------- | | newAutomationRegistry | address | The new automation registry address | ### updateVerifier ```solidity function updateVerifier(address newVerifier) external ``` Updates the verifier contract address _Callable mid-epoch for maintenance. The owner must coordinate with the zk-orchestrator so proofs submitted after this change are verified by the new contract._ #### Parameters | Name | Type | Description | | ----------- | ------- | ---------------------------------------- | | newVerifier | address | The address of the new verifier contract | ### updateVKey ```solidity function updateVKey(bytes32 newvKey) external ``` Updates the internal state orchestrator verification key _Callable mid-epoch for maintenance. Reverts with InvalidArguments if newvKey is bytes32(0). The owner must coordinate with the zk-orchestrator so proofs submitted after this change match the new verification key and current epoch commitments._ #### Parameters | Name | Type | Description | | ------- | ------- | ------------------------ | | newvKey | bytes32 | The new verification key | ### setTargetBufferRatio ```solidity function setTargetBufferRatio(uint256 _targetBufferRatio) external ``` Sets the target buffer ratio #### Parameters | Name | Type | Description | | ------------------ | ------- | --------------------------- | | _targetBufferRatio | uint256 | The new target buffer ratio | ### setSlippageTolerance ```solidity function setSlippageTolerance(uint256 _slippageTolerance) external ``` Sets the slippage tolerance #### Parameters | Name | Type | Description | | ------------------ | ------- | -------------------------- | | _slippageTolerance | uint256 | The new slippage tolerance | ### claimProtocolFees ```solidity function claimProtocolFees(uint256 amount) external ``` Claim protocol fees with specified amount _Called by the Owner to claim a specific amount of protocol fees_ #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------------ | | amount | uint256 | The amount of protocol fees to claim | ### setExecutionAdapter ```solidity function setExecutionAdapter(address asset, contract IExecutionAdapter adapter) external ``` Register or replace the execution adapter for an asset. _Can only be called by the Orion Config contract._ #### Parameters | Name | Type | Description | | ------- | -------------------------- | ------------------------------------ | | asset | address | The address of the asset. | | adapter | contract IExecutionAdapter | The execution adapter for the asset. | ### executionAdapterOf ```solidity function executionAdapterOf(address asset) external view returns (contract IExecutionAdapter) ``` Returns the execution adapter for a given asset #### Parameters | Name | Type | Description | | ----- | ------- | ------------------------ | | asset | address | The address of the asset | #### Return Values | Name | Type | Description | | ---- | -------------------------- | ----------------------------------- | | [0] | contract IExecutionAdapter | The execution adapter for the asset | ### returnDepositFunds ```solidity function returnDepositFunds(address user, uint256 amount) external ``` Return deposit funds to a user who cancelled their deposit request _Called by vault contracts when users cancel deposit requests_ #### Parameters | Name | Type | Description | | ------ | ------- | --------------------------- | | user | address | The user to return funds to | | amount | uint256 | The amount to return | ### transferVaultFees ```solidity function transferVaultFees(uint256 amount) external ``` Transfer pending fees to manager _Called by vault contracts when managers claim their fees_ #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------ | | amount | uint256 | The amount of fees to transfer | ### transferRedemptionFunds ```solidity function transferRedemptionFunds(address user, uint256 amount) external ``` Transfer redemption funds to a user after shares are burned _Called by vault contracts when processing redemption requests_ #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------------------- | | user | address | The user to transfer funds to | | amount | uint256 | The amount of underlying assets to transfer | ### depositLiquidity ```solidity function depositLiquidity(uint256 amount) external ``` Deposits underlying assets to the liquidity orchestrator buffer _Increases the buffer amount by the deposited amount._ #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------------------ | | amount | uint256 | The amount of underlying assets to deposit | ### withdrawLiquidity ```solidity function withdrawLiquidity(uint256 amount) external ``` Withdraws underlying assets from the liquidity orchestrator buffer _Can only be called by the owner. Decreases the buffer amount by the withdrawn amount. Includes safety checks to prevent predatory withdrawals that could break protocol operations._ #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------------------- | | amount | uint256 | The amount of underlying assets to withdraw | ### withdraw ```solidity function withdraw(uint256 assets, address receiver) external ``` Synchronous redemption for decommissioned vaults _Called by vault contracts to process synchronous redemptions for LPs with share tokens_ #### Parameters | Name | Type | Description | | -------- | ------- | -------------------------------------------- | | assets | uint256 | The amount of underlying assets to withdraw | | receiver | address | The address to receive the underlying assets | ### pause ```solidity function pause() external ``` Pauses protocol operations for the orchestrator _Can only be called by guardian or owner for emergency situations_ ### unpause ```solidity function unpause() external ``` Unpauses protocol operations for the orchestrator _Can only be called by owner after resolving emergency (not guardian: requires owner approval to resume)_ ### checkUpkeep ```solidity function checkUpkeep() external view returns (bool upkeepNeeded) ``` Checks if upkeep is needed _the API is inspired but different from the Chainlink Automation interface._ #### Return Values | Name | Type | Description | | ------------ | ---- | ------------------------ | | upkeepNeeded | bool | Whether upkeep is needed | ### performUpkeep ```solidity function performUpkeep(bytes _publicValues, bytes proofBytes, bytes statesBytes) external ``` Performs the upkeep _the API is inspired but different from the Chainlink Automation interface._ #### Parameters | Name | Type | Description | | ------------- | ----- | ------------------------------------------------------------------ | | _publicValues | bytes | Encoded PublicValuesStruct containing input and output commitments | | proofBytes | bytes | The zk-proof bytes | | statesBytes | bytes | Encoded StatesStruct containing state transition payload. | --- # IOrionAccessControl > Deposit access control: who may request a deposit. ## IOrionDepositAccessControl ### canRequestDeposit ```solidity function canRequestDeposit(address sender, bytes data) external view returns (bool) ``` Check if a deposit request is allowed #### Parameters | Name | Type | Description | | ------ | ------- | ---------------------------------- | | sender | address | The address requesting the deposit | | data | bytes | Additional data | #### Return Values | Name | Type | Description | | ---- | ---- | ------------------------------------------------------- | | [0] | bool | True if the deposit request is allowed, false otherwise | ## IOrionHolderAccessControl Holder access control: who may hold vault shares. ### canHoldShares ```solidity function canHoldShares(address account) external view returns (bool) ``` Check if an account may hold vault shares #### Parameters | Name | Type | Description | | ------- | ------- | ---------------------------- | | account | address | The prospective share holder | #### Return Values | Name | Type | Description | | ---- | ---- | ---------------------------------------------------- | | [0] | bool | True if the account may hold shares, false otherwise | ## IOrionTransferAccessControl Transfer access control: who may transfer vault shares. ### canTransferShares ```solidity function canTransferShares(address sender, bytes data) external view returns (bool) ``` Check if an account may transfer vault shares #### Parameters | Name | Type | Description | | ------ | ------- | ---------------------------- | | sender | address | The prospective share sender | | data | bytes | Additional data | #### Return Values | Name | Type | Description | | ---- | ---- | -------------------------------------------------------- | | [0] | bool | True if the account may transfer shares, false otherwise | --- # IOrionConfig > Interface for the Orion config contract ### liquidityOrchestrator ```solidity function liquidityOrchestrator() external view returns (address) ``` Returns the address of the liquidity orchestrator contract _This orchestrator manages liquidity operations and coordination_ #### Return Values | Name | Type | Description | | ---- | ------- | ----------------------------------------- | | [0] | address | The address of the liquidity orchestrator | ### underlyingAsset ```solidity function underlyingAsset() external view returns (contract IERC20) ``` Returns the address of the underlying asset used by the protocol _This is the base asset that the protocol operates with_ #### Return Values | Name | Type | Description | | ---- | --------------- | -------------------------------------------- | | [0] | contract IERC20 | The address of the underlying asset contract | ### priceAdapterRegistry ```solidity function priceAdapterRegistry() external view returns (address) ``` Returns the address of the price adapter registry contract _This registry is responsible for managing asset price adapters_ #### Return Values | Name | Type | Description | | ---- | ------- | ----------------------------------------- | | [0] | address | The address of the price adapter registry | ### strategistIntentDecimals ```solidity function strategistIntentDecimals() external view returns (uint8) ``` Returns the number of decimal places used for strategist intent calculations _This value is used to scale strategist intent values for precision_ #### Return Values | Name | Type | Description | | ---- | ----- | --------------------------------------------------- | | [0] | uint8 | The number of decimal places for strategist intents | ### priceAdapterDecimals ```solidity function priceAdapterDecimals() external view returns (uint8) ``` Returns the number of decimal places used for price adapters _This value is used to scale price adapter values for precision_ #### Return Values | Name | Type | Description | | ---- | ----- | ----------------------------------------------- | | [0] | uint8 | The number of decimal places for price adapters | ### riskFreeRate ```solidity function riskFreeRate() external view returns (uint16) ``` Returns the risk-free rate #### Return Values | Name | Type | Description | | ---- | ------ | ------------------ | | [0] | uint16 | The risk-free rate | ### guardian ```solidity function guardian() external view returns (address) ``` Returns the guardian address #### Return Values | Name | Type | Description | | ---- | ------- | -------------------- | | [0] | address | The guardian address | ### hpkePublicKey ```solidity function hpkePublicKey() external view returns (bytes32) ``` Returns the HPKE recipient public key #### Return Values | Name | Type | Description | | ---- | ------- | ----------------------------- | | [0] | bytes32 | The HPKE recipient public key | ### setHpkePublicKey ```solidity function setHpkePublicKey(bytes32 _hpkePublicKey) external ``` Sets the HPKE recipient public key #### Parameters | Name | Type | Description | | -------------- | ------- | ---------------------------------- | | _hpkePublicKey | bytes32 | X25519 public key as 32 raw octets | ### updateProtocolFees ```solidity function updateProtocolFees(uint16 _nettingFeeCoefficient, uint16 _rsFeeCoefficient) external ``` Updates the protocol fees _If called while a previous fee change is still in cooldown, the prior scheduled change is cancelled: activeProtocolFees() returns the current (old) rates, which are stored as old coefficients, then the new coefficients overwrite the prior schedule. The previously scheduled intermediate fees never take effect._ #### Parameters | Name | Type | Description | | ---------------------- | ------ | ---------------------------------------------------------------- | | _nettingFeeCoefficient | uint16 | The new netting fee coefficient (bps of netted rebalance volume) | | _rsFeeCoefficient | uint16 | The new revenue share fee coefficient | ### activeProtocolFees ```solidity function activeProtocolFees() external view returns (uint16 nettingFee, uint16 rsFee) ``` Returns the active protocol fees (old during cooldown, new after) #### Return Values | Name | Type | Description | | ---------- | ------ | ---------------------------------------- | | nettingFee | uint16 | The active netting fee coefficient | | rsFee | uint16 | The active revenue share fee coefficient | ### setLiquidityOrchestrator ```solidity function setLiquidityOrchestrator(address orchestrator) external ``` Sets the liquidity orchestrator for the protocol _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | ------------ | ------- | ----------------------------------------- | | orchestrator | address | The address of the liquidity orchestrator | ### setVaultFactory ```solidity function setVaultFactory(address transparentFactory) external ``` Sets the vault factory for the protocol _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | ------------------ | ------- | -------------------------------------------- | | transparentFactory | address | The address of the transparent vault factory | ### encryptedVaultFactory ```solidity function encryptedVaultFactory() external view returns (address) ``` Returns the encrypted vault factory address #### Return Values | Name | Type | Description | | ---- | ------- | ------------------------------------------ | | [0] | address | The address of the encrypted vault factory | ### setEncryptedVaultFactory ```solidity function setEncryptedVaultFactory(address encryptedFactory) external ``` Sets the encrypted vault factory for the protocol _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | ---------------- | ------- | ------------------------------------------ | | encryptedFactory | address | The address of the encrypted vault factory | ### setPriceAdapterRegistry ```solidity function setPriceAdapterRegistry(address registry) external ``` Sets the price adapter registry for the protocol _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | -------- | ------- | ----------------------------------------- | | registry | address | The address of the price adapter registry | ### setProtocolRiskFreeRate ```solidity function setProtocolRiskFreeRate(uint16 newRiskFreeRate) external ``` Sets the protocol risk-free rate _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | --------------- | ------ | ------------------ | | newRiskFreeRate | uint16 | The risk-free rate | ### addWhitelistedAsset ```solidity function addWhitelistedAsset(address asset, address priceAdapter, address executionAdapter) external ``` Adds an asset to the whitelist _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | ---------------- | ------- | ------------------------------------- | | asset | address | The address of the asset to whitelist | | priceAdapter | address | The address of the price adapter | | executionAdapter | address | The address of the execution adapter | ### removeWhitelistedAsset ```solidity function removeWhitelistedAsset(address asset) external ``` Removes an asset from the whitelist _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | ----- | ------- | ------------------------------------------------- | | asset | address | The address of the asset to remove from whitelist | ### whitelistedAssetsLength ```solidity function whitelistedAssetsLength() external view returns (uint16) ``` Returns the total number of whitelisted assets #### Return Values | Name | Type | Description | | ---- | ------ | ------------------------------- | | [0] | uint16 | The count of whitelisted assets | ### getAllWhitelistedAssets ```solidity function getAllWhitelistedAssets() external view returns (address[]) ``` Returns all whitelisted assets #### Return Values | Name | Type | Description | | ---- | --------- | --------------------------------------- | | [0] | address[] | An array of whitelisted asset addresses | ### getAllWhitelistedAssetNames ```solidity function getAllWhitelistedAssetNames() external view returns (string[] names) ``` Returns ERC20 human-readable names for all whitelisted assets #### Return Values | Name | Type | Description | | ----- | -------- | --------------------------------------------------------------- | | names | string[] | Array of token names in same order as getAllWhitelistedAssets() | ### getAllTokenDecimals ```solidity function getAllTokenDecimals() external view returns (uint8[] decimals) ``` Returns the token decimals for all whitelisted assets _Returns decimals in the same order as getAllWhitelistedAssets()_ #### Return Values | Name | Type | Description | | -------- | ------- | ----------------------------------------------------------- | | decimals | uint8[] | Array of token decimals corresponding to whitelisted assets | ### isWhitelisted ```solidity function isWhitelisted(address asset) external view returns (bool) ``` Checks if an asset is whitelisted #### Parameters | Name | Type | Description | | ----- | ------- | --------------------------------- | | asset | address | The address of the asset to check | #### Return Values | Name | Type | Description | | ---- | ---- | ------------------------------------------------- | | [0] | bool | True if the asset is whitelisted, false otherwise | ### decommissioningAssets ```solidity function decommissioningAssets() external view returns (address[]) ``` Decommissioning assets (pending liquidation) #### Return Values | Name | Type | Description | | ---- | --------- | ------------------------------------------- | | [0] | address[] | An array of decommissioning asset addresses | ### completeAssetsRemoval ```solidity function completeAssetsRemoval(address[] failedTokens) external ``` Completes assets removal; only callable by liquidity orchestrator. Assets that appear in failedTokens were not successfully processed this epoch and are kept in the decommissioning list for retry next epoch. #### Parameters | Name | Type | Description | | ------------ | --------- | ------------------------------------------------------------------- | | failedTokens | address[] | Tokens whose sell or buy execution failed during the current epoch. | ### addWhitelistedManager ```solidity function addWhitelistedManager(address manager) external ``` Adds a manager to the whitelist _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | ------- | ------- | --------------------------------------- | | manager | address | The address of the manager to whitelist | ### removeWhitelistedManager ```solidity function removeWhitelistedManager(address manager) external ``` Removes a manager from the whitelist _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | ------- | ------- | --------------------------------------------------- | | manager | address | The address of the manager to remove from whitelist | ### isWhitelistedManager ```solidity function isWhitelistedManager(address manager) external view returns (bool) ``` Checks if a manager is whitelisted #### Parameters | Name | Type | Description | | ------- | ------- | ----------------------------------- | | manager | address | The address of the manager to check | #### Return Values | Name | Type | Description | | ---- | ---- | --------------------------------------------------- | | [0] | bool | True if the manager is whitelisted, false otherwise | ### getAllOrionManagers ```solidity function getAllOrionManagers() external view returns (address[]) ``` Returns all Orion manager addresses #### Return Values | Name | Type | Description | | ---- | --------- | ----------------------------------- | | [0] | address[] | An array of Orion manager addresses | ### addOrionVault ```solidity function addOrionVault(address vault, enum EventsLib.VaultType vaultType) external ``` Adds a new Orion vault to the protocol registry _Only callable by the vault factories contracts_ #### Parameters | Name | Type | Description | | --------- | ------------------------ | ----------------------------------------------- | | vault | address | The address of the vault to add to the registry | | vaultType | enum EventsLib.VaultType | Whether the vault is encrypted or transparent | ### removeOrionVault ```solidity function removeOrionVault(address vault) external ``` Deregisters an Orion vault from the protocol's registry _Callable by the contract owner or by the vault's manager. This action does not destroy the vault itself; it merely disconnects the vault from the protocol, which causes the share price to stale and renders strategist intents inactive. The vault remains in both active and decommissioning states, allowing orchestrator to process it one last time to liquidate all positions before final removal._ #### Parameters | Name | Type | Description | | ----- | ------- | -------------------------------------------------------- | | vault | address | The address of the vault to be removed from the registry | ### getAllOrionVaults ```solidity function getAllOrionVaults(enum EventsLib.VaultType vaultType) external view returns (address[]) ``` Returns all Orion vault addresses #### Parameters | Name | Type | Description | | --------- | ------------------------ | ------------------------------------------------- | | vaultType | enum EventsLib.VaultType | Whether to return encrypted or transparent vaults | #### Return Values | Name | Type | Description | | ---- | --------- | --------------------------------- | | [0] | address[] | An array of Orion vault addresses | ### isOrionVault ```solidity function isOrionVault(address vault) external view returns (bool) ``` Checks if an address is a registered Orion vault _This function checks both encrypted and transparent vaults_ #### Parameters | Name | Type | Description | | ----- | ------- | --------------------------------- | | vault | address | The address of the vault to check | #### Return Values | Name | Type | Description | | ---- | ---- | ---------------------------------------------------------------- | | [0] | bool | True if the address is a registered Orion vault, false otherwise | ### isEncryptedVault ```solidity function isEncryptedVault(address vault) external view returns (bool) ``` Checks if an address is a registered encrypted Orion vault #### Parameters | Name | Type | Description | | ----- | ------- | --------------------------------- | | vault | address | The address of the vault to check | #### Return Values | Name | Type | Description | | ---- | ---- | ---------------------------------------------------------------- | | [0] | bool | True if the address is an encrypted Orion vault, false otherwise | ### isDecommissioningVault ```solidity function isDecommissioningVault(address vault) external view returns (bool) ``` Checks if an address is a decommissioning Orion vault #### Parameters | Name | Type | Description | | ----- | ------- | --------------------------------- | | vault | address | The address of the vault to check | #### Return Values | Name | Type | Description | | ---- | ---- | --------------------------------------------------------------------- | | [0] | bool | True if the address is a decommissioning Orion vault, false otherwise | ### isDecommissionedVault ```solidity function isDecommissionedVault(address vault) external view returns (bool) ``` Checks if an address is a decommissioned Orion vault #### Parameters | Name | Type | Description | | ----- | ------- | --------------------------------- | | vault | address | The address of the vault to check | #### Return Values | Name | Type | Description | | ---- | ---- | -------------------------------------------------------------------- | | [0] | bool | True if the address is a decommissioned Orion vault, false otherwise | ### getAllDecommissionedVaults ```solidity function getAllDecommissionedVaults() external view returns (address[]) ``` Returns all decommissioned Orion vault addresses #### Return Values | Name | Type | Description | | ---- | --------- | ------------------------------------------ | | [0] | address[] | An array of decommissioned vault addresses | ### completeVaultDecommissioning ```solidity function completeVaultDecommissioning(address vault) external ``` Completes the decommissioning process for a vault _This function removes the vault from the active vault lists and moves it to decommissioned vaults Only callable by the liquidity orchestrator after vault liquidation is complete_ #### Parameters | Name | Type | Description | | ----- | ------- | -------------------------------------------------------- | | vault | address | The address of the vault to complete decommissioning for | ### isSystemIdle ```solidity function isSystemIdle() external view returns (bool) ``` Checks if the system is idle _This function checks if both the liquidity orchestrator and the internal state orchestrator are idle_ #### Return Values | Name | Type | Description | | ---- | ---- | ------------------------------------------- | | [0] | bool | True if the system is idle, false otherwise | ### tokenDecimals ```solidity function tokenDecimals(address token) external view returns (uint8) ``` Returns the stored decimals for a whitelisted token #### Parameters | Name | Type | Description | | ----- | ------- | ----------------- | | token | address | The token address | #### Return Values | Name | Type | Description | | ---- | ----- | ------------------------------------ | | [0] | uint8 | The number of decimals for the token | ### getTokenDecimals ```solidity function getTokenDecimals(address token) external view returns (uint8) ``` Returns the stored decimals for a whitelisted token _Alias of `tokenDecimals` for backward-compatible ABI._ #### Parameters | Name | Type | Description | | ----- | ------- | ----------------- | | token | address | The token address | #### Return Values | Name | Type | Description | | ---- | ----- | ------------------------------------ | | [0] | uint8 | The number of decimals for the token | ### minDepositAmount ```solidity function minDepositAmount() external view returns (uint256) ``` Returns the minimum deposit amount #### Return Values | Name | Type | Description | | ---- | ------- | ---------------------------------------------------- | | [0] | uint256 | The minimum deposit amount in underlying asset units | ### minRedeemAmount ```solidity function minRedeemAmount() external view returns (uint256) ``` Returns the minimum redeem amount #### Return Values | Name | Type | Description | | ---- | ------- | ---------------------------------------- | | [0] | uint256 | The minimum redeem amount in share units | ### setMinDepositAmount ```solidity function setMinDepositAmount(uint256 amount) external ``` Sets the minimum deposit amount _Can be called by the contract owner or guardian_ #### Parameters | Name | Type | Description | | ------ | ------- | -------------------------------------------------------- | | amount | uint256 | The new minimum deposit amount in underlying asset units | ### setMinRedeemAmount ```solidity function setMinRedeemAmount(uint256 amount) external ``` Sets the minimum redeem amount _Can be called by the contract owner or guardian_ #### Parameters | Name | Type | Description | | ------ | ------- | -------------------------------------------- | | amount | uint256 | The new minimum redeem amount in share units | ### feeChangeCooldownDuration ```solidity function feeChangeCooldownDuration() external view returns (uint256) ``` Returns the fee change cooldown duration #### Return Values | Name | Type | Description | | ---- | ------- | -------------------------------- | | [0] | uint256 | The cooldown duration in seconds | ### setFeeChangeCooldownDuration ```solidity function setFeeChangeCooldownDuration(uint256 duration) external ``` Sets the fee change cooldown duration _Can only be called by the contract owner_ #### Parameters | Name | Type | Description | | -------- | ------- | ------------------------------------ | | duration | uint256 | The new cooldown duration in seconds | ### maxFulfillBatchSize ```solidity function maxFulfillBatchSize() external view returns (uint256) ``` Returns the maximum fulfill batch size #### Return Values | Name | Type | Description | | ---- | ------- | ------------------------------ | | [0] | uint256 | The maximum fulfill batch size | ### setMaxFulfillBatchSize ```solidity function setMaxFulfillBatchSize(uint256 size) external ``` Sets the maximum fulfill batch size _Can be called by the contract owner or guardian_ #### Parameters | Name | Type | Description | | ---- | ------- | ---------------------------------- | | size | uint256 | The new maximum fulfill batch size | --- # IOrionEncryptedVault > Interface for Orion confidential vaults ### submitIntent ```solidity function submitIntent(bytes intentCiphertext) external ``` Submit an encrypted portfolio intent #### Parameters | Name | Type | Description | | ---------------- | ----- | ------------------------ | | intentCiphertext | bytes | Opaque intent ciphertext | ### getPortfolio ```solidity function getPortfolio() external view returns (bytes portfolioCiphertext) ``` Returns the stored portfolio ciphertext #### Return Values | Name | Type | Description | | ------------------- | ----- | ---------------- | | portfolioCiphertext | bytes | Opaque portfolio | ### getIntent ```solidity function getIntent() external view returns (bytes intentCiphertext) ``` Returns the stored intent ciphertext #### Return Values | Name | Type | Description | | ---------------- | ----- | ------------- | | intentCiphertext | bytes | Opaque intent | ### updateVaultState ```solidity function updateVaultState(bytes portfolioCiphertext, uint256 newTotalAssets) external ``` Updates the vault's encrypted portfolio and total assets _Can only be called by the liquidity orchestrator._ #### Parameters | Name | Type | Description | | ------------------- | ------- | ---------------------------------------- | | portfolioCiphertext | bytes | Opaque portfolio | | newTotalAssets | uint256 | The new total assets value for the vault | ### maxCiphertextLength ```solidity function maxCiphertextLength() external view returns (uint256) ``` Maximum accepted ciphertext length for the current investment universe #### Return Values | Name | Type | Description | | ---- | ------- | ---------------- | | [0] | uint256 | Max blob length. | --- # IOrionStrategist > Interface for smart contract strategists that compute portfolio intents on-demand. _Implementors must support ERC-165 so that vaults can detect and auto-link them on assignment._ ### setVault ```solidity function setVault(address vault_) external ``` Link this strategist to a vault. Can only be called once per deployment. #### Parameters | Name | Type | Description | | ------ | ------- | --------------------------------------------- | | vault_ | address | The vault address to link to this strategist. | ### submitIntent ```solidity function submitIntent() external ``` Compute the current portfolio intent from onchain state and submit it to the linked vault. _Permissioned access is strongly recommended for security._ --- # IOrionTransparentVault > Interface for the Orion transparent vault ### IntentPosition _Struct representing a token and its weight in an intent._ #### Parameters | Name | Type | Description | | ---- | ---- | ----------- | ```solidity struct IntentPosition { address token; uint32 weight; } ``` ### submitIntent ```solidity function submitIntent(struct IOrionTransparentVault.IntentPosition[] intent) external ``` Submit a plaintext portfolio intent. #### Parameters | Name | Type | Description | | ------ | ---------------------------------------------- | ------------------------------------------------------------------------- | | intent | struct IOrionTransparentVault.IntentPosition[] | IntentPosition structs array containing the tokens and plaintext weights. | ### getPortfolio ```solidity function getPortfolio() external view returns (address[] tokens, uint256[] sharesPerAsset) ``` Get the transparent portfolio. #### Return Values | Name | Type | Description | | -------------- | --------- | -------------------------------------- | | tokens | address[] | The tokens in the portfolio. | | sharesPerAsset | uint256[] | The shares per asset in the portfolio. | ### getIntent ```solidity function getIntent() external view returns (address[] tokens, uint32[] weights) ``` Get the transparent intent. #### Return Values | Name | Type | Description | | ------- | --------- | -------------------------- | | tokens | address[] | The tokens in the intent. | | weights | uint32[] | The weights in the intent. | ### updateVaultState ```solidity function updateVaultState(address[] tokens, uint256[] shares, uint256 newTotalAssets) external ``` Updates the vault's portfolio state and total assets _Can only be called by the liquidity orchestrator. Clears the previous portfolio and replaces it with the new one. Updates the high watermark if the current share price exceeds it. The system maintains a single global high watermark shared across all LPs._ #### Parameters | Name | Type | Description | | -------------- | --------- | ---------------------------------------------------- | | tokens | address[] | Array of token addresses in the portfolio | | shares | uint256[] | Array of shares per asset (parallel to tokens array) | | newTotalAssets | uint256 | The new total assets value for the vault | --- # IOrionVault > Interface for Orion vaults ### SynchronousCallDisabled ```solidity error SynchronousCallDisabled() ``` External synchronous calls are disabled in the current context. ### DepositRequest ```solidity event DepositRequest(address sender, uint256 assets) ``` A deposit request has been queued for a beneficiary. #### Parameters | Name | Type | Description | | ------ | ------- | --------------------------------------------------------- | | sender | address | The address credited in the deposit queue and on fulfill. | | assets | uint256 | The amount of assets being deposited. | ### DepositRequestCancelled ```solidity event DepositRequestCancelled(address user, uint256 amount) ``` A deposit request has been cancelled. #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------------------------------------ | | user | address | The address of the user whose deposit request was cancelled. | | amount | uint256 | The amount of assets that were requested for deposit. | ### RedeemRequest ```solidity event RedeemRequest(address sender, uint256 shares) ``` A redemption request has been made by a user. #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------------------------------ | | sender | address | The address of the user making the redemption request. | | shares | uint256 | The number of shares being redeemed. | ### RedeemRequestCancelled ```solidity event RedeemRequestCancelled(address user, uint256 shares) ``` A redemption request has been cancelled. #### Parameters | Name | Type | Description | | ------ | ------- | --------------------------------------------------------------- | | user | address | The address of the user whose redemption request was cancelled. | | shares | uint256 | The number of shares that were requested for redemption. | ### StrategistUpdated ```solidity event StrategistUpdated(address newStrategist) ``` The strategist has been updated. #### Parameters | Name | Type | Description | | ------------- | ------- | --------------------------- | | newStrategist | address | The new strategist address. | ### Redeem ```solidity event Redeem(address user, uint256 redeemAmount, uint256 sharesBurned) ``` A redemption request has been fulfilled. #### Parameters | Name | Type | Description | | ------------ | ------- | ------------------------------------------------------- | | user | address | The address of the user whose redemption was fulfilled. | | redeemAmount | uint256 | The amount of assets redeemed by the user. | | sharesBurned | uint256 | The number of shares burned for the user. | ### RedemptionFailed ```solidity event RedemptionFailed(address user, uint256 amount, uint256 shares) ``` Transfer to the redeemer failed; funds are held in escrow until claimed. #### Parameters | Name | Type | Description | | ------ | ------- | ---------------------------------------------------- | | user | address | The address of the recipient whose transfer failed. | | amount | uint256 | The underlying amount that could not be transferred. | | shares | uint256 | The number of shares that could not be paid out. | ### RedemptionClaimed ```solidity event RedemptionClaimed(address user, uint256 amount) ``` A previously failed redemption transfer has been claimed. #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------ | | user | address | The address of the claimer. | | amount | uint256 | The underlying amount claimed. | ### VaultFeesAccrued ```solidity event VaultFeesAccrued(uint256 managementFee, uint256 performanceFee) ``` Fees have been accrued. #### Parameters | Name | Type | Description | | -------------- | ------- | --------------------------------------- | | managementFee | uint256 | The amount of management fees accrued. | | performanceFee | uint256 | The amount of performance fees accrued. | ### VaultFeesClaimed ```solidity event VaultFeesClaimed(address manager, uint256 feeAmount) ``` Fees have been claimed. #### Parameters | Name | Type | Description | | --------- | ------- | ------------------------------------------------ | | manager | address | The address of the manager who claimed the fees. | | feeAmount | uint256 | The amount of fees claimed. | ### DepositAccessControlUpdated ```solidity event DepositAccessControlUpdated(address newDepositAccessControl) ``` The deposit access control contract has been updated. #### Parameters | Name | Type | Description | | ----------------------- | ------- | ------------------------------------------------- | | newDepositAccessControl | address | The new controller (address(0) = permissionless). | ### HolderAccessControlUpdated ```solidity event HolderAccessControlUpdated(address newHolderAccessControl) ``` The holder access control contract has been updated. #### Parameters | Name | Type | Description | | ---------------------- | ------- | ------------------------------------------------- | | newHolderAccessControl | address | The new controller (address(0) = permissionless). | ### TransferAccessControlUpdated ```solidity event TransferAccessControlUpdated(address newTransferAccessControl) ``` The transfer access control contract has been updated. #### Parameters | Name | Type | Description | | ------------------------ | ------- | ------------------------------------------------- | | newTransferAccessControl | address | The new controller (address(0) = permissionless). | ### DepositFulfillmentFailed ```solidity event DepositFulfillmentFailed(address user, uint256 amount) ``` Deposit fulfillment skipped because the user may not hold shares; underlying escrowed. #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------------------------------------- | | user | address | The address whose deposit could not be fulfilled into shares. | | amount | uint256 | The underlying amount escrowed for later claim. | ### FeeType Fee type ```solidity enum FeeType { ABSOLUTE, SOFT_HURDLE, HARD_HURDLE, HIGH_WATER_MARK, HURDLE_HWM } ``` ### FeeModel Fee model _This struct is used to define the fee model for the vault_ ```solidity struct FeeModel { enum IOrionVault.FeeType feeType; uint16 performanceFee; uint16 managementFee; uint256 highWaterMark; } ``` ### config ```solidity function config() external view returns (contract IOrionConfig) ``` Orion config getter #### Return Values | Name | Type | Description | | ---- | --------------------- | --------------------------------- | | [0] | contract IOrionConfig | The Orion config contract address | ### manager ```solidity function manager() external view returns (address) ``` Manager getter #### Return Values | Name | Type | Description | | ---- | ------- | ------------------- | | [0] | address | The manager address | ### strategist ```solidity function strategist() external view returns (address) ``` Strategist getter #### Return Values | Name | Type | Description | | ---- | ------- | ---------------------- | | [0] | address | The strategist address | ### pendingVaultFees ```solidity function pendingVaultFees() external view returns (uint256) ``` Pending vault fees getter #### Return Values | Name | Type | Description | | ---- | ------- | ------------------------- | | [0] | uint256 | Pending vault fees amount | ### activeFeeModel ```solidity function activeFeeModel() external view returns (struct IOrionVault.FeeModel) ``` Returns the active fee model (old during cooldown, new after) #### Return Values | Name | Type | Description | | ---- | --------------------------- | ------------------------------ | | [0] | struct IOrionVault.FeeModel | The currently active fee model | ### overrideIntentForDecommissioning ```solidity function overrideIntentForDecommissioning() external ``` Override intent to 100% underlying asset for decommissioning _Can only be called by the OrionConfig contract_ ### requestDeposit ```solidity function requestDeposit(uint256 assets) external ``` Submit an asynchronous deposit request. _No share tokens are minted immediately. The specified amount of underlying tokens is transferred to the liquidity orchestrator for centralized liquidity management._ #### Parameters | Name | Type | Description | | ------ | ------- | ---------------------------------------------- | | assets | uint256 | The amount of the underlying asset to deposit. | ### requestDepositFor ```solidity function requestDepositFor(address beneficiary, uint256 assets) external ``` Submit an async deposit request on behalf of `beneficiary`. #### Parameters | Name | Type | Description | | ----------- | ------- | ---------------------------------------------------------------------- | | beneficiary | address | The LP whose pending deposit balance and eventual shares are credited. | | assets | uint256 | The amount of underlying to deposit. | ### cancelDepositRequest ```solidity function cancelDepositRequest(uint256 amount) external ``` Cancel a previously submitted deposit request. _Allows LPs to withdraw their funds before any share tokens are minted. The request must still have enough balance remaining to cover the cancellation. Funds are returned from the liquidity orchestrator to the LP._ #### Parameters | Name | Type | Description | | ------ | ------- | -------------------------------- | | amount | uint256 | The amount of funds to withdraw. | ### requestRedeem ```solidity function requestRedeem(uint256 shares) external ``` Submit a redemption request. _No share tokens are burned immediately. The specified amount of share tokens is transferred to the vault._ #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------------------- | | shares | uint256 | The amount of the share tokens to withdraw. | ### cancelRedeemRequest ```solidity function cancelRedeemRequest(uint256 shares) external ``` Cancel a previously submitted redemption request. _Allows LPs to recover their share tokens before any burning occurs. The request must still have enough shares remaining to cover the cancellation. Share tokens are returned from the vault._ #### Parameters | Name | Type | Description | | ------ | ------- | -------------------------------------- | | shares | uint256 | The amount of share tokens to recover. | ### claimUnderlying ```solidity function claimUnderlying() external ``` Claim underlying funds from a previously failed redemption transfer or a deposit fulfillment that could not mint shares. _Called by the user after the transfer blocker / eligibility issue has been resolved._ ### updateStrategist ```solidity function updateStrategist(address newStrategist) external ``` Update the strategist address _The strategist is responsible for setting allocation logic for the vault's assets. This function enables managers to update the strategist. Strategist can be a smart contract or an address. It is the FULL responsibility of the manager to ensure the strategist is capable of performing its duties._ #### Parameters | Name | Type | Description | | ------------- | ------- | --------------------------- | | newStrategist | address | The new strategist address. | ### updateFeeModel ```solidity function updateFeeModel(uint8 mode, uint16 performanceFee, uint16 managementFee) external ``` Update the fee model parameters #### Parameters | Name | Type | Description | | -------------- | ------ | ----------------------------- | | mode | uint8 | The calculation mode for fees | | performanceFee | uint16 | The performance fee | | managementFee | uint16 | The management fee | ### claimVaultFees ```solidity function claimVaultFees(uint256 amount) external ``` Claim accrued vault fees #### Parameters | Name | Type | Description | | ------ | ------- | --------------------------------- | | amount | uint256 | The amount of vault fees to claim | ### setDepositAccessControl ```solidity function setDepositAccessControl(address newDepositAccessControl) external ``` Set deposit access control contract _Only callable by vault manager. Non-zero addresses must ERC-165 as IOrionDepositAccessControl._ #### Parameters | Name | Type | Description | | ----------------------- | ------- | ------------------------------------------------------------------------ | | newDepositAccessControl | address | Address of the new access control contract (address(0) = permissionless) | ### setHolderAccessControl ```solidity function setHolderAccessControl(address newHolderAccessControl) external ``` Set holder access control contract _Only callable by vault manager. Non-zero addresses must ERC-165 as IOrionHolderAccessControl._ #### Parameters | Name | Type | Description | | ---------------------- | ------- | ------------------------------------------------------------------------ | | newHolderAccessControl | address | Address of the new access control contract (address(0) = permissionless) | ### setTransferAccessControl ```solidity function setTransferAccessControl(address newTransferAccessControl) external ``` Set transfer access control contract _Only callable by vault manager. Non-zero addresses must ERC-165 as IOrionTransferAccessControl._ #### Parameters | Name | Type | Description | | ------------------------ | ------- | ------------------------------------------------------------------------ | | newTransferAccessControl | address | Address of the new access control contract (address(0) = permissionless) | ### pendingDeposit ```solidity function pendingDeposit(uint256 fulfillBatchSize) external view returns (uint256) ``` Get total pending deposit amount across all users _This returns asset amounts, not share amounts_ #### Parameters | Name | Type | Description | | ---------------- | ------- | ---------------------------------------------------------- | | fulfillBatchSize | uint256 | The maximum number of requests to process per fulfill call | #### Return Values | Name | Type | Description | | ---- | ------- | ------------------------------------------------------------------------------ | | [0] | uint256 | Total pending deposits denominated in underlying asset units (e.g., USDC, ETH) | ### pendingRedeem ```solidity function pendingRedeem(uint256 fulfillBatchSize) external view returns (uint256) ``` Get total pending redemption shares across all users _This returns share amounts, not underlying asset amounts_ #### Parameters | Name | Type | Description | | ---------------- | ------- | ---------------------------------------------------------- | | fulfillBatchSize | uint256 | The maximum number of requests to process per fulfill call | #### Return Values | Name | Type | Description | | ---- | ------- | ---------------------------------------------------------- | | [0] | uint256 | Total pending redemptions denominated in vault share units | ### pendingDepositCount ```solidity function pendingDepositCount() external view returns (uint256) ``` Get the number of pending deposit queue entries. #### Return Values | Name | Type | Description | | ---- | ------- | ------------------------------------------------------------------ | | [0] | uint256 | The number of unique users with non-zero pending deposit requests. | ### pendingRedeemCount ```solidity function pendingRedeemCount() external view returns (uint256) ``` Get the number of pending redeem queue entries. #### Return Values | Name | Type | Description | | ---- | ------- | ----------------------------------------------------------------- | | [0] | uint256 | The number of unique users with non-zero pending redeem requests. | ### pendingRedeemBatch ```solidity function pendingRedeemBatch(uint256 fulfillBatchSize) external view returns (address[] users, uint256[] shares) ``` Get the list of pending redeem entries (users and shares) for the next fulfill batch _This function enables per-request conversion, ensuring exact rounding behaviour for state transition._ #### Parameters | Name | Type | Description | | ---------------- | ------- | ------------------------------------------ | | fulfillBatchSize | uint256 | The maximum number of requests to consider | #### Return Values | Name | Type | Description | | ------ | --------- | ----------------------------------------------------- | | users | address[] | Addresses with pending redeem requests in batch order | | shares | uint256[] | Share amounts per user (same index as users) | ### totalPendingUnderlyingClaims ```solidity function totalPendingUnderlyingClaims() external view returns (uint256 total) ``` Total underlying assets owed to users whose redemption transfer failed #### Return Values | Name | Type | Description | | ----- | ------- | ----------------------------------------------------- | | total | uint256 | Sum of all pending underlying claims across all users | ### pendingUnderlyingClaim ```solidity function pendingUnderlyingClaim(address account) external view returns (uint256 amount) ``` Underlying escrowed for `account` from a failed redemption payout or deposit fulfillment. #### Parameters | Name | Type | Description | | ------- | ------- | --------------------- | | account | address | The address to query. | #### Return Values | Name | Type | Description | | ------ | ------- | ------------------------------------------------------------- | | amount | uint256 | Underlying asset units held in vault escrow for this account. | ### fulfillDeposit ```solidity function fulfillDeposit(uint256 depositTotalAssets) external ``` Process all pending deposit requests and mint shares to depositors #### Parameters | Name | Type | Description | | ------------------ | ------- | ----------------------------------------------------- | | depositTotalAssets | uint256 | The total assets associated with the deposit requests | ### fulfillRedeem ```solidity function fulfillRedeem(uint256 redeemTotalAssets) external ``` Process all pending redemption requests and burn shares from redeemers #### Parameters | Name | Type | Description | | ----------------- | ------- | -------------------------------------------------------- | | redeemTotalAssets | uint256 | The total assets associated with the redemption requests | ### accrueVaultFees ```solidity function accrueVaultFees(uint256 managementFee, uint256 performanceFee) external ``` Accrue vault fees for a specific epoch #### Parameters | Name | Type | Description | | -------------- | ------- | ------------------------------------------------------------------ | | managementFee | uint256 | The amount of management fees to accrue in underlying asset units | | performanceFee | uint256 | The amount of performance fees to accrue in underlying asset units | --- # IPriceAdapter > Interface for price adapters ### getPriceData ```solidity function getPriceData(address asset) external view returns (uint256 price, uint8 decimals) ``` Get the price data for an asset _The asset shall be whitelisted in the OrionConfig contract. The registry will handle normalization to priceAdapterDecimals._ #### Parameters | Name | Type | Description | | ----- | ------- | --------------------------------------------- | | asset | address | The address of the asset to get the price for | #### Return Values | Name | Type | Description | | -------- | ------- | --------------------------------------------- | | price | uint256 | The raw price of the asset | | decimals | uint8 | The number of decimals for the returned price | ### validatePriceAdapter ```solidity function validatePriceAdapter(address asset) external view ``` Validates that the given asset is compatible with this adapter _Reverts with InvalidAdapter if the asset is not compatible_ #### Parameters | Name | Type | Description | | ----- | ------- | ------------------------------------ | | asset | address | The address of the asset to validate | --- # IPriceAdapterRegistry > Interface for the price adapter registry ### setPriceAdapter ```solidity function setPriceAdapter(address asset, contract IPriceAdapter adapter) external ``` Register or replace the price adapter for an asset. #### Parameters | Name | Type | Description | | ------- | ---------------------- | -------------------------------- | | asset | address | The address of the asset. | | adapter | contract IPriceAdapter | The price adapter for the asset. | ### getPrice ```solidity function getPrice(address asset) external view returns (uint256) ``` Returns the price of the given asset via its assigned price adapter. _The asset shall be whitelisted in the OrionConfig contract, therefore assigned an adapter in `adapterOf`. Returned value is always expected to have priceAdapterDecimals decimals._ #### Parameters | Name | Type | Description | | ----- | ------- | ------------------------- | | asset | address | The address of the asset. | #### Return Values | Name | Type | Description | | ---- | ------- | -------------------------------------------------------------------- | | [0] | uint256 | The price of the asset, normalized to priceAdapterDecimals decimals. | --- # ISP1Verifier > This contract is the interface for the SP1 Verifier. ### verifyProof ```solidity function verifyProof(bytes32 programVKey, bytes publicValues, bytes proofBytes) external view ``` Verifies a proof with given public values and vkey. _It is expected that the first 4 bytes of proofBytes must match the first 4 bytes of target verifier's VERIFIER_HASH._ #### Parameters | Name | Type | Description | | ------------ | ------- | ----------------------------------------------------------------- | | programVKey | bytes32 | The verification key for the RISC-V program. | | publicValues | bytes | The public values encoded as bytes. | | proofBytes | bytes | The proof of the program execution the SP1 zkVM encoded as bytes. | ## ISP1VerifierWithHash This interface is the interface for the SP1 Verifier with a hash. ### VERIFIER_HASH ```solidity function VERIFIER_HASH() external pure returns (bytes32) ``` Returns the hash of the verifier. --- # ErrorsLib > Centralized library for reusable custom errors across the protocol. ### NotAuthorized ```solidity error NotAuthorized() ``` Caller is not authorized to perform the requested action. ### ZeroAddress ```solidity error ZeroAddress() ``` Address parameter is the zero address. ### AlreadyRegistered ```solidity error AlreadyRegistered() ``` Address or token is already registered or whitelisted. ### InvalidAddress ```solidity error InvalidAddress() ``` Provided address is invalid for the specified context. ### TokenNotWhitelisted ```solidity error TokenNotWhitelisted(address token) ``` Token is not whitelisted for the requested operation. #### Parameters | Name | Type | Description | | ----- | ------- | ------------------------------------------ | | token | address | The token address that is not whitelisted. | ### AmountMustBeGreaterThanZero ```solidity error AmountMustBeGreaterThanZero(address asset) ``` The amount specified must be greater than zero. #### Parameters | Name | Type | Description | | ----- | ------- | --------------------------------------------- | | asset | address | The asset address associated with the amount. | ### InvalidTotalWeight ```solidity error InvalidTotalWeight() ``` The total weight assigned to assets or allocations is invalid. ### OrderIntentCannotBeEmpty ```solidity error OrderIntentCannotBeEmpty() ``` The order intent list is empty and must contain at least one entry. ### TokenAlreadyInOrder ```solidity error TokenAlreadyInOrder(address token) ``` Token has already been added to the order intent list. #### Parameters | Name | Type | Description | | ----- | ------- | ---------------------------- | | token | address | The duplicate token address. | ### InsufficientAmount ```solidity error InsufficientAmount() ``` Insufficient amount to complete the operation. ### AdapterNotSet ```solidity error AdapterNotSet() ``` Expected adapter address is not set. ### PriceMustBeGreaterThanZero ```solidity error PriceMustBeGreaterThanZero(address asset) ``` Price returned by the adapter must be greater than zero. #### Parameters | Name | Type | Description | | ----- | ------- | --------------------------------------------------- | | asset | address | The asset address that has a zero or invalid price. | ### InvalidUnderlyingDecimals ```solidity error InvalidUnderlyingDecimals() ``` The underlying asset has an unsupported or invalid number of decimals. ### InvalidArguments ```solidity error InvalidArguments() ``` One or more function arguments are invalid. ### InvalidAdapter ```solidity error InvalidAdapter(address asset) ``` The adapter is not compatible with the asset. #### Parameters | Name | Type | Description | | ----- | ------- | ---------------------------------------------------------- | | asset | address | The asset address that is not compatible with the adapter. | ### SystemNotIdle ```solidity error SystemNotIdle() ``` Operation cannot be performed because the system is not idle. ### VaultDecommissioned ```solidity error VaultDecommissioned() ``` Vault is decommissioned and cannot accept new requests. ### BelowMinimumDeposit ```solidity error BelowMinimumDeposit(uint256 amount, uint256 minimum) ``` The deposit amount is below the minimum required amount. #### Parameters | Name | Type | Description | | ------- | ------- | ----------------------------- | | amount | uint256 | The amount that was provided. | | minimum | uint256 | The minimum amount required. | ### BelowMinimumRedeem ```solidity error BelowMinimumRedeem(uint256 amount, uint256 minimum) ``` The redeem amount is below the minimum required amount. #### Parameters | Name | Type | Description | | ------- | ------- | ----------------------------- | | amount | uint256 | The amount that was provided. | | minimum | uint256 | The minimum amount required. | ### DepositNotAllowed ```solidity error DepositNotAllowed() ``` Deposit not allowed due to access control restrictions. ### ShareHoldNotAllowed ```solidity error ShareHoldNotAllowed() ``` Holding shares is not allowed due to access control restrictions. ### ShareTransferNotAllowed ```solidity error ShareTransferNotAllowed() ``` Share transfer not allowed due to access control restrictions. ### SlippageExceeded ```solidity error SlippageExceeded(address asset, uint256 actual, uint256 expected) ``` Slippage exceeds the configured tolerance. #### Parameters | Name | Type | Description | | -------- | ------- | ---------------------------------------------- | | asset | address | The asset address where slippage was detected. | | actual | uint256 | The actual value observed. | | expected | uint256 | The expected value. | ### StalePrice ```solidity error StalePrice(address asset) ``` Price data from oracle is stale or outdated. #### Parameters | Name | Type | Description | | ----- | ------- | ------------------------------------ | | asset | address | The asset whose price feed is stale. | ### InvalidPrice ```solidity error InvalidPrice(address asset, int256 price) ``` Price returned from oracle is invalid (zero, negative, or uninitialized). #### Parameters | Name | Type | Description | | ----- | ------- | --------------------------------- | | asset | address | The asset whose price is invalid. | | price | int256 | The invalid price value returned. | ### PriceOutOfBounds ```solidity error PriceOutOfBounds(address asset, uint256 price, uint256 min, uint256 max) ``` Price is outside acceptable bounds. #### Parameters | Name | Type | Description | | ----- | ------- | --------------------------------------- | | asset | address | The asset whose price is out of bounds. | | price | uint256 | The price that exceeded bounds. | | min | uint256 | The minimum acceptable price. | | max | uint256 | The maximum acceptable price. | ### CommitmentMismatch ```solidity error CommitmentMismatch(bytes32 proofCommitment, bytes32 onchainCommitment) ``` Thrown when the zk proof's commitment doesn't match the onchain commitment. #### Parameters | Name | Type | Description | | ----------------- | ------- | --------------------------------- | | proofCommitment | bytes32 | The commitment from the zk proof. | | onchainCommitment | bytes32 | The commitment from the onchain. | ### StrategistVaultAlreadyLinked ```solidity error StrategistVaultAlreadyLinked() ``` Strategist is already linked to a vault and cannot be re-linked. --- # EventsLib > Centralized library of events emitted throughout the Orion protocol. ### WhitelistedAssetAdded ```solidity event WhitelistedAssetAdded(address asset) ``` A new asset has been whitelisted for protocol usage. #### Parameters | Name | Type | Description | | ----- | ------- | ------------------------------------- | | asset | address | The address of the whitelisted asset. | ### WhitelistedAssetRemoved ```solidity event WhitelistedAssetRemoved(address asset) ``` An asset has been removed from the whitelist. #### Parameters | Name | Type | Description | | ----- | ------- | --------------------------------- | | asset | address | The address of the removed asset. | ### AssetDecommissioningInitiated ```solidity event AssetDecommissioningInitiated(address asset) ``` Asset marked for decommissioning (stays whitelisted until completeAssetRemoval). #### Parameters | Name | Type | Description | | ----- | ------- | ---------------------------------------------------- | | asset | address | The address of the asset marked for decommissioning. | ### OrionVaultAdded ```solidity event OrionVaultAdded(address vault) ``` A new Orion Vault has been registered in the protocol. #### Parameters | Name | Type | Description | | ----- | ------- | ------------------------------- | | vault | address | The address of the added vault. | ### RiskFreeRateUpdated ```solidity event RiskFreeRateUpdated(uint16 riskFreeRate) ``` The risk-free rate has been updated. #### Parameters | Name | Type | Description | | ------------ | ------ | --------------------------------------- | | riskFreeRate | uint16 | The new risk-free rate in basis points. | ### MinDepositAmountUpdated ```solidity event MinDepositAmountUpdated(uint256 minDepositAmount) ``` The minimum deposit amount has been updated. #### Parameters | Name | Type | Description | | ---------------- | ------- | ------------------------------- | | minDepositAmount | uint256 | The new minimum deposit amount. | ### MinRedeemAmountUpdated ```solidity event MinRedeemAmountUpdated(uint256 minRedeemAmount) ``` The minimum redeem amount has been updated. #### Parameters | Name | Type | Description | | --------------- | ------- | ------------------------------ | | minRedeemAmount | uint256 | The new minimum redeem amount. | ### FeeChangeCooldownDurationUpdated ```solidity event FeeChangeCooldownDurationUpdated(uint256 newCooldownDuration) ``` The fee change cooldown duration has been updated. #### Parameters | Name | Type | Description | | ------------------- | ------- | ------------------------------------- | | newCooldownDuration | uint256 | The new cooldown duration in seconds. | ### MaxFulfillBatchSizeUpdated ```solidity event MaxFulfillBatchSizeUpdated(uint256 maxFulfillBatchSize) ``` The maximum fulfill batch size has been updated. #### Parameters | Name | Type | Description | | ------------------- | ------- | ----------------------------------- | | maxFulfillBatchSize | uint256 | The new maximum fulfill batch size. | ### VaultFeeChangeScheduled ```solidity event VaultFeeChangeScheduled(uint8 feeType, uint16 performanceFee, uint16 managementFee, uint256 newFeeRatesTimestamp) ``` A vault fee model change has been scheduled. #### Parameters | Name | Type | Description | | -------------------- | ------- | ------------------------------------------------------ | | feeType | uint8 | The new fee type. | | performanceFee | uint16 | The new performance fee. | | managementFee | uint16 | The new management fee. | | newFeeRatesTimestamp | uint256 | The timestamp when the new fee rates become effective. | ### ProtocolFeeChangeScheduled ```solidity event ProtocolFeeChangeScheduled(uint16 nettingFeeCoefficient, uint16 rsFeeCoefficient, uint256 newProtocolFeeRatesTimestamp) ``` A protocol fee change has been scheduled. #### Parameters | Name | Type | Description | | ---------------------------- | ------- | ----------------------------------------------------------------- | | nettingFeeCoefficient | uint16 | The new netting fee coefficient (bps of netted rebalance volume). | | rsFeeCoefficient | uint16 | The new revenue share fee coefficient. | | newProtocolFeeRatesTimestamp | uint256 | The timestamp when the new protocol fee rates become effective. | ### GuardianUpdated ```solidity event GuardianUpdated(address guardian) ``` The guardian address has been updated. #### Parameters | Name | Type | Description | | -------- | ------- | ------------------------- | | guardian | address | The new guardian address. | ### ProtocolPaused ```solidity event ProtocolPaused(address pauser) ``` The protocol has been paused. #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------------- | | pauser | address | The address that triggered the pause. | ### ProtocolUnpaused ```solidity event ProtocolUnpaused(address unpauser) ``` The protocol has been unpaused. #### Parameters | Name | Type | Description | | -------- | ------- | --------------------------------------- | | unpauser | address | The address that triggered the unpause. | ### ManagerAdded ```solidity event ManagerAdded(address manager) ``` A manager has been added to the whitelist. #### Parameters | Name | Type | Description | | ------- | ------- | ------------------------------------------ | | manager | address | The address of the manager that was added. | ### ManagerRemoved ```solidity event ManagerRemoved(address manager) ``` A manager has been removed from the whitelist. #### Parameters | Name | Type | Description | | ------- | ------- | -------------------------------------------- | | manager | address | The address of the manager that was removed. | ### OrderSubmitted ```solidity event OrderSubmitted(address strategist, address[] assets, uint256[] weights) ``` A new order has been submitted. #### Parameters | Name | Type | Description | | ---------- | --------- | --------------------------------------------------------- | | strategist | address | The address of the strategist who submitted the order. | | assets | address[] | Array of token addresses in the order. | | weights | uint256[] | Array of weights in the order (parallel to assets array). | ### VaultStateUpdated ```solidity event VaultStateUpdated(uint256 newTotalAssets, uint256 totalSupply, uint256 currentSharePrice, uint256 highWaterMark, address[] tokens, uint256[] shares) ``` The vault's state has been updated with complete portfolio information. #### Parameters | Name | Type | Description | | ----------------- | --------- | ----------------------------------------------------- | | newTotalAssets | uint256 | The new total assets value for the vault. | | totalSupply | uint256 | The total supply of the vault. | | currentSharePrice | uint256 | The current share price of the vault. | | highWaterMark | uint256 | The new high watermark value for the vault. | | tokens | address[] | Array of token addresses in the portfolio. | | shares | uint256[] | Array of shares per asset (parallel to tokens array). | ### ConfidentialOrderSubmitted ```solidity event ConfidentialOrderSubmitted(address strategist) ``` A confidential intent ciphertext was submitted. #### Parameters | Name | Type | Description | | ---------- | ------- | ---------------------------------------- | | strategist | address | The strategist who submitted the intent. | ### ConfidentialVaultStateUpdated ```solidity event ConfidentialVaultStateUpdated(uint256 newTotalAssets, uint256 totalSupply, uint256 currentSharePrice, uint256 highWaterMark) ``` The vault's state has been updated without portfolio information. #### Parameters | Name | Type | Description | | ----------------- | ------- | ------------------------------------------- | | newTotalAssets | uint256 | The new total assets value for the vault. | | totalSupply | uint256 | The total supply of the vault. | | currentSharePrice | uint256 | The current share price of the vault. | | highWaterMark | uint256 | The new high watermark value for the vault. | ### AutomationRegistryUpdated ```solidity event AutomationRegistryUpdated(address newAutomationRegistry) ``` The automation registry address has been updated. #### Parameters | Name | Type | Description | | --------------------- | ------- | ------------------------------------------- | | newAutomationRegistry | address | The address of the new automation registry. | ### SP1VerifierUpdated ```solidity event SP1VerifierUpdated(address newVerifier) ``` The SP1 verifier contract address has been updated. #### Parameters | Name | Type | Description | | ----------- | ------- | --------------------------------------------- | | newVerifier | address | The address of the new SP1 verifier contract. | ### VKeyUpdated ```solidity event VKeyUpdated(bytes32 vKey) ``` The internal state orchestrator verification key has been updated. #### Parameters | Name | Type | Description | | ---- | ------- | ------------------------- | | vKey | bytes32 | The new verification key. | ### EpochStart ```solidity event EpochStart(uint256 epochCounter, address[] assets, uint256[] prices) ``` A new epoch has started. #### Parameters | Name | Type | Description | | ------------ | --------- | ------------------------------------------------- | | epochCounter | uint256 | The current epoch counter. | | assets | address[] | Array of asset addresses. | | prices | uint256[] | Array of asset prices (parallel to assets array). | ### EpochStateCommitted ```solidity event EpochStateCommitted(uint256 epochCounter, bytes32 epochStateCommitment) ``` The epoch state commitment has been committed. #### Parameters | Name | Type | Description | | -------------------- | ------- | --------------------------- | | epochCounter | uint256 | The current epoch counter. | | epochStateCommitment | bytes32 | The epoch state commitment. | ### EpochProtocolStateHashed ```solidity event EpochProtocolStateHashed(uint256 epochCounter, bytes32 protocolStateHash, uint256 loBalanceUnderlying) ``` Protocol state hash built for this epoch. #### Parameters | Name | Type | Description | | ------------------- | ------- | ------------------------------------ | | epochCounter | uint256 | Current epoch. | | protocolStateHash | bytes32 | Result of `_buildProtocolStateHash`. | | loBalanceUnderlying | uint256 | Mid-tx LO.balanceOf(underlying). | ### EpochEnd ```solidity event EpochEnd(uint256 epochCounter, uint256 nettedRebalanceVolumeUnderlying) ``` The portfolio has been rebalanced. #### Parameters | Name | Type | Description | | ------------------------------- | ------- | ------------------------------------------------------------------------ | | epochCounter | uint256 | The epoch that has just completed. | | nettedRebalanceVolumeUnderlying | uint256 | Zk-reported netted rebalance volume in underlying (from `StatesStruct`). | ### EpochSellExecuted ```solidity event EpochSellExecuted(uint256 epochCounter, address asset, uint256 executionUnderlyingAmount, uint256 sharesAmount, uint256 estimatedUnderlyingAmount) ``` Sell leg executed during upkeep: vault shares swapped to underlying via the execution adapter. #### Parameters | Name | Type | Description | | ------------------------- | ------- | ------------------------------------------------------------------------------------------ | | epochCounter | uint256 | Epoch id at execution time (`EpochEnd` increments after the batch that uses this counter). | | asset | address | asset shares sold through the adapter. | | executionUnderlyingAmount | uint256 | Underlying actually received (`adapter.sell` return). | | sharesAmount | uint256 | Share tokens sold into the adapter. | | estimatedUnderlyingAmount | uint256 | Upkeep estimate before routing to the adapter. | ### EpochBuyExecuted ```solidity event EpochBuyExecuted(uint256 epochCounter, address asset, uint256 executionUnderlyingAmount, uint256 sharesAmount, uint256 estimatedUnderlyingAmount) ``` Buy leg executed during upkeep: underlying spent for vault shares via the execution adapter. #### Parameters | Name | Type | Description | | ------------------------- | ------- | ------------------------------------------------------------------------------------------ | | epochCounter | uint256 | Epoch id at execution time (`EpochEnd` increments after the batch that uses this counter). | | asset | address | asset shares purchased from the adapter. | | executionUnderlyingAmount | uint256 | Underlying actually spent (`adapter.buy` return). | | sharesAmount | uint256 | Share tokens acquired from the adapter. | | estimatedUnderlyingAmount | uint256 | Upkeep estimate before routing to the adapter. | ### PriceAdapterSet ```solidity event PriceAdapterSet(address asset, address adapter) ``` A price adapter has been set for an asset. #### Parameters | Name | Type | Description | | ------- | ------- | --------------------------------- | | asset | address | The address of the asset. | | adapter | address | The address of the price adapter. | ### ExecutionAdapterSet ```solidity event ExecutionAdapterSet(address asset, address adapter) ``` An execution adapter has been set for an asset. #### Parameters | Name | Type | Description | | ------- | ------- | ------------------------------------- | | asset | address | The address of the asset. | | adapter | address | The address of the execution adapter. | ### ProtocolFeesAccrued ```solidity event ProtocolFeesAccrued(uint256 epochProtocolFees) ``` Protocol fees have been accrued. #### Parameters | Name | Type | Description | | ----------------- | ------- | ---------------------------------------------------------- | | epochProtocolFees | uint256 | The amount of protocol fees accrued for the current epoch. | ### ProtocolFeesClaimed ```solidity event ProtocolFeesClaimed(uint256 amount) ``` Protocol fees have been claimed. #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------------ | | amount | uint256 | The amount of protocol fees claimed. | ### LiquidityDeposited ```solidity event LiquidityDeposited(address depositor, uint256 amount) ``` Liquidity has been deposited to the protocol buffer. #### Parameters | Name | Type | Description | | --------- | ------- | ---------------------------------- | | depositor | address | The address of the depositor. | | amount | uint256 | The amount of liquidity deposited. | ### LiquidityWithdrawn ```solidity event LiquidityWithdrawn(address withdrawer, uint256 amount) ``` Liquidity has been withdrawn from the protocol buffer. #### Parameters | Name | Type | Description | | ---------- | ------- | ---------------------------------- | | withdrawer | address | The address of the withdrawer. | | amount | uint256 | The amount of liquidity withdrawn. | ### VaultType Enumeration of available vault types. ```solidity enum VaultType { Transparent, Encrypted } ``` ### OrionVaultCreated ```solidity event OrionVaultCreated(address vault, address manager, address strategist, string name, string symbol, uint8 feeType, uint16 performanceFee, uint16 managementFee, address depositAccessControl, address holderAccessControl, address transferAccessControl, enum EventsLib.VaultType vaultType) ``` A new Orion Vault has been created. #### Parameters | Name | Type | Description | | --------------------- | ------------------------ | ---------------------------------------------------------------------------------- | | vault | address | The address of the newly created vault. | | manager | address | The address of the vault's manager. | | strategist | address | The address of the vault's strategist. | | name | string | The name of the vault. | | symbol | string | The symbol of the vault. | | feeType | uint8 | The fee type of the vault. | | performanceFee | uint16 | The performance fee of the vault. | | managementFee | uint16 | The management fee of the vault. | | depositAccessControl | address | The address of the deposit access control contract (address(0) = permissionless). | | holderAccessControl | address | The address of the holder access control contract (address(0) = permissionless). | | transferAccessControl | address | The address of the transfer access control contract (address(0) = permissionless). | | vaultType | enum EventsLib.VaultType | The type of vault that was created (Transparent or Encrypted). | ### VaultDecommissioningInitiated ```solidity event VaultDecommissioningInitiated(address vault) ``` Decommissioning process for a vault has been initiated. #### Parameters | Name | Type | Description | | ----- | ------- | ---------------------------------------------- | | vault | address | The address of the vault being decommissioned. | ### OrionVaultDecommissioned ```solidity event OrionVaultDecommissioned(address vault) ``` An Orion Vault has been decommissioned. #### Parameters | Name | Type | Description | | ----- | ------- | ---------------------------------------- | | vault | address | The address of the decommissioned vault. | ### VaultBeaconUpdated ```solidity event VaultBeaconUpdated(address newBeacon) ``` The vault beacon has been updated. #### Parameters | Name | Type | Description | | --------- | ------- | ------------------------------------ | | newBeacon | address | The address of the new vault beacon. | ### UpgradeTimelockSet ```solidity event UpgradeTimelockSet(address proxy, address timelock) ``` The upgrade timelock address has been set on an upgradeable contract. #### Parameters | Name | Type | Description | | -------- | ------- | ------------------------------------------------------------ | | proxy | address | The proxy whose timelock was updated. | | timelock | address | The new upgrade timelock address (an OZ TimelockController). | --- # OrionEncryptedVault > A confidential implementation of OrionVault supporting active management strategies ### MIN_CIPHERTEXT_LENGTH ```solidity uint256 MIN_CIPHERTEXT_LENGTH ``` Minimum ciphertext length. ### _portfolioCiphertext ```solidity bytes _portfolioCiphertext ``` Encrypted portfolio shares per asset (w_0) ### _intentCiphertext ```solidity bytes _intentCiphertext ``` Encrypted strategist intent (w_1) ### constructor ```solidity constructor() public ``` Constructor that disables initializers for the implementation contract ### initialize ```solidity function initialize(address manager_, address strategist_, contract IOrionConfig config_, string name_, string symbol_, uint8 feeType_, uint16 performanceFee_, uint16 managementFee_, address depositAccessControl_, address holderAccessControl_, address transferAccessControl_) public ``` Initialize the vault #### Parameters | Name | Type | Description | | ---------------------- | --------------------- | ----------------------------------------------------- | | manager_ | address | The address of the vault manager | | strategist_ | address | The address of the vault strategist | | config_ | contract IOrionConfig | The address of the OrionConfig contract | | name_ | string | The name of the vault | | symbol_ | string | The symbol of the vault | | feeType_ | uint8 | The fee type | | performanceFee_ | uint16 | The performance fee | | managementFee_ | uint16 | The management fee | | depositAccessControl_ | address | Deposit access control (address(0) = permissionless) | | holderAccessControl_ | address | Holder access control (address(0) = permissionless) | | transferAccessControl_ | address | Transfer access control (address(0) = permissionless) | ### submitIntent ```solidity function submitIntent(bytes intentCiphertext) external ``` Submit an encrypted portfolio intent #### Parameters | Name | Type | Description | | ---------------- | ----- | ------------------------ | | intentCiphertext | bytes | Opaque intent ciphertext | ### maxCiphertextLength ```solidity function maxCiphertextLength() public view returns (uint256) ``` Maximum accepted ciphertext length for the current investment universe #### Return Values | Name | Type | Description | | ---- | ------- | ---------------- | | [0] | uint256 | Max blob length. | ### getPortfolio ```solidity function getPortfolio() external view returns (bytes portfolioCiphertext) ``` Returns the stored portfolio ciphertext #### Return Values | Name | Type | Description | | ------------------- | ----- | ---------------- | | portfolioCiphertext | bytes | Opaque portfolio | ### getIntent ```solidity function getIntent() external view returns (bytes intentCiphertext) ``` Returns the stored intent ciphertext #### Return Values | Name | Type | Description | | ---------------- | ----- | ------------- | | intentCiphertext | bytes | Opaque intent | ### updateVaultState ```solidity function updateVaultState(bytes portfolioCiphertext, uint256 newTotalAssets) external ``` Updates the vault's encrypted portfolio and total assets _Can only be called by the liquidity orchestrator._ #### Parameters | Name | Type | Description | | ------------------- | ------- | ---------------------------------------- | | portfolioCiphertext | bytes | Opaque portfolio | | newTotalAssets | uint256 | The new total assets value for the vault | --- # OrionTransparentVault > A transparent implementation of OrionVault supporting both active and passive management strategies ### _portfolio ```solidity struct EnumerableMap.AddressToUintMap _portfolio ``` Current portfolio shares per asset (w_0) - mapping of token address to live allocation ### _portfolioIntent ```solidity struct EnumerableMap.AddressToUintMap _portfolioIntent ``` Strategist intent (w_1) - mapping of token address to target allocation ### constructor ```solidity constructor() public ``` Constructor that disables initializers for the implementation contract ### initialize ```solidity function initialize(address manager_, address strategist_, contract IOrionConfig config_, string name_, string symbol_, uint8 feeType_, uint16 performanceFee_, uint16 managementFee_, address depositAccessControl_, address holderAccessControl_, address transferAccessControl_) public ``` Initialize the vault #### Parameters | Name | Type | Description | | ---------------------- | --------------------- | ----------------------------------------------------- | | manager_ | address | The address of the vault manager | | strategist_ | address | The address of the vault strategist | | config_ | contract IOrionConfig | The address of the OrionConfig contract | | name_ | string | The name of the vault | | symbol_ | string | The symbol of the vault | | feeType_ | uint8 | The fee type | | performanceFee_ | uint16 | The performance fee | | managementFee_ | uint16 | The management fee | | depositAccessControl_ | address | Deposit access control (address(0) = permissionless) | | holderAccessControl_ | address | Holder access control (address(0) = permissionless) | | transferAccessControl_ | address | Transfer access control (address(0) = permissionless) | ### submitIntent ```solidity function submitIntent(struct IOrionTransparentVault.IntentPosition[] intent) external ``` Submit a plaintext portfolio intent. #### Parameters | Name | Type | Description | | ------ | ---------------------------------------------- | ------------------------------------------------------------------------- | | intent | struct IOrionTransparentVault.IntentPosition[] | IntentPosition structs array containing the tokens and plaintext weights. | ### getPortfolio ```solidity function getPortfolio() external view returns (address[] tokens, uint256[] sharesPerAsset) ``` Get the transparent portfolio. #### Return Values | Name | Type | Description | | -------------- | --------- | -------------------------------------- | | tokens | address[] | The tokens in the portfolio. | | sharesPerAsset | uint256[] | The shares per asset in the portfolio. | ### getIntent ```solidity function getIntent() external view returns (address[] tokens, uint32[] weights) ``` Get the transparent intent. #### Return Values | Name | Type | Description | | ------- | --------- | -------------------------- | | tokens | address[] | The tokens in the intent. | | weights | uint32[] | The weights in the intent. | ### updateVaultState ```solidity function updateVaultState(address[] tokens, uint256[] shares, uint256 newTotalAssets) external ``` Updates the vault's portfolio state and total assets _Can only be called by the liquidity orchestrator. Clears the previous portfolio and replaces it with the new one. Updates the high watermark if the current share price exceeds it. The system maintains a single global high watermark shared across all LPs._ #### Parameters | Name | Type | Description | | -------------- | --------- | ---------------------------------------------------- | | tokens | address[] | Array of token addresses in the portfolio | | shares | uint256[] | Array of shares per asset (parallel to tokens array) | | newTotalAssets | uint256 | The new total assets value for the vault | --- # OrionVault > Modular asset management vault with asynchronous deposits and redemptions ### manager ```solidity address manager ``` Vault manager ### strategist ```solidity address strategist ``` Vault strategist ### config ```solidity contract IOrionConfig config ``` OrionConfig contract ### liquidityOrchestrator ```solidity contract ILiquidityOrchestrator liquidityOrchestrator ``` Liquidity orchestrator ### depositAccessControl ```solidity address depositAccessControl ``` Deposit access control contract (address(0) = permissionless) ### _totalAssets ```solidity uint256 _totalAssets ``` Total assets under management (t_0) - denominated in underlying asset units ### pendingVaultFees ```solidity uint256 pendingVaultFees ``` Pending vault fees [assets] ### SHARE_DECIMALS ```solidity uint8 SHARE_DECIMALS ``` Share token decimals ### YEAR_IN_SECONDS ```solidity uint32 YEAR_IN_SECONDS ``` Number of seconds in a year ### BASIS_POINTS_FACTOR ```solidity uint16 BASIS_POINTS_FACTOR ``` Basis points factor (100% = 10_000) ### feeModel ```solidity struct IOrionVault.FeeModel feeModel ``` Fee model ### newFeeRatesTimestamp ```solidity uint256 newFeeRatesTimestamp ``` Timestamp when new fee rates become effective ### oldFeeModel ```solidity struct IOrionVault.FeeModel oldFeeModel ``` Previous fee model (used during cooldown period) ### isDecommissioning ```solidity bool isDecommissioning ``` Flag indicating if the vault is in decommissioning mode _When true, intent is overridden to 100% underlying asset_ ### PendingUnderlyingClaims ```solidity struct PendingUnderlyingClaims { mapping(address => uint256) byUser; uint256 total; } ``` ### holderAccessControl ```solidity address holderAccessControl ``` Holder access control contract (address(0) = permissionless) ### transferAccessControl ```solidity address transferAccessControl ``` Transfer access control contract (address(0) = permissionless) ### onlyManager ```solidity modifier onlyManager() ``` _Restricts function to only vault manager_ ### onlyStrategist ```solidity modifier onlyStrategist() ``` _Restricts function to only vault strategist_ ### onlyLiquidityOrchestrator ```solidity modifier onlyLiquidityOrchestrator() ``` _Restricts function to only liquidity orchestrator_ ### onlyConfig ```solidity modifier onlyConfig() ``` _Restricts function to only Orion Config contract_ ### constructor ```solidity constructor() internal ``` Constructor that disables initializers for the implementation contract ### __OrionVault_init ```solidity function __OrionVault_init(address manager_, address strategist_, contract IOrionConfig config_, string name_, string symbol_, uint8 feeType_, uint16 performanceFee_, uint16 managementFee_, address depositAccessControl_, address holderAccessControl_, address transferAccessControl_) internal ``` Initialize the vault #### Parameters | Name | Type | Description | | ---------------------- | --------------------- | ----------------------------------------------------- | | manager_ | address | The address of the vault manager | | strategist_ | address | The address of the vault strategist | | config_ | contract IOrionConfig | The address of the OrionConfig contract | | name_ | string | The name of the vault | | symbol_ | string | The symbol of the vault | | feeType_ | uint8 | The fee type | | performanceFee_ | uint16 | The performance fee | | managementFee_ | uint16 | The management fee | | depositAccessControl_ | address | Deposit access control (address(0) = permissionless) | | holderAccessControl_ | address | Holder access control (address(0) = permissionless) | | transferAccessControl_ | address | Transfer access control (address(0) = permissionless) | ### deposit ```solidity function deposit(uint256, address) public pure returns (uint256) ``` _Deposit `assets` underlying tokens and send the corresponding number of vault shares (`shares`) to `receiver`. - MUST emit the Deposit event. - MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the deposit execution, and are accounted for during deposit. - MUST revert if all of assets cannot be deposited (due to deposit limit being reached, slippage, the user not approving enough underlying tokens to the Vault contract, etc). NOTE: most implementations will require pre-approval of the Vault with the Vault’s underlying asset token._ ### mint ```solidity function mint(uint256, address) public pure returns (uint256) ``` _Mints exactly `shares` vault shares to `receiver` in exchange for `assets` underlying tokens. - MUST emit the Deposit event. - MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the mint execution, and are accounted for during mint. - MUST revert if all of shares cannot be minted (due to deposit limit being reached, slippage, the user not approving enough underlying tokens to the Vault contract, etc). NOTE: most implementations will require pre-approval of the Vault with the Vault’s underlying asset token._ ### redeem ```solidity function redeem(uint256 shares, address receiver, address owner) public returns (uint256) ``` _Burns exactly shares from owner and sends assets of underlying tokens to receiver. - MUST emit the Withdraw event. - MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the redeem execution, and are accounted for during redeem. - MUST revert if all of shares cannot be redeemed (due to withdrawal limit being reached, slippage, the owner not having enough shares, etc). NOTE: some implementations will require pre-requesting to the Vault before a withdrawal may be performed. Those methods should be performed separately._ ### withdraw ```solidity function withdraw(uint256, address, address) public pure returns (uint256) ``` _Burns shares from owner and sends exactly assets of underlying tokens to receiver. - MUST emit the Withdraw event. - MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the withdraw execution, and are accounted for during withdraw. - MUST revert if all of assets cannot be withdrawn (due to withdrawal limit being reached, slippage, the owner not having enough shares, etc). Note that some implementations will require pre-requesting to the Vault before a withdrawal may be performed. Those methods should be performed separately._ ### totalAssets ```solidity function totalAssets() public view returns (uint256) ``` _Returns the total amount of the underlying asset that is “managed” by Vault. - SHOULD include any compounding that occurs from yield. - MUST be inclusive of any fees that are charged against assets in the Vault. - MUST NOT revert._ ### maxDeposit ```solidity function maxDeposit(address receiver) public view returns (uint256) ``` _Returns the maximum amount of the underlying asset that can be deposited into the Vault for the receiver, through a deposit call. - MUST return a limited value if receiver is subject to some deposit limit. - MUST return 2 ** 256 - 1 if there is no limit on the maximum amount of assets that may be deposited. - MUST NOT revert._ ### maxMint ```solidity function maxMint(address receiver) public view returns (uint256) ``` _Returns the maximum amount of the Vault shares that can be minted for the receiver, through a mint call. - MUST return a limited value if receiver is subject to some mint limit. - MUST return 2 ** 256 - 1 if there is no limit on the maximum amount of shares that may be minted. - MUST NOT revert._ ### maxRedeem ```solidity function maxRedeem(address owner) public view returns (uint256) ``` _Returns the maximum amount of Vault shares that can be redeemed from the owner balance in the Vault, through a redeem call. - MUST return a limited value if owner is subject to some withdrawal limit or timelock. - MUST return balanceOf(owner) if owner is not subject to any withdrawal limit or timelock. - MUST NOT revert._ ### maxWithdraw ```solidity function maxWithdraw(address owner) public view returns (uint256) ``` _Returns the maximum amount of the underlying asset that can be withdrawn from the owner balance in the Vault, through a withdraw call. - MUST return a limited value if owner is subject to some withdrawal limit or timelock. - MUST NOT revert._ ### decimals ```solidity function decimals() public view virtual returns (uint8) ``` Override ERC4626 decimals to always use SHARE_DECIMALS regardless of underlying asset decimals _This ensures consistent 18-decimal precision for share tokens across all vaults_ #### Return Values | Name | Type | Description | | ---- | ----- | ----------------------------------------- | | [0] | uint8 | SHARE_DECIMALS for all vault share tokens | ### _decimalsOffset ```solidity function _decimalsOffset() internal view virtual returns (uint8) ``` Override ERC4626 decimals offset to match our custom decimals implementation _Since we override decimals() to return SHARE_DECIMALS, we need to override _decimalsOffset() to return the difference between SHARE_DECIMALS and underlying asset decimals_ #### Return Values | Name | Type | Description | | ---- | ----- | --------------------------------------------------------- | | [0] | uint8 | The decimals offset for virtual shares/assets calculation | ### _convertToSharesWithPITTotalAssets ```solidity function _convertToSharesWithPITTotalAssets(uint256 assets, uint256 pointInTimeTotalAssets, uint256 snapshotTotalSupply, enum Math.Rounding rounding) internal view returns (uint256) ``` Internal version that uses a snapshot of totalSupply for batch processing #### Parameters | Name | Type | Description | | ---------------------- | ------------------ | ------------------------------------------ | | assets | uint256 | The assets to convert | | pointInTimeTotalAssets | uint256 | The point-in-time total assets | | snapshotTotalSupply | uint256 | The snapshot of totalSupply at batch start | | rounding | enum Math.Rounding | The rounding mode | #### Return Values | Name | Type | Description | | ---- | ------- | ----------------------------------- | | [0] | uint256 | The shares equivalent to the assets | ### _convertToAssetsWithPITTotalAssets ```solidity function _convertToAssetsWithPITTotalAssets(uint256 shares, uint256 pointInTimeTotalAssets, uint256 snapshotTotalSupply, enum Math.Rounding rounding) internal view returns (uint256) ``` Internal version that uses a snapshot of totalSupply for batch processing #### Parameters | Name | Type | Description | | ---------------------- | ------------------ | ------------------------------------------ | | shares | uint256 | The shares to convert | | pointInTimeTotalAssets | uint256 | The point-in-time total assets | | snapshotTotalSupply | uint256 | The snapshot of totalSupply at batch start | | rounding | enum Math.Rounding | The rounding mode | #### Return Values | Name | Type | Description | | ---- | ------- | ----------------------------------- | | [0] | uint256 | The assets equivalent to the shares | ### overrideIntentForDecommissioning ```solidity function overrideIntentForDecommissioning() external ``` Override intent to 100% underlying asset for decommissioning _Can only be called by the OrionConfig contract_ ### requestDeposit ```solidity function requestDeposit(uint256 assets) external ``` Submit an asynchronous deposit request. _No share tokens are minted immediately. The specified amount of underlying tokens is transferred to the liquidity orchestrator for centralized liquidity management._ #### Parameters | Name | Type | Description | | ------ | ------- | ---------------------------------------------- | | assets | uint256 | The amount of the underlying asset to deposit. | ### requestDepositFor ```solidity function requestDepositFor(address beneficiary, uint256 assets) external ``` Submit an async deposit request on behalf of `beneficiary`. #### Parameters | Name | Type | Description | | ----------- | ------- | ---------------------------------------------------------------------- | | beneficiary | address | The LP whose pending deposit balance and eventual shares are credited. | | assets | uint256 | The amount of underlying to deposit. | ### _requestDeposit ```solidity function _requestDeposit(address beneficiary, uint256 assets) internal ``` _Assets are pulled from msg.sender (e.g., router/depositor), but the deposit queue and eventual shares credit `beneficiary`. Deposit and holder access control lists are evaluated solely against `beneficiary`, not msg.sender._ ### cancelDepositRequest ```solidity function cancelDepositRequest(uint256 amount) external ``` Cancel a previously submitted deposit request. _Allows LPs to withdraw their funds before any share tokens are minted. The request must still have enough balance remaining to cover the cancellation. Funds are returned from the liquidity orchestrator to the LP._ #### Parameters | Name | Type | Description | | ------ | ------- | -------------------------------- | | amount | uint256 | The amount of funds to withdraw. | ### requestRedeem ```solidity function requestRedeem(uint256 shares) external ``` Submit a redemption request. _No share tokens are burned immediately. The specified amount of share tokens is transferred to the vault._ #### Parameters | Name | Type | Description | | ------ | ------- | ------------------------------------------- | | shares | uint256 | The amount of the share tokens to withdraw. | ### cancelRedeemRequest ```solidity function cancelRedeemRequest(uint256 shares) external ``` Cancel a previously submitted redemption request. _Allows LPs to recover their share tokens before any burning occurs. The request must still have enough shares remaining to cover the cancellation. Share tokens are returned from the vault._ #### Parameters | Name | Type | Description | | ------ | ------- | -------------------------------------- | | shares | uint256 | The amount of share tokens to recover. | ### updateStrategist ```solidity function updateStrategist(address newStrategist) external ``` Update the strategist address _The strategist is responsible for setting allocation logic for the vault's assets. This function enables managers to update the strategist. Strategist can be a smart contract or an address. It is the FULL responsibility of the manager to ensure the strategist is capable of performing its duties._ #### Parameters | Name | Type | Description | | ------------- | ------- | --------------------------- | | newStrategist | address | The new strategist address. | ### _linkStrategistVault ```solidity function _linkStrategistVault(address strategist_) internal ``` _Tells onchain strategists which vault they manage; skips EOAs and non-compliant / non-strategist contracts._ ### _requireValidAccessControl ```solidity function _requireValidAccessControl(address accessControl, bytes4 interfaceId) internal view ``` _Rejects EOAs and contracts that fail ERC-165 compliance and do not support `interfaceId`._ ### _depositAccessControlAllows ```solidity function _depositAccessControlAllows(address account) internal view returns (bool) ``` ### _holderAccessControlAllows ```solidity function _holderAccessControlAllows(address account) internal view returns (bool) ``` ### _canRequestDeposit ```solidity function _canRequestDeposit(address account) internal view returns (bool) ``` ### _requireCanRequestDeposit ```solidity function _requireCanRequestDeposit(address account) internal view ``` ### setDepositAccessControl ```solidity function setDepositAccessControl(address newDepositAccessControl) external ``` Set deposit access control contract _Only callable by vault manager. Non-zero addresses must ERC-165 as IOrionDepositAccessControl._ #### Parameters | Name | Type | Description | | ----------------------- | ------- | ------------------------------------------------------------------------ | | newDepositAccessControl | address | Address of the new access control contract (address(0) = permissionless) | ### setHolderAccessControl ```solidity function setHolderAccessControl(address newHolderAccessControl) external ``` Set holder access control contract _Only callable by vault manager. Non-zero addresses must ERC-165 as IOrionHolderAccessControl._ #### Parameters | Name | Type | Description | | ---------------------- | ------- | ------------------------------------------------------------------------ | | newHolderAccessControl | address | Address of the new access control contract (address(0) = permissionless) | ### setTransferAccessControl ```solidity function setTransferAccessControl(address newTransferAccessControl) external ``` Set transfer access control contract _Only callable by vault manager. Non-zero addresses must ERC-165 as IOrionTransferAccessControl._ #### Parameters | Name | Type | Description | | ------------------------ | ------- | ------------------------------------------------------------------------ | | newTransferAccessControl | address | Address of the new access control contract (address(0) = permissionless) | ### _update ```solidity function _update(address from, address to, uint256 value) internal virtual ``` _Every ERC-20 balance change is routed through `_update`. Guard: - `from != address(0)` excludes mint, e.g. `fulfillDeposit`. - `to != address(0)` excludes burn, e.g. `redeem, fulfillRedeem`. - `from != address(this)` excludes vault-as-sender, e.g. `cancelRedeemRequest`. - `to != address(this)` excludes vault-as-recipient, e.g. `requestRedeem`._ ### updateFeeModel ```solidity function updateFeeModel(uint8 feeType, uint16 performanceFee, uint16 managementFee) external ``` Update the fee model parameters with cooldown protection _Only vault manager can update fee model parameters Performance and management fees are capped by protocol limits New fees take effect after cooldown period to protect depositors_ #### Parameters | Name | Type | Description | | -------------- | ------ | ------------------- | | feeType | uint8 | The fee type | | performanceFee | uint16 | The performance fee | | managementFee | uint16 | The management fee | ### activeFeeModel ```solidity function activeFeeModel() public view returns (struct IOrionVault.FeeModel) ``` Returns the active fee model (old during cooldown, new after) #### Return Values | Name | Type | Description | | ---- | --------------------------- | ------------------------------ | | [0] | struct IOrionVault.FeeModel | The currently active fee model | ### _validateIntentAssets ```solidity function _validateIntentAssets(address[] assets) internal view ``` Validate that all assets in an intent are whitelisted #### Parameters | Name | Type | Description | | ------ | --------- | ------------------------------------ | | assets | address[] | Array of asset addresses to validate | ### claimVaultFees ```solidity function claimVaultFees(uint256 amount) external ``` Claim accrued vault fees #### Parameters | Name | Type | Description | | ------ | ------- | --------------------------------- | | amount | uint256 | The amount of vault fees to claim | ### pendingDeposit ```solidity function pendingDeposit(uint256 fulfillBatchSize) external view returns (uint256) ``` Get total pending deposit amount across all users _This returns asset amounts, not share amounts_ #### Parameters | Name | Type | Description | | ---------------- | ------- | ---------------------------------------------------------- | | fulfillBatchSize | uint256 | The maximum number of requests to process per fulfill call | #### Return Values | Name | Type | Description | | ---- | ------- | ------------------------------------------------------------------------------ | | [0] | uint256 | Total pending deposits denominated in underlying asset units (e.g., USDC, ETH) | ### pendingRedeem ```solidity function pendingRedeem(uint256 fulfillBatchSize) external view returns (uint256) ``` Get total pending redemption shares across all users _This returns share amounts, not underlying asset amounts_ #### Parameters | Name | Type | Description | | ---------------- | ------- | ---------------------------------------------------------- | | fulfillBatchSize | uint256 | The maximum number of requests to process per fulfill call | #### Return Values | Name | Type | Description | | ---- | ------- | ---------------------------------------------------------- | | [0] | uint256 | Total pending redemptions denominated in vault share units | ### pendingDepositCount ```solidity function pendingDepositCount() external view returns (uint256) ``` Get the number of pending deposit queue entries. #### Return Values | Name | Type | Description | | ---- | ------- | ------------------------------------------------------------------ | | [0] | uint256 | The number of unique users with non-zero pending deposit requests. | ### pendingRedeemCount ```solidity function pendingRedeemCount() external view returns (uint256) ``` Get the number of pending redeem queue entries. #### Return Values | Name | Type | Description | | ---- | ------- | ----------------------------------------------------------------- | | [0] | uint256 | The number of unique users with non-zero pending redeem requests. | ### pendingRedeemBatch ```solidity function pendingRedeemBatch(uint256 fulfillBatchSize) external view returns (address[], uint256[]) ``` Get the list of pending redeem entries (users and shares) for the next fulfill batch _This function enables per-request conversion, ensuring exact rounding behaviour for state transition._ #### Parameters | Name | Type | Description | | ---------------- | ------- | ------------------------------------------ | | fulfillBatchSize | uint256 | The maximum number of requests to consider | #### Return Values | Name | Type | Description | | ---- | --------- | ----------- | | [0] | address[] | | | [1] | uint256[] | | ### accrueVaultFees ```solidity function accrueVaultFees(uint256 managementFee, uint256 performanceFee) external ``` Accrue vault fees for a specific epoch #### Parameters | Name | Type | Description | | -------------- | ------- | ------------------------------------------------------------------ | | managementFee | uint256 | The amount of management fees to accrue in underlying asset units | | performanceFee | uint256 | The amount of performance fees to accrue in underlying asset units | ### fulfillDeposit ```solidity function fulfillDeposit(uint256 depositTotalAssets) external ``` Process all pending deposit requests and mint shares to depositors #### Parameters | Name | Type | Description | | ------------------ | ------- | ----------------------------------------------------- | | depositTotalAssets | uint256 | The total assets associated with the deposit requests | ### fulfillRedeem ```solidity function fulfillRedeem(uint256 redeemTotalAssets) external ``` Process all pending redemption requests and burn shares from redeemers #### Parameters | Name | Type | Description | | ----------------- | ------- | -------------------------------------------------------- | | redeemTotalAssets | uint256 | The total assets associated with the redemption requests | ### totalPendingUnderlyingClaims ```solidity function totalPendingUnderlyingClaims() external view returns (uint256) ``` Total underlying assets owed to users whose redemption transfer failed #### Return Values | Name | Type | Description | | ---- | ------- | ----------- | | [0] | uint256 | | ### pendingUnderlyingClaim ```solidity function pendingUnderlyingClaim(address account) external view returns (uint256) ``` Underlying escrowed for `account` from a failed redemption payout or deposit fulfillment. #### Parameters | Name | Type | Description | | ------- | ------- | --------------------- | | account | address | The address to query. | #### Return Values | Name | Type | Description | | ---- | ------- | ----------- | | [0] | uint256 | | ### claimUnderlying ```solidity function claimUnderlying() external ``` Claim underlying funds from a previously failed redemption transfer or a deposit fulfillment that could not mint shares. _Called by the user after the transfer blocker / eligibility issue has been resolved._ ### _payoutOrEscrowRedemption ```solidity function _payoutOrEscrowRedemption(address user, uint256 underlyingAmount, uint256 userShares) internal ``` _Push underlying to the user; on revert, escrow on this vault for later claim._