Across Docs
User Docs

Roles within Across

Learn about the key roles in Across' system.


A user is someone who bridges assets between L2s and L1 with Across. Users pay relayers and liquidity providers in order to send their tokens instantly across networks that support their token. You can find a step-by-step explainer on bridging here.

Liquidity Provider

A liquidity provider or LP is an actor who deposits assets into one of the pools on Liquidity Providers insure user funds in exchange for fees. You can find the step-by-step process for liquidity providers here.


Relayers give out short-term token loans to Users in exchange for fees. Relayers fulfill deposit requests by sending the depositor their desired token on their requested “destination chain”. Relayers will send the recipient the full deposit amount minus a relayer fee, meaning that they will keep the relayer fee as an incentive for crediting the depositor funds. You can find more information on relayers here.


Dataworkers support stability and healthy functioning of the system by refunding relayers and moving system assets between networks. Dataworkers are in charge of proposing "bundles" to be optimistcally validated by the Across system. Each bundle contains instructions for:
  • Refunding relayers for valid fills
  • Sending tokens to SpokePools that can be used to pay such refunds
  • Sending tokens to SpokePools that can be used to execute slow fills
  • Withdrawing funds originating from deposits on SpokePools back to the HubPool
Each bundle has a list of "bundle end blocks" that mark the last blocks per SpokePool chain queried for that bundle. The start blocks are equal to the previous bundle's end blocks + 1. The bundle end blocks can be used to verify that the bundle's are correct for the data contained within the bundle's block range.
Finally, the bundle's summarize their instructions via merkle roots, so each bundle contains:
  • bundle end blocks
  • pool rebalance merkle root: instructions for net inflows/outflows to each spoke pool
  • relayer refund merkle root: all relayers that need to be refunded and their aggregate refund
  • slow relay merkle root: which deposits need to be slow filled because a relayer hasn't fully filled it
The dataworker's responsibility is described in this UMIP and a reference implementation can be found here. An example proposal transaction can be seen here.