Across is a cross-chain bridge for L2s and rollups secured by UMA's optimistic oracle.



Supported chains

Ethereum, Arbitrum, Base, Optimism, Polygon PoS, zkSync Era


Auction Design

Intent-centric protocols like utilise a variety of auction mechanisms designed to optimise order execution either in terms of execution quality or speed. By matching buyers and sellers directly without the need for an intermediary liquidity pool the protocols can reduce the impact of front-running and slippage. The design of the auction is crucial because it creates different incentives for Fillers as well as different trade-offs depending on the exact mechanisms used. Commonly used auctions like FCFS are easy for protocols to run and result in fast order execution, however the lack the RFQ-like bid auction window that would allow multiple Fillers to compete with each other on execution quality.


The first accepted solver bid automatically wins the auction irrespective of whether another bid comes in at roughly the same time with a better price or outcome for the user

Auction Openness

The openness of an auction is important in ensuring the trustworthiness of the result and proving there is no collusion between the protocol and Fillers. Open auctions allow all participants to see the auction process in real-time and verify the outcome. This transparency ensures that all bids are considered fairly, the auction rules are followed and the winning bid is the result of a fair and competitive process.


Auctions occur entirely on chain with no auction period of shielded competition window


Open participation

Whilst most protocols are open and encourage free permissionless participation by any entity wishing to contribute bids for orderflow, some may require Fillers to apply and be whitelisted before they can access orderflow. Having a permissioned system increases risks of centralisation and heightens the risk of Censorship and amplifies the consequences of Filler Failure since it is not straight forward to for a new entity step in to provide bids for 'stuck' orders should no Fillers be available.


There are no protocol restrictions on who can act as a Filler.



When interacting with entirely blockchain resident programs (i.e. smart contracts) all transaction originating addresses have theoretically equal opportunity to obtain service (gas fees and block building stages notwithstanding). Intent based protocols incur additional practical complexities and, coupled with a lack of standarisation between how intents are expressed, auctions are run and how Fillers obtain information about orders to fill, results in additional layers of infrastructure needing to be created. Largely, these additional layers are not implemented fully on chain and / or rely on messaging passing mechanisms which can further widen the ways that participation can be limited. Performing some of the calculation, matching or execution logic off chain introduces a potential source of centralisation. Centralisation negates the guarantees of a decentralised system where if only a single participant is acting honestly and rationally, there is a level playing field for all. Depending on the design of an protocol, centralisation can occur through multiple mechanisms like off chain order advertising, order-bid matching, auction execution, cross-chain message passing, permissioned relayers or executors and others.


As auctions are entirely on chain, all details about new orders are public and available to all participants. There are no mechanisms on-chain by which the protocol can prevent an order from being accepted. There are however no penalties to fillers for systematically ignoring address or orders which can indirectly result in censorship. However to prevent this there only needs to be one honest rational filler in the ecosystem to fill the order.

Filler failure

Intent centric protocols require a Filler to submit a bid and execute transfers / actions that a user order specifies. Without at least one Filler facilitating orders, an Intent based protocol is unable to offer a service to users. Having no Fillers to facilitate an order (or all orders) is a existential risk factor for the protocol which is usually mitigated by the protocol running their own simplistic Filler to provide a minimum level of service. However, should there be no Fillers available to satisfy an order or, if all Fillers decline to service a particular order, there is the potential for an order to be trapped in-flight unless another Filler steps in or the facilitating protocol has an “escape hatch” mechanism for the order originator to cancel their order and have their funds returned.


If no fillers are available to fast fill the order, a backup mechanism using the JIT AMM and canonical bridges exists to fill an order (assuming a slow fill is requested prior to expiration). If an order is not filled before expiration time it will expire and can be credited back to the user on the source chain. (See