Intents Architecture in Across

Across' Intents Architecture

Across' cross-chain intents architecture can be distilled into a 3-layered system: a request for quote mechanism to house users' intents, enabling a competitive network of relayers to bid, claim and fill those orders, and lastly a settlement layer to verify intent fulfillment and repay relayers.

Below is a diagram of the planned architecture of Across after implementing a RFQ price auction to enable gasless orders and cross-chain swaps:

Users Request Quotes to Fill their Intent

1. User receives a quote from a relayer to fill their order, and signs (no onchain transaction).

Across' current RFQ implementation does not include gasless orders or cross-chain swaps via a RFQ as depicted in steps 1, 2a, 2b, though these are planned upgrades.

Across' quoting currently has fixed fees and relayer competition is strictly based on a speed.

All other steps are identical to Across' current architecture.

Relayer Network Fills User

2. (a) Relayer claims the order and executes the sign order (b) bringing the transaction on-chain and the users' assets are escrowed via into the SpokePool. The structure of Across orders can be found in Intent Lifecycle in Across.

3. (a) Relayer calls fillRelayV3 on the destination SpokePool with their own assets which (b) are then transferred to the user. During this step relayers also specify which chain to take repayment on.

Settlement System Verifies Fills and Repays Relayer

4. Over a 90 minute window, the Dataworker ingests deposit events, matches them to valid fill events (i.e. fills that meet the intent order requirements). All valid fills are aggregated into a relayer repayment "bundle" and optimistically proposed for verification.

5. If no disputes occur during the challenge period, the Dataworker executes the bundle on the HubPool which then routes repayment instructions to the various SpokePools to repay relayers.

6. Relayers are repaid after a short delay.

Modular Intents Settlement Layer

RFQ systems can and will be external to Across, and will have different mechanics than the Across RFQ.

• Across implements a specific type of RFQ for the Across Bridge, but any other auction mechanism that produces a transaction or signed order recognized by the Across SpokePool is supported in Across' Settlement Layer.

Relayers compete to fill intent order flow and are external to Across.

• Risk Labs (the team building Across) builds and runs an open source implementation of a relayer to support the Across Bridge and other intent systems, and to accelerate the expansion of the relayer network.

• Relayers subscribe to and fill orders from multiple systems, have different service offerings (e.g. same-asset transfers vs. cross-chain swaps) and different profit motives.

Settlement is the core offering and advantage of Across' architecture.

Across can accept any cross-chain intent based order flow and provide settlement (escrow, verification and repayment). The order only needs to be able to be translated into a structure SpokePools recognize. Across Settlement provides two core advantages, which ultimately leads to better execution of intent fulfillment for users and relayers:

• Aggregated and Optimistic Verification: As described in steps 4-6 in the above diagram, Across Settlement system aggregates valid fills events off-chain to create a repayment bundle, which is then optimistically verified by UMA's Optimistic Oracle. This verification and repayment mechanism scales gas cost of repayment at O(1) instead of O(N) with the number of fills. This offers an order of magnitude in gas savings vs. other approaches and ultimately leads to better pricing for users and more profit for relayers.

• Relayer Cross-chain Management: With Across' settlement architecture, repayment is made on the relayer’s chain of choice, reducing overhead and complexity of managing cross-chain positions. This lowers costs for relayers enabling better pricing and execution for end-users. It is enabled by Across' Hub and Spoke model, where passive LPs extend loans to relayers for taking on time-value risk as funds are rebalanced through canonical bridges by the protocol.