Risks
Security Contact: For security-related matters, please contact security@orionfinance.ai.
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.
This page documents the various risks associated with using the Orion Finance Protocol, including smart contract risks, execution risks, third-party dependencies, oracle risks, governance considerations, and user security risks. Each risk category includes descriptions and the mitigation strategies in place.
Mitigations described below are best-effort controls, not guarantees, unless explicitly required by onchain logic. See the Terms of Service for binding limitations.
Smart Contract Risks
Smart contracts may contain bugs, vulnerabilities, or unexpected behaviors that could result in loss of funds. While extensive testing and audits are performed, no system is completely free of risk.
To help mitigate the risk of vulnerabilities or bugs in the smart contracts:
- All core smart contracts undergo independent security audits prior to deployment.
- Protocol invariants are continuously monitored in the production environment.
- Conservative upgrade and deployment procedures are followed.
- Emergency pause mechanisms are in place (see 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, introducing the risk of inconsistent accounting between planning and settlement. | Atomic slippage limits are enforced per asset where configured. A protocol-controlled buffer reserve 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 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 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 emergency pause functions (including pauseAll) to temporarily freeze deposits, redemptions, and vault interactions in anomalous states. The Admin retains broader protocol controls, including pauseAll and unpause. Neither role guarantees recovery timing or compensation for pause-related disruption. | Guardian authority under policy is limited to emergency pause only—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. |