> 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`.

# 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.

# 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.

## 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.