Across — A Deep Dive - All You Need to Know About Across

By LI.FI | LiFi | 9 May 2022

Powered by UMA protocol’s Optimistic Oracle, Across is the preeminent solution for bridging from Optimistic rollups to Ethereum Mainnet in a cheap, secure, and decentralized manner. With Across, users can instantly send assets from Layer 2 rollups to Ethereum’s Mainnet.

In this article, we will cover the following:

  • Across: An Overview
  • Across’ Bridge Design and Architecture
  • How It Works — Transaction Lifecycle
  • Security Model
  • Incentives
  • LI.FI Evaluation Model
  • Supported Chains and Assets
  • Team and Community
  • Closing Thoughts

Let’s dive in!

Across: An Overview

Across is the brainchild of the engineers behind the Universal Market Access (UMA) protocol and is powered by UMA’s Optimistic Oracle, which allows smart contracts to use off-chain data in a decentralized, economically secured manner.

It is a bridging solution that facilitates near-instant transfers from Layer 2 rollups to Ethereum. The bridge was designed to speed up the transfer of assets from L2 to L1, as native Optimistic rollup bridges can take up to a week to finalize transactions due to the current parameters regarding dispute periods. Across claims that, on average, users can expect to receive funds in 1–2 minutes. This is a significant improvement for users as they don’t have to wait for a week to bridge their funds. Furthermore, Across was built with affordability in mind and prides itself on offering the cheapest solution in the L2 → L1 bridging world

(Authors note: Across V2 is coming out soon, which will support L2 <-> L2 and L2 <-> L1 bridging. However, as of writing time, V2 has yet to be released, so this report is focused on Across’ ability to bridge from L2s -> Ethereum Mainnet).

Across’ Bridge Design and Architecture

Across combines single-sided liquidity pools, bonded Relayers, and UMA’s Optimistic Oracle to bridge assets from L2s to Ethereum’s Mainnet in a decentralized, secure, and cheap manner. Let’s take a closer look at Across’ architecture:

Liquidity Pools

Liquidity pools are essential to Across’ functionality. They allow users bridging from L2 to L1 to gain immediate liquidity on L1 — even though an Optimistic rollup bridge may take up to seven days to validate. For this service, liquidity providers are paid a fee for each transfer. In essence, liquidity providers are issuing a short-term loan to bridgers and receive an interest rate via fees.


The actual bridge mechanism of Across is dependent on entities called “Relayers.” The Relayers, as the name suggests, are actors that report information about transactions going from L2 to L1.

Note: Because of the nature of blockchains, Across expects that most Relayers will be automated bots. Manual relays are possible but will most likely only be possible for users with an in-depth understanding of blockchain tooling.

A Relayer’s main job is to report transaction details to UMA’s Optimistic Oracle (which we will analyze in the next section.)

To do so, Relayers post a bond to the UMA Optimistic Oracle, which is necessary to use the oracle (very much like it is required to stake ETH to participate in proof-of-stake on ETH 2.0). From there, Relayers report L2 transaction details to the Optimistic Oracle.

Once a Relayer attests to transaction details and no other Relayer disputes the truth of the transaction, withdrawals from the liquidity pool on Ethereum are unlocked. The Relayer can then complete two types of bridging actions, “slow” or “fast.”

  • Fast relays, which happen most often on Across, occur when a Relayer advances funds to a bridger and gets reimbursed from the liquidity pool after the dispute period.
  • Slow relays occur when a Relayer claims that a particular deposit happened on L2, but it did not have the funds at hand to front the transaction. Slow relays can take up to two hours, while fast relays can be nearly instantaneous. Because of this difference in duration, fast relays are more expensive.

Optimistic Oracle

Across is powered by UMA’s Optimistic Oracle. The Optimistic Oracle is used to resolve disputes on Across — meaning that it is in charge of deciding whether or not the details posted by a Relayer about the transaction coming from an L2 to L1 is correct.

The Optimistic Oracle was initially built as a price oracle for transactions and is known for enabling smart contracts to utilize off-chain data in an on-chain manner. Interestingly, this makes it a perfect mechanism for chain-to-chain transactions, as moving L2 tokens to L1 is essentially the same as moving completely off-chain data to an L1.

To summarize: The Optimistic Oracle allows any Relayer to dispute invalid transaction details reported by another Relayer. Once disputed, the Optimistic Oracle funnels the data through a data verification system that relies upon UMA token holders to settle disputes. Any Relayer that successfully disputes transaction details of another Relayer may then claim the original Relayer’s bond. With this type of infrastructure in place,

  • anyone can be a Relayer, meaning Relayers will be decentralized in the long term
  • Relayers are incentivized not to propose inaccurate L2 -> L1 details because if the proposed information is disputed and deemed incorrect, the Relayer’s bond will be slashed
  • if a Relayer is incorrect, the Optimistic Oracle mechanism should catch the mistake and allow the user to seek recourse, meaning that a user’s funds are never lost

Essentially, “UMA’s oracle mechanism allows anyone to dispute invalid relays during the challenge period and claim the relayer’s bond if the relay was incorrect,” as Across’ docs summarize.

How It Works — Transaction Lifecycle

Now that the groundwork has been laid out, here’s how an Across transaction works:

  • Across gathers enough tokens in a liquidity pool on Ethereum Mainnet to facilitate as many “fast” relays as possible.
  • Bridgers on L2s ask to move assets from L2 → L1
  • A Relayer posts a bond, along with the details of the transaction
  • The Relayer can then decide to either make it a “fast” or “slow” relay
  • UMA’s Optimistic Oracle allows anyone to go in and dispute whether the above transaction is correct
  • Once the L2 → L1 transaction goes through, the bridger pays the liquidity provider a fee (and if it was a “fast” transaction, then they also pay an extra fee to the Relayer)
  • 7d775fb4361c1c6da56692a466a185cba3e2a2b1444d77885159c6827b880bbf.png


Across Fees

Across users will experience two separate fees per transaction.

  1. Liquidity Provider Fees — With Across, users are gifted immediate liquidity on L1, even though native optimistic bridges can take up to a week to settle. In essence, Across’ L1 liquidity pool fronts the cost of liquidity in the short term. To make this worth a liquidity provider’s time, Across charges a fee on the bridging transaction based on Aave’s pricing model — meaning a liquidity provider’s fee is roughly the estimated interest payment someone would have to make on a seven-day loan from Aave on a given asset and the rate increases subject to a pool’s utilization, just like on Aave.
  2. Relay Fees — There are two types of relay fees. Slow relay fees are optional fees that a user can pay to incentivize a Relayer to acknowledge and report their L2 → L1 bridging transaction. If there are no disputes, this transaction will go through in two hours. Instant relay fees incentivize a Relayer to instantly pick up, report, and front the transaction to the bridger. For context, in a fee example on Across’ website, to bridge 1 ETH from an L2 to an L1, Across calculates a liquidity provider fee of .000939 ETH, .001 ETH for a slow Relayer fee, and .01 ETH for a fast Relayer fee.

Security Model

On the cybersecurity side, Across has completed an audit from OpenZeppelin in December of 2021. UMA and Optimistic Oracle have undergone multiple audits and have a bug bounty that could extend to 10% of funds at risk.

The overall security of Across rests in the hands of UMA’s Optimistic Oracle, which is how Across confirms that transactions from L2 to L1 are correct.

As its name hints, the Optimistic Oracle is fundamentally designed to believe that every transaction is correct unless it is disputed. The process for using the Optimistic Oracle goes as follows:

  1. The Relayer for a specific transaction reports the transaction details and posts a bond to the Optimistic Oracle attesting to the details of the transaction.
  2. If a transaction remains undisputed by all Relayers in the system, then the Relayer’s bond will be returned to the Relayer and they will also be given the Relayer fee (described in the Fees section).
  3. If it was an instant relay, they would also be reimbursed for the amount advanced to the depositor.

Let’s take a pause here to note that many of the transactions on Across are “fast” relays. This is another layer for user security because user funds are rarely at risk. Instead, with the Relayer fronting the initial bridge transaction, they essentially take on the risk of the initial bridger in the case of a disputed transaction.

“In our optimistic approach, the Relayer accepts the relay and provides a loan to the user. The Relayer is fronting the money to the user because it trusts UMA’s Optimistic Oracle…The Relayer is trading places with the user in the sense that they’re willing to wait for the challenge window to complete… By providing the funds upfront, we are able to provide the level of speed that you know and love from Across, with no compromise of safety.” — Lana Foglio, Across Medium.

Ok, now let’s proceed back to the Optimistic Oracle. What happens if a transaction is disputed?

  • If a transaction is disputed, the Optimistic Oracle will resolve the conflict via an UMA token-holder vote. This is a somewhat complex process, but it boils down to UMA token holders voting on data submitted to the Optimistic Oracle by both a proposer Relayer and a disputer Relayer via its “Data Verification Mechanism” (DVM), which is secured by UMA tokenomics.

As described by UMA’s documentation:

“UMA’s oracle system is constructed with economic guarantees around the cost of corrupting the DVM to ensure it will cost more to corrupt the oracle (i.e., obtain 51% or more UMA tokens) than the amount someone could profit from corrupting the oracle (i.e., stealing funds within contracts on UMA).”

The process (outlined below) takes between 48 and 96 hours.



To summarize, the structure of the Optimistic Oracle boils down to the following two bullet points:

  • Multiple bots, or Relayers, are active and fact-checking each other at all times. These bots will notice any discrepancies in prices and can force human intervention. As long as one bot is checking and disputing malicious transactions, then the system should work.
  • UMA token holders are incentivized to vote and vote correctly on any disputed transaction as they can claim more rewards if they’re on the winning (or correct) side of the vote. Furthermore, bad-acting Relayers will see their bonds slashed.


Each actor within the Across ecosystem is correctly aligned with good actions. Here are a few examples of how Across has structurally incentivized its design:

  • Token holders — UMA protocol token holders are incentivized to vote correctly regarding disputed Across transactions to maintain the integrity of the Optimistic Oracle, which is the main feature of UMA protocol, along with the integrity of UMA’s token, UMA.
  • Relayers — Relayers are incentivized to report layer 2 deposits correctly because their bond can be slashed if the information is incorrect, leading to less funds overall.
  • Liquidity Providers — Liquidity providers are incentivized to keep the liquidity on Ethereum’s Mainnet at a deep level in order for larger transactions, and therefore, larger fees, to cross from L2 to L1 instantaneously.


As a dApp developer integrating an external tool, the biggest risk is always the reliability of the tool and the underlying trustlessness of any of the systems the tool implements. In the case of Across, here are the most significant integration risks:

  • Smart contracts — though Across’ bridge contract is audited and straightforward, there are always risks when humans write something.
  • Bridge design and architecture — bridges now account for the three largest DeFi hacks in history. This is bleeding-edge infrastructure, and exploits are part of the business.
  • Reliance on UMA — if the economic incentives protecting UMA’s Optimistic Oracle are manipulated, then Across, which is dependent on UMA voters acting correctly, would also fail. To use Across, users must trust UMA.
  • Layer 2 demand and liquidity — Across facilitates L2 → L1 transactions. This assumes that users will want to move to Ethereum Mainnet for finality and that Ethereum, in general, will retain its place as a top blockchain. While this seems like a good bet in the short term, it is worth noting that various L1s hold much more TVL than Ethereum L2s.
  • Relayer centralization — Across’ decentralization model relies on anyone being able to build a Relayer bot and participate in the mechanics of bridging. However, this is a technical skill, and, as of writing, no readily available data exists on the distribution, maintenance, or trustworthiness of different Relayers.

LI.FI Evaluation Metrics



Let’s evaluate Across’ design according to the following attributes:

  • Security — Across’ design heavily depends on UMA’s Optimistic Oracle being a secure, decentralized, and fair system. The Optimistic Oracle has never been exploited, allows for multiple bots that anyone can run to fact check each other, and has facilitated fair votes for numerous years. In theory, Optimistic Oracle provides economic guarantees of correct voting and a reliable way to settle disputes native to Optimistic crypto solutions. Furthermore, its historical lack of exploits and a robust set of audits is a major plus. That being said, being so reliant on Optimistic Oracle could be seen as an issue. While it has yet to be exploited, there are known issues, such as a “bribery attack,” that could affect the integrity of Optimistic Oracle. To summarize, the security of Across is trust minimized — but is dependent on UMA protocol continuing to progress as a decentralized system as well.
  • Speed — Across significantly improves the speed for transfers from Optimistic rollups from L2 to L1 by allowing Relayers to tap into its liquidity pool to instantly front transactions. This mechanism speeds up a bridging process from 7 days to, at the maximum, two hours for slow relays, while fast relays can be as fast as 1–2 minutes.
  • Connectivity — Across is limited to Ethereum and Ethereum L2s designed as Optimistic rollups. For now, it only supports Arbitrum, Optimism, and Boba, along with Ethereum. Furthermore, Across only offers bridging for seven tokens, which is a somewhat limiting number.
  • Capital Efficiency — Across is capital efficient in that it allows anyone bridging from an L2 to Ethereum to instantly draw upon liquidity if a Relayer passes through a transaction without dispute and decides to front it. Funds are stored on Ethereum, but can be used equally on any of the three supported chains without bias. Furthermore, since routes are limited, liquidity can be used efficiently.
  • Statefulness — Across’ statefulness, or the amount of information it can share between chains, is limited. Across’ main webapp allows for L1 <-> L2 transactions, but routes the transaction through a native bridge (which is slow). Furthermore, as of now, Across does not support L2-L2 transactions. That being said, with V2 of Across coming out soon, L2<->L2 transactions, along with L1 <-> L2 transactions will be supported. Therefore, this rating will be temporarily lower than what it would be in 6–8 weeks.

Supported Chains and Assets

Across is a one-way bridge for Optimistic rollups to Ethereum Mainnet. Across currently supports Optimism, Arbitrum, and Boba Network, along with, of course, Ethereum.

Token-wise, Across supports:

  • Wrapped Ether (wETH)
  • USD Coin (USDC)
  • Ether (ETH)
  • Wrapped Bitcoin (wBTC)
  • UMA Token (UMA)
  • BadgerDAO (BADGER)
  • Boba Network (BOBA)
  • Dai (DAI)


As mentioned above, Across was spearheaded by a group of UMA engineers at Risk Labs, specifically Nick Pai and UMA co-founder Hart Lambur, who wanted to create a non-financialized use for the Optimistic Oracle.

Since then, UMA has decided to fully open-source its code and give up the project to the community. They call this a “fair fair launch.” According to Across’ Discord channel, anyone who joins the community has a chance to become a co-founder.

Furthermore, Across promises that any future token will be designed publicly and by the community. As of writing, the team has 5,000+ co-founders (based on Discord clicks). After creating a good consensus mechanism, token drop plan, and development team, the protocol will be given over to Across DAO.


You can stay updated about Across and its community through the following:

Closing Thoughts

Across is one of the best bridging solutions in the cross-chain ecosystem. It is a decentralized, cheap, and secure way to move funds from Optimistic layer 2 solutions to Ethereum’s Mainnet.

We’re excited to integrate Across into LI.FI and offer its features to our users. We believe the vision and values of both teams are aligned toward creating a highly interoperable cross-chain ecosystem. We look forward to working closely with the Across team to build critical infrastructure for the cross-chain future.

  Get Started with LI.FI Today:

To learn more about us,

or try our any-2-any swaps NOW at

How do you rate this article?



The ultimate cross-chain liquidity aggregator, aggregating cross-chain liquidity networks to DEXs, calculating you the best cross-chain swaps. The future is cross-chain and we make sure you don't have to care. #DeFi


The ultimate cross-chain liquidity aggregator, aggregating cross-chain liquidity networks to DEXs, calculating you the best cross-chain swaps. The future is cross-chain and we make sure you don't have to care. #DeFi

Send a $0.01 microtip in crypto to the author, and earn yourself as you read!

20% to author / 80% to me.
We pay the tips from our rewards pool.