Skip to main content

For AI agents: the complete documentation index is at llms.txt. Markdown versions of pages are available by appending .md to the URL or sending Accept: text/markdown.

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 repository; optional strategists, access controllers, and distribution helpers live in protocol-plugins.

The sections below describe the main protocol components and how they interact.

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 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): 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.

Last updated on