Skip to main content

Audits

Orvex is built on audited DEX infrastructure and modern v4-based architecture. This page outlines upstream audit references, Orvex-specific review practices, and the standards applied to integrated modules and partners.

1) DEX Engine (v4 Infrastructure)

Orvex is built on v4 tech, using a modular architecture designed to keep core execution logic lean while allowing extensibility through modules.

Where Orvex relies on upstream v4-style infrastructure, we reference relevant upstream audits below. These reviews cover components commonly used in v4-based systems, including pool management, routing, hooks lifecycles, and core concentrated liquidity logic.

Upstream audit reports (v4 infrastructure)

Each audit report should be reviewed directly for exact scope, assumptions, and limitations.

2) Codebase Lineage

Orvex builds on established DeFi design patterns that have seen extensive real-world usage and third-party review across multiple protocols.

Where Orvex integrates or adapts known mechanisms (such as incentives, voting systems, or emissions logic), those components benefit from prior audits and production deployments. References below reflect audits of related lineage and ecosystems.

Thena

Lynex

Any Orvex-specific changes or extensions follow the audit policy outlined below.

3) Partner Strategy Requirements

Third-party strategy providers and vaults integrated with Orvex must meet strict requirements before production use.

Before launch, partners must:

  • Provide an external audit for the exact strategy version being deployed.
  • Use version pinning (commit or hash) with explicit allow-listing; upgrades require re-review.
  • Expose emergency controls (pause, withdraw, unwind) and maintain a public incident-response contact.
  • Be subject to ongoing monitoring, including TVL behaviour and rebalancing activity.

Only partners that satisfy these conditions are eligible for production integration.

4) Audit Policy for Major Protocol Changes

Orvex applies a formal audit process to material protocol changes.

Scope includes (but is not limited to):

  • Core execution logic
  • Routing adapters
  • Pool hooks and modular extensions
  • Incentive, voting, or emissions logic
  • Treasury routing
  • External strategy interfaces

Requirements:

  • Independent third-party audit prior to mainnet deployment
  • Findings addressed before launch
  • Optional re-audit for high or medium-severity items
  • Publication of audit reports on this page where applicable

5) Governance, Multisigs, and Timelocks

Orvex uses multisig control and timelocks to reduce operational risk and increase transparency.

Multisig Governance Structure

Orvex implements a two-tier multisig system to separate critical protocol changes from routine operational decisions:

Core Admin Multisig (4-of-7)

Purpose: Critical protocol parameters and upgrades

Threshold: 4 out of 7 signers required

Timelock: 72 hours (3 days)

Scope:

  • Protocol parameter changes (fee structures, emissions rates)
  • Smart contract upgrades
  • Addition or removal of pool hooks
  • Changes to gauge voting mechanics
  • Treasury allocation modifications
  • Emergency pause/unpause of core contracts

Safety Requirements:

  • All changes subject to mandatory 72-hour public review period
  • On-chain proposals visible before execution
  • Veto window for community response
  • Multi-jurisdictional signer distribution

Operations Multisig (3-of-7)

Purpose: Day-to-day operational decisions

Threshold: 3 out of 7 signers required

Timelock: 24 hours (1 day)

Scope:

  • Whitelisting new tokens or pools
  • Gauge creation for approved pools
  • Partner strategy approvals (meeting audit requirements)
  • Fee routing configurations
  • Incentive program adjustments
  • Non-critical parameter tuning

Safety Requirements:

  • 24-hour timelock for transparency
  • Limited to pre-approved operational categories
  • Cannot modify core protocol logic
  • Regular public reporting of actions taken

Separation of Concerns

The two-tier structure ensures:

  • Critical changes require higher consensus and longer review (4-of-7, 72h)
  • Routine operations can proceed efficiently while maintaining safety (3-of-7, 24h)
  • No single point of failure across either multisig
  • Clear scope boundaries prevent privilege escalation

Key Principles

  • No single-actor control: Sensitive actions require multiple independent signers.
  • Timelock delays: Changes are subject to a public delay before execution.
  • On-chain visibility: Administrative actions are observable and auditable.
  • Separation of concerns: Critical changes and routine operations are handled through distinct processes.
  • Geographic distribution: Signers distributed across jurisdictions and time zones.

Transparency Commitments

As Orvex progresses toward full protocol launch:

  • Exact multisig addresses will be published on-chain
  • Signer identities (where public) will be disclosed
  • All multisig transactions will be viewable via block explorer
  • Quarterly governance reports will summarize multisig activity
  • Emergency response procedures will be documented publicly

Emergency Response

In the event of a critical security issue:

  • Operations multisig can execute emergency pause (24h timelock waived for critical threats)
  • Core Admin multisig can execute emergency upgrades (72h timelock waived with 5-of-7 supermajority)
  • All emergency actions require public post-mortem within 7 days
  • Community veORVX holders can propose governance votes to modify emergency powers

This governance structure balances operational efficiency with security and decentralization, ensuring Orvex can respond quickly to opportunities while maintaining robust safeguards against misuse.