Skip to main content

Modular Infrastructure

Orvex is built on v4 tech. That matters because v4 is designed around modular infrastructure: keep the core exchange logic lean and reliable, then extend behaviour through modules over time.

In plain terms, Orvex can ship new functionality without rebuilding the whole exchange every time.

What "modular" means in Orvex

Orvex is structured around:

  • Immutable Core: the base logic that handles swaps and liquidity math. Once deployed, the core remains unchanged and reliable.
  • Hooks (Modules): pluggable components that extend pool behavior without requiring liquidity migration.
  • Separation: core stays stable; modules evolve without creating a new product every upgrade.
  • Consistency: integrations and user flows stay familiar as Orvex expands.

Technical Architecture

Singleton/PoolManager Pattern

All pools in Orvex operate under a unified manager rather than individual pool contracts. This design:

  • Enables efficient pool creation through state updates instead of deploying new contracts
  • Streamlines multi-hop routing by keeping all pool state in one place
  • Reduces gas costs for complex trading routes

Flash Accounting System

Orvex uses a flash accounting system that optimizes multi-hop trades:

  • Settles net balances at the end of routing paths
  • Eliminates redundant token transfers between consecutive swaps
  • Significantly reduces transaction costs for complex trades

Internal Accounting (ERC-6909)

The protocol implements an ERC-6909-style accounting system for internal token tracking:

  • Lightweight multi-token balance tracking
  • Lower gas consumption for frequent interactions
  • Efficient handling of multiple token positions

Native Token Support

Where supported by the blockchain, Orvex can settle trades directly in native assets, reducing transfer overhead and gas costs.

Hooks

Hooks are the primary extensibility mechanism in Orvex. A hook is a smart contract selected at pool creation that defines how a pool behaves beyond the immutable core math. Once attached, a hook cannot be swapped — ensuring predictable behavior and strong safety guarantees.

A single hook implementation may serve many pools. Orvex exposes lifecycle "touchpoints" that allow hooks to run custom logic before or after core pool actions, without altering pricing or accounting invariants.

Lifecycle Touchpoints

Hooks may execute logic at the following moments:

  • Before / after pool initialization
  • Before / after adding or removing liquidity
  • Before / after swaps
  • Before / after donations

Design Constraints

To ensure safety and performance, hooks are stateless or minimally stateful, deterministic, and gas-aware. Reentrancy into the same pool context is blocked by the PoolManager.

Immutable Attachment

The hook address for a pool is fixed at initialization and cannot be replaced. This guarantees consistency for LPs and traders. To materially change behavior, a new hook is deployed with a new pool, and liquidity can migrate.

Hook Families

Orvex's hook architecture enables a wide range of pool-level behavior:

Fee hooks — Dynamic fees based on trade impact or volatility, fee redirects to veORVX voters or treasury, conditional rebates for defined cohorts.

Liquidity hooks — Auto-rebalancing strategies, liquidity throttles near sensitive levels, IL mitigation schemes.

Order hooks — TWAMM streamed orders, limit/stop/take-profit orders, DCA and auto-roll logic.

Incentive hooks — In-range boosts for active liquidity, bribe pass-through to veORVX voting, donation routing to active tick ranges.

Access hooks — Token-gated or allowlisted pools, circuit breakers during abnormal conditions, slippage and price-move caps.

Production Standards

To be enabled on production pools, a hook must meet strict requirements: governance controls with parameter bounds and pause modes, least-privileged access control, no reentrancy, bounded gas complexity, and thorough testing and security review.

Security and Upgrades

A modular design helps reduce risk by keeping critical logic isolated:

  • Immutable Core: Core swap and liquidity math cannot be changed once deployed
  • Independent Hook Audits: Each hook module can be audited separately
  • Separation of Concerns: Critical execution logic is isolated from extensibility features

Where upgrades or parameter changes are possible, they follow a defined process with transparency, including documentation of what can be changed, by whom, and under what conditions.

Benefits of V4 Architecture

  • Gas Efficiency: Flash accounting and singleton design reduce transaction costs by 20-50% on complex routes
  • Extensibility: New features ship without migrating liquidity or breaking integrations
  • Composability: Hooks enable custom pool types while maintaining a unified liquidity layer
  • Reliability: Immutable core ensures critical functionality remains stable and predictable