Case Study: How UMA Secures Across Protocol

Introduction

Did you know that UMA secures one of Ethereum’s fastest and cheapest crosschain bridges?

This case study explores how Across Protocol uses UMA to settle Intents-based crosschain transactions, repay relayers, and resolve disputes; all with minimal trust assumptions and maximum flexibility.

Ultimately, Across exhibits a unique use case for UMA and provides a reference model for Intents-based crosschain infrastructure powered by decentralized truth, not centralized trust.

Let’s take a closer look.

The Role of UMA’s Optimistic Oracle

UMA’s optimistic oracle (OO) is a decentralized system for verifying real-world data onchain. It optimistically assumes data assertions are correct unless someone challenges it. If data is disputed, it gets resolved by a permissionless voting mechanism, open to participants from anywhere in the world.

UMA provides a reliable and affordable solution to deliver trustworthy data to smart contracts and dApps by combining optimistic verification with economic security.

The OO operates through a lightweight escalation game designed for trust-minimized verification:

1. A proposer submits a data claim to the oracle contract and posts a bond.

2. A short challenge window opens (typically one hour for Across).

3. If the claim goes unchallenged, it is accepted as correct. If challenged, the dispute is resolved through UMA’s Data Verification Mechanism (DVM).

This system allows decentralized applications to verify outcomes with low latency and low cost while retaining strong security guarantees. This architecture is ideal for crosschain protocols like Across, because it enables the trustless verification of messages and outcomes across blockchains without relying on privileged validators or multisigs.

How Across Works as an Intents-Based Bridge

Across is an Intents-based bridging protocol. Intents are user-signed expressions of desired outcomes without a prescription of how they are done. Across empowers users to express a crosschain Intent (such as sending USDC from an L2 like Optimism to Ethereum mainnet) and receive rapid bridging finality, thanks to relayers and UMA’s oracle.

Here’s the core process:

1. A user deposits tokens into a SpokePool contract on the origin chain. This deposit includes the destination chain, recipient address, and an optional relayer fee.

2. A bonded relayer fulfills the user’s Intent on the destination chain by delivering the correct tokens to the specified recipient.

3. A dataworker later aggregates this intent and other fulfilled Intents and submits them to UMA’s optimistic oracle for verification.

Across only uses canonical assets (no wrapped or synthetic tokens). Instead of requiring every bridge transfer to be validated in real-time, it settles in batches through UMA’s oracle. This separation of fast fulfillment and delayed verification provides end-users with a fast, cheap, and secure bridging experience.

Technical Integration: Step-by-Step Flow

The integration between Across and UMA’s optimistic oracle is the backbone of how Intents are validated, and liquidity is managed trustlessly across chains. Across uses a unique variation of OOV3, which is slightly different from OOV2.

Unlike V2, V3 doesn’t implement data requests. Instead, relayer transactions are bundled and asserted directly to the oracle. But Across’ implementation is even more exceptional.

Let’s break down the system in greater depth.

1. User Signals Intent: The process begins when a user initiates a bridge transfer by calling the deposit function on the SpokePool of their origin chain. This onchain action escrows the asset (e.g., 500 USDC on Arbitrum) and logs metadata, including the recipient address, destination chain, and a custom relayer fee. The Intent is now active and visible to the network.

2. Relayer Fulfills Intent: Relayers (independent participants monitoring chains) detect the deposit event and choose whether to fulfill it. The first to act calls fillRelay on the SpokePool of the destination chain (e.g. Ethereum). This relayer transfers the correct asset amount to the user, records the fulfillment, and posts a bond to prevent double claims. This means the user receives their funds within minutes, much faster than canonical bridging would take.

3. Dataworker Aggregates and Submits Batch: The dataworker (a bot currently operated by Risk Labs) scans all SpokePools for fulfilled Intents. Periodically (e.g., every hour), it creates a bundle of filled transfers and encodes them into a claim. This bundle includes:

   • All relayers and the amounts they’re owed.

   • Their preferred repayment chains.

   • Net liquidity movements for rebalancing.

The dataworker submits the transaction bundle to Across’ HubPool contract on Ethereum. Transaction bundles are only sent to UMA if disputed on the HubPool contract.

Here are details on how root bundles are verified and disputed on UMA.

1. Dispute Escalation (Conditional): If a transaction bundle is disputed on the HubPool contract, a price request, proposal, and dispute are all submitted to UMA in one transaction. The bundle structure allows multiple transfers to be validated in one oracle call, improving gas efficiency. Once the dispute is sent to UMA’s DVM, $UMA tokenholders vote on the validity of the transaction bundle, with economic incentives aligned to reward honesty and penalize fraud.

2. Settlement and Liquidity Rebalancing: After the challenge window (in step 3), if the transaction bundle is undisputed, it is optimistically considered valid. Disputed bundles are deemed valid or invalid via UMA’s DVM (step 4). Once a transaction bundle is confirmed valid, Across’ HubPool contract executes repayment instructions, reimbursing relayers from pooled LP capital. At the same time, liquidity is rebalanced across chains using canonical bridges. For example, the user’s original 500 USDC locked on Arbitrum will eventually move to Ethereum via Arbitrum’s native bridge and replenish the pool.

This process converts asynchronous Intents into verified crosschain state updates. It minimizes gas usage, optimizes capital efficiency, and allows fast bridging with a reliable fallback verification.

Security, Latency, and Capital Efficiency

Across’ integration with UMA is designed for speed, security, and efficiency. Here’s how:

• Security: UMA serves as an economic security layer. Relayers do not submit reimbursement claims themselves. Instead, the Risk Labs dataworker monitors fulfilled intents and proposes batched repayment bundles to the oracle. If a bundle includes inaccurate data (e.g., a relayer getting reimbursed for an unfilled or misreported intent), it can be disputed. The dispute process is transparent, resolved by UMA tokenholder votes, and penalizes incorrect assertions by slashing the proposer’s bond.

• Latency: Relayers provide liquidity immediately, front-running the canonical bridge. Most users receive their funds in under 3 seconds. Meanwhile, relayers are reimbursed only after the oracle verification period, meaning they temporarily assume risk for the user’s benefit.

• Capital Efficiency: Across uses a shared liquidity pool on Ethereum. All bridge flows draw from and return to this hub. This reduces idle capital and fragmentation across chains. Because repayments are batched and settled asynchronously, the system dramatically lowers gas costs per transaction compared to validating each transfer individually.

The Optimistic Oracle as a Settlement System for Intents

UMA’s optimistic oracle is well-suited for verifying Intents. The oracle answers the fundamental question: “Did this Intent get fulfilled as expected?” This makes it a versatile layer for building interoperable apps on Ethereum.

As we’ve explored above, Across leverages UMA’s optimistic oracle into a verification and settlement system for crosschain Intents. Rather than simply passing data or acting as a price feed, the oracle verifies discrete actions from multiple chains: “Was this transfer fulfilled? Did the correct party receive the right asset?” This ensures that Across' relayers are repaid fairly.

This model is:

• Chain Agnostic: The oracle can verify events across multiple chains.

• Use Case agnostic: It can verify swaps, contract calls, or governance actions.

• Incentive Aligned: It creates a game-theoretic equilibrium where honest behavior is profitable.

The system is decentralized and trustless. If an actor misbehaves, a third party can always challenge the claim. The honest participant is rewarded, and the system self-corrects.

Beyond Across: How UMA Can Power Other Interop Protocols

Across is just the beginning. UMA offers a quick-start verification and settlement layer for any Intents-based protocol. It allows developers to build secure, trust-minimized systems that verify outcomes across chains without needing to deploy or manage their validator infrastructure.

Projects building crosschain swaps, generalized bridging apps, or other Intent execution frameworks can adopt the same basic model:

• Let users submit Intents.

• Let relayers fulfill them.

• Use UMA’s oracle to verify fulfillment.

• Use bonding and disputes to keep actors honest.

The biggest constraint today is the oracle’s challenge period duration. However, UMA is actively researching enhancements, including AI-assisted escalation, to reduce verification time while retaining trustlessness and security.

Build with UMA

Across is a testament to UMA’s flexibility. The OO works in production, securing Across’ Intents-based bridging at scale and without compromise. The design delivers trust-minimized verification, fast bridging, and capital efficiency all while staying decentralized and permissionless.

Luckily, you can integrate and build with UMA too.

Ready to start building? Begin your journey here.