Cross-Chain Architecture

Aori's cross-chain architecture enables seamless trading across different blockchains while maintaining security and trust minimization. Built on LayerZero's messaging infrastructure, the protocol coordinates order execution between paired smart contracts deployed on supported chains.

Paired Contract System

The foundation of Aori's cross-chain capability lies in identical smart contracts deployed on each supported blockchain. These contracts operate independently while coordinating through LayerZero's omnichain messaging protocol to maintain state consistency and enable secure settlement.

Each contract maintains its own state and token balances while communicating settlement confirmations, cancellation notifications, and balance synchronization messages to its counterparts on other chains.

Cross-Chain Order Execution

Cross-chain trades follow a carefully orchestrated sequence that ensures security while maintaining efficiency.

Order Deposit Phase

When a solver decides to fulfill a cross-chain order, they begin by depositing it on the source chain. This operation validates the user's signature, transfers the input tokens from the user to the Aori contract, and marks the order as Active.

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

The deposit phase serves as a commitment mechanism, locking the user's tokens and creating an on-chain record of the trading intent. This prevents the user from double-spending their tokens while giving the solver confidence to proceed with fulfillment.

Order Fulfillment Phase

On the destination chain, the solver fulfills the order by providing the output tokens directly to the user's specified recipient address. This operation transfers tokens from the solver to the user and records the fill in the solver's pending settlement array.

function fill(Order calldata order) external;

The fulfillment phase represents the solver's commitment to the trade. By providing tokens to the user, the solver demonstrates their ability to complete the trade and earns the right to claim the input tokens from the source chain.

Settlement Coordination

Settlement is where Aori's cross-chain architecture truly shines. Solvers can batch multiple filled orders for efficient settlement, dramatically reducing the per-order cost of cross-chain messaging.

function settle(
    uint32 srcEid, 
    address filler, 
    bytes calldata extraOptions
) external payable;

The settlement process creates a LayerZero message containing proof of the fills and sends it to the source chain. This message includes the filler address, order hashes, and validation data necessary for the source chain to verify and process the settlement.

LayerZero Integration

Aori leverages LayerZero's infrastructure to achieve secure cross-chain communication without relying on trusted intermediaries.

Endpoint Identification

Each blockchain in the Aori network is identified by a unique LayerZero endpoint ID (EID). Orders specify both source and destination EIDs, enabling the protocol to route messages correctly and coordinate settlement across the appropriate blockchain pairs.

Message Security

LayerZero's security model provides multiple independent verification methods for cross-chain messages. This includes configurable security parameters that can be adjusted based on the value and risk profile of the transactions being processed.

Gas Abstraction

LayerZero handles the complexity of cross-chain gas payments, allowing solvers to pay for destination chain execution using source chain tokens. This simplifies the user experience and reduces the operational complexity for solvers.

Settlement Mechanics

The settlement process is designed for efficiency and reliability, handling both successful operations and edge cases gracefully.

Batch Processing

Settlement operations can process up to a configurable maximum number of orders in a single transaction. This batching mechanism shares the fixed costs of cross-chain messaging across multiple orders, significantly reducing the per-order settlement cost.

The settlement payload contains the filler address and an array of order hashes, along with any necessary validation data. This compact representation minimizes message size and reduces transmission costs.

Source Chain Processing

When the source chain receives a settlement message, it validates each order in the batch and processes successful settlements while skipping problematic orders. This approach ensures that one failed order doesn't prevent the settlement of other valid orders in the same batch.

For each successfully settled order, the protocol transfers tokens from the locked balance to the solver's unlocked balance and marks the order as Settled. The solver can then withdraw these tokens at their convenience.

Event Tracking

Settlement operations emit comprehensive events for monitoring and debugging purposes:

event SettleSent(
    uint32 indexed srcEid, 
    address indexed filler, 
    bytes payload, 
    bytes32 guid, 
    uint64 nonce, 
    uint256 fee
);

event Settle(bytes32 indexed orderId);

These events provide complete traceability of the settlement process, including LayerZero message identifiers and fee information.

Cancellation Mechanisms

Aori provides flexible cancellation mechanisms to handle various scenarios where orders cannot or should not be fulfilled.

Source Chain Cancellation

The simplest cancellation path occurs directly on the source chain before an order has been filled. Solvers can cancel orders they've deposited but haven't yet fulfilled, immediately unlocking the user's tokens.

function cancel(bytes32 orderId) external;

This mechanism is useful when market conditions change or when solvers discover they cannot source the necessary liquidity to fulfill the order.

Cross-Chain Cancellation

After an order expires, cancellation can be initiated from the destination chain and communicated back to the source chain via LayerZero messaging. This mechanism ensures that expired orders don't remain locked indefinitely.

Cross-chain cancellation provides a safety mechanism for users whose orders haven't been fulfilled within the specified time window, ensuring they can always recover their locked tokens.