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.
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 execution windows. Future protocol upgrades will support optional synchronous execution. |
| Slippage | Prices for order generation are measured seconds before order execution, introducing the risk of inconsistent accounting. | Atomic slippage limits are enforced for each asset. Buffer liquidity is maintained for programmatic counterparty risk management. Batching and netting reduce market impact. |
| Failing Orders | If an order fails to execute via the Liquidity Orchestrator (e.g., due to low liquidity or revert errors), the system would stall the rebalancing cycle. | In such scenarios, the system automatically goes back to order generation, bypassing the problematic asset(s), finalizing the rebalancing cycle and retrying the failed order later. |
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: comprehensive due diligence is performed before adding assets. |
| Liquidity Risk | Lack of liquidity on external DEXs or lending protocols can prevent execution or cause significant slippage. | Vetting is performed to monitor the liquidity and market depth of investment universe assets. The same mitigation strategies discussed in the Execution and Orchestration Risks section are in place. |
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 continuously monitored. Time-weighted average prices (TWAP) are used to reduce manipulation risk when needed. Staleness checks, circuit breakers and price deviation checks are in place. |
Governance Risks
| Risk | Description | Mitigation / Controls |
|---|---|---|
| Emergency Powers | The Guardian and Admin retain the right to execute emergency functions, including pauseAll, which may temporarily freeze all deposits, redemptions, and interactions with the Vaults. | Emergency powers are limited to specific functions. Emergency actions are triggered by broken invariants and anomalous states only, and are publicly communicated. |
| Automation Dependencies | The Protocol relies on off-chain "Keepers" (the Automation Registry) to trigger critical functions like rebalancing. In the event of an automation failure, Vaults may remain in a pending state or fail to rebalance until the service is restored. | Redundant keeper infrastructure is maintained. Monitoring systems alert on missed upkeep. Manual intervention capabilities exist as a fallback. |
| Governance Changes | Protocol governance may change parameters, fees, or functionality in ways that affect open positions. | Timelock mechanisms provide advance notice, and community input is solicited for significant changes. |
User Error and Security Risks
| Risk | Description | Mitigation / Controls |
|---|---|---|
| User Error | Forgotten passwords, incorrectly constructed transactions, or mistyped addresses. | User-friendly interfaces with clear warnings and confirmations, including address validation and transaction preview features. |
| Unauthorized Access | Unauthorized access to Wallets or devices, including through the use of viruses, phishing, or other means of attack. | Security best practices documentation. Phishing awareness and education. |