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
+ 1to 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 | All active vaults |
| Liquidity Orchestrator Balance Consistency | Whitelisted assets; portfolios over vaults |
| 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.