Single-Chain Optimizations

While Aori excels at cross-chain trading, it also provides highly optimized execution paths for single-chain swaps. These same-chain operations bypass complex cross-chain messaging and offer efficient peer-to-peer settlement with multiple fulfillment strategies tailored to different liquidity sourcing scenarios.

Unified Order Interface

Single-chain swaps in Aori use the same Order structure as cross-chain trades, with both srcEid and dstEid set to the same chain endpoint ID. This unified approach allows applications to handle both local and cross-chain trades through identical interfaces while the protocol applies chain-specific optimizations automatically.

This design philosophy means developers can build applications that seamlessly support both single-chain and cross-chain trading without managing different order types or execution flows.

Execution Strategies

Aori offers three distinct fulfillment strategies for single-chain swaps, each optimized for different solver capabilities and market conditions.

Atomic Swaps

The most gas-efficient execution path for solvers who already possess the required output tokens.

function swap(Order calldata order, bytes calldata signature) external;

Atomic swaps execute the entire trade in a single transaction. The solver provides the output tokens while simultaneously receiving the input tokens, eliminating the need for separate deposit and fill operations. This approach minimizes gas costs and provides immediate settlement for both parties.

The atomic nature ensures that either the complete trade executes successfully or the entire transaction reverts, providing strong guarantees against partial execution or failed states.

Delayed Settlement

A two-phase execution strategy that gives solvers time to source liquidity after securing the user's trading intent.

// Phase 1: Lock user tokens
function deposit(Order calldata order, bytes calldata signature) external;

// Phase 2: Fulfill the order
function fill(Order calldata order) external;

The delayed settlement strategy allows solvers to commit to fulfilling an order before they have the necessary output tokens. This is particularly valuable for market makers who need to source liquidity from DEXs, other protocols, or their own inventory management systems.

During the delay period, the user's tokens remain locked, preventing double-spending while giving the solver time to execute their liquidity sourcing strategy. Once the solver obtains the output tokens, they can complete the trade through the fill operation.

Hook-Based Execution

An advanced execution path that enables custom logic during the order processing, allowing for sophisticated liquidity sourcing and trade execution strategies.

Hook-based execution transfers the user's input tokens directly to a custom hook contract that implements arbitrary logic before returning the required output tokens. This enables complex strategies like DEX aggregation, multi-hop routing, or integration with other DeFi protocols.

struct SrcHook {
    address hookAddress;
    address preferredToken;
    uint256 minPreferedTokenAmountOut;
    bytes instructions;
}

function deposit(
    Order calldata order,
    bytes calldata signature,
    SrcHook calldata hook
) external;

Hook System Deep Dive

The hook system represents Aori's most flexible execution mechanism, enabling integration with virtually any DeFi protocol or custom logic.

Hook Architecture

Hooks are smart contracts that implement a standardized interface for receiving tokens, executing custom logic, and returning the required output tokens. The hook receives the user's input tokens along with encoded instructions specifying the desired execution strategy.

Common hook implementations include DEX aggregators that route trades across multiple venues, yield optimizers that stake tokens before trading, and portfolio rebalancers that execute complex multi-step strategies.

Security Considerations

Hook execution introduces additional complexity that requires careful security consideration. The hook contract must be trusted to handle the user's tokens appropriately and return the correct output amount. Solvers should only use audited hook contracts and implement appropriate slippage protection.

The protocol validates that the hook returns at least the minimum required output amount, but cannot verify the optimality of the execution strategy or protect against all forms of value extraction.