Across protocol security is enforced through ABT bond disputes

Across protocol security is an optimistic settlement model in which a bonded root bundle becomes final unless one honest validator disputes it in time. ABT supplies the proposer and disputer bonds, while UMA’s Data Verification Mechanism decides contested validity; contracts, governance permissions, chain data, and canonical message paths remain separate trust boundaries.

Updated on 2026-08-09

Key takeaway: Three Merkle roots carry separate repayment, rebalancing, and slow-fill consequences, so validators must reproduce every covered chain.

A bounded response path for validators and treasury operators

The bundle-dispute path gives validators a deterministic way to stop contested settlement before root execution begins. Once ProposeRootBundle emits, a monitor reconstructs the bundle and acts before challengePeriodEndTimestamp.

The HubPool stores only one active root bundle, which concentrates review on a single proposal rather than a queue. Its implementation initializes liveness at 7 200 seconds, or 2 hours, and rejects a governance-set replacement of 600 seconds or less. The deployed liveness() value and proposal end timestamp still control the actual window. Execution requires time to be strictly later than that timestamp, while disputeRootBundle() remains callable through the timestamp itself. Across protocol security therefore depends on monitoring latency, complete chain data, and an Ethereum transaction landing before this exact boundary.

How does one honest validator compare with a signing quorum?

Across needs one correct dispute to interrupt an invalid root bundle, while quorum bridges require enough designated verifiers to attest to a message. A related page handles this Across protocol overview.

The phrase “one honest validator” describes an independent Across data checker, not an Ethereum consensus validator. Its dispute doesn’t decide validity alone; it escalates the question to UMA token holders through the DVM. Wormhole takes a different route: its canonical Verifiable Action Approval requires 13 signatures from 19 Guardians, although governance controls the set. LayerZero V2 lets an application choose an X-of-Y-of-N Decentralized Verifier Network policy. These mechanisms place the decisive threshold in different locations: an open challenge followed by oracle voting, a fixed signing quorum, or an application-selected verifier configuration.

For context, Across’s model is especially sensitive to observer availability during liveness. Wormhole’s threshold is sensitive to Guardian independence, while LayerZero’s outcome follows each application’s required and optional DVN choices. None of those comparisons scores a brand; they identify who must notice, approve, and deliver the relevant crosschain state.

ABT bonds price proposal and dispute errors

ABT makes both proposal and dispute errors economically costly while keeping the dispute entry point permissionless for any funded Ethereum address.

Bond token mechanics

ABT inherits WETH9’s 18-decimal accounting and issues one ABT for each ETH deposited, preserving a 1:1 redemption relationship. The HubPool exposes bondToken() and bondAmount(), so automation should read both instead of embedding an amount. A proposer and a disputer each post one configured bond. The HubPool passes a zero reward to UMA. On dispute, the Skinny Optimistic Oracle charges the final fee and burns half of its custom bond.

Approval and loss paths

An operator starting without ABT completes three Ethereum contract calls: deposit(), approve(), and disputeRootBundle(). The BondToken owner allowlists proposers through setProposer, but that transfer restriction doesn’t block dispute bonds. If UMA validates the proposal, the disputer gives up its bond; if UMA rejects it, the proposer gives up its bond. The oracle’s final fee and burned bond reduce the winning payout.

Worked example

This worked example uses these hypothetical changing inputs: bondAmount() is 0.45 ABT, the final fee is 0.01 ABT, the validator holds 0.10 ABT, its gas reserve is 0.02 ETH, and 20 minutes remain. The validator deposits 0.35 ETH to mint the shortfall, keeps 0.02 ETH for gas, and therefore needs 0.37 ETH of working balance. It approves 0.45 ABT. The oracle’s custom bond is 0.44 ABT, and half of it, 0.22 ABT, is burned. If the DVM favors the disputer, the payout is 0.44 plus 0.22 plus the returned 0.01 final fee, equalling 0.67 ABT. A proposer-favoring outcome costs the disputer 0.45 ABT.

What exactly must a validator reconstruct?

A validator must rebuild every covered chain’s deposits, fills, block ranges, fees, and resulting Merkle trees from on-chain events.

Seven bundle checks

On the operational side, Across defines seven core checks: fill validity, deposit matching, no double-counting, block-range correctness, rebalancing, slow-fill accuracy, and fee calculations. UMIP-157 specifies the original V2 bundle rules, while UMIP-179 extends validation for V3 intents, exclusivity, embedded actions, and updated fees. Archive-capable RPC access matters because a validator replays historical events across every chain in the proposal. A root comparison based on incomplete logs isn’t reliable evidence for risking a bond.

Three roots and their consequences

Each proposal carries three 32-byte Merkle roots. The pool-rebalance root moves liquidity between HubPool and SpokePools; the relayer-refund root encodes repayments; and the slow-fill root covers deposits awaiting protocol fulfillment. The event also carries evaluation block numbers and an 8-bit pool-rebalance leaf count. HubPool tracks claims in a 256-bit bitmap, so validators must reproduce both root content and leaf organization.

Permissions that sit outside the bond game

On those terms, Across protocol security includes owner-controlled settings and upgrade paths that ABT economics don’t adjudicate through a root-bundle vote. A further page states it Across protocol essentials.

Seven owner-gated HubPool actions directly shape bundle security: pausing, emergency deletion, bond changes, liveness changes, identifier changes, cross-chain contract changes, and relayed SpokePool administration. BondToken ownership separately controls which addresses may propose, whereas disputes remain public. SpokePools use UUPS upgradeable proxies and treat HubPool as their cross-chain administrator, so a stable proxy address doesn’t mean immutable implementation code. Events such as Paused, BondSet, LivenessSet, ProposerModified, and CrossChainContractsSet expose these changes for monitoring. OpenZeppelin audit work covers contract versions, while later upgrades create a new code-state boundary.

Contract, asset, and message-path boundaries

Contract code, token behavior, and crosschain delivery form separate trust boundaries, and a valid ABT dispute covers only the proposed bundle’s correctness.

HubPool coordinates settlement on Ethereum, while SpokePools enforce deposits, fills, refunds, and slow fills on their own networks. Chain identity is part of the evidence: Ethereum is chain ID 1, Optimism is 10, Base is 8453, and Arbitrum is 42161. Adapters and canonical bridges carry roots or rebalance instructions between those contracts. Token semantics add another boundary because fee-charging ERC-20 assets disrupt accounting, ERC-777 behavior can make accounting functions revert, and upgradeable token contracts can change after a route is approved. A matching Merkle root doesn’t remove those dependencies.

Regardless of the route taken, Across V4 adds proof-based delivery through Succinct SP1 and SP1 Helios after the optimistic bundle becomes final. That flow waits about 12–15 minutes for Ethereum finality, uses a sync committee with 512 validators, and submits two destination transactions. Those figures describe message verification and execution, not ABT adjudication. The optimistic challenge still determines which HubPool bundle becomes eligible for delivery.

Which signals justify an immediate bundle review?

Root mismatches, governance-setting changes, and inconsistent chain data justify an immediate review before the bundle’s challenge window closes.

The strongest signal is a different independently reconstructed Merkle root. Gaps or overlaps in evaluation block ranges, a fill counted twice, an unmatched deposit, an incorrect token route, or a fee-calculation difference explain where to inspect next. A new BondSet, LivenessSet, IdentifierSet, ProposerModified, or CrossChainContractsSet event requires the validator to refresh its baseline; the event alone doesn’t prove the bundle is wrong. Conflicting RPC results call for a second archive provider and block-hash comparison. The remaining liveness, rather than the perceived severity, sets the response deadline.

A response sequence and the operator fit

Independent validators need a rehearsed three-stage response that separates evidence capture, bond submission, and post-dispute tracking.

Before the window

Run the Across dataworker in validation mode with archive RPC coverage for every supported proposal chain. Pin the software revision and configuration, maintain an Ethereum signer, and, when bondToken() returns ABT, keep enough ETH to mint bondAmount() plus gas. Alert on proposal and administration events rather than polling a web interface alone.

When roots diverge

Preserve the proposal transaction, evaluation block numbers, emitted roots, expected roots, and validator logs. Recheck the same ranges through an independent provider, then query bondToken(), bondAmount(), liveness(), and the active end timestamp. If the mismatch persists, mint any ABT shortfall, approve the exact HubPool spend, and submit disputeRootBundle() before expiry. The call deletes the pending proposal immediately, allowing a replacement bundle while UMA resolves the disputed one.

After escalation and operator fit

Track RootBundleDisputed separately from RootBundleCanceled, preserve the DVM request context, and reconcile the eventual bond movement. Integrators should also distinguish a user’s destination fill from the later relayer settlement that the bundle controls. Running this role fits infrastructure teams, relayers, treasury operators, and protocol monitors with continuous multi-chain data access. Ordinary bridge users receive little benefit from posting bonds themselves; the validator role belongs with teams that can maintain evidence and an Ethereum signer throughout every liveness window.

Across protocol security questions worth asking