Protocol Summary
The Orion protocol is a portfolio management infrastructure designed for creating and managing investment vaults. It operates on an epoch-based system, driven by two main orchestrator contracts, to provide efficient, batched transaction processing for deposits, redemptions, and portfolio rebalancing.
The architecture is modular and consists of several key components.
Orion Vaults
These are ERC-4626 compliant vaults where users, known as Liquidity Providers (LPs), can deposit a single underlying asset. A key feature is the asynchronous nature of deposits and redemptions. LPs submit requests which are queued and processed at the end of each epoch, mitigating risks like front-running and enabling gas-efficient batch operations.
Strategists and Intents
Each vault is managed by a Strategist, who defines the investment strategy by submitting an "intent." An intent is a target portfolio allocation. Strategists can be active (an externally owned account submitting plaintext intents) or passive (a smart contract implementing the IOrionStrategist interface that computes the intent on-demand).
Internal State Orchestrator
Acting as the protocol's "brain," this contract is triggered periodically by an external keeper. It reads the state of all vaults, including current portfolios and new manager intents. It then calculates fees, processes pending deposits and redemptions to determine the new total assets for each vault, and computes the required trades to align all vault portfolios with their target intents. Finally, it aggregates these trades into a single, net list of buy and sell orders for the entire protocol.
Liquidity Orchestrator
This contract is the protocol's execution engine. It first 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): 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 then executes trades via modular Execution Adapters, manages a central pool of the protocol's underlying asset (netting across vaults before external markets), and maintains a liquidity buffer for slippage. Once rebalancing is complete, it finalizes the epoch by settling the queued deposit and redemption requests in the respective vaults. This design keeps execution scalable without giving up verifiability.
Adapters and Registries
The protocol's extensibility is ensured through Price Adapters, which provide asset pricing data, and Execution Adapters, which handle the logic for trading specific types of assets. These are managed by dedicated registry contracts. This orchestrated, epoch-based model allows the protocol to manage a diverse set of assets across multiple vaults efficiently, reducing gas costs and providing a structured environment for decentralized asset management.