A bridge is a trust decision with a UI

A bridge button does not tell you what it is.

It presents one field, an amount, and a word like "Bridge" or "Swap." Underneath, two entirely different machines are possible, and they disagree about who has to be honest for your transfer to land.

One machine asks you to sign a transaction against a named, fixed set of verifiers, and everything after that is a claim those verifiers already agreed on. The other takes your signature, hands the work to a competitor you never see, and pays you from inventory somebody else is holding right now. Both are reasonable designs. Neither is visible in the UI. That gap is the actual risk, and the reason a trader cannot treat "I bridged it" as a completed fact.

Two models, described in the documents themselves

The intent model is the one getting the attention, and its standard is worth reading closely. ERC-7683 describes the arrangement without endorsing it:

This ERC standardizes how a protocol describes an order to solvers; it does not standardize or guarantee the security of the protocol that ultimately settles the order.

That sentence is the whole argument in one line. The standard governs how an order is described to a solver, and nothing else. The ERC is equally clear that it leaves settlement open, stating: "This ERC does not require protocols to use a common escrow, settlement contract, or fill function." What you are trusting is therefore never the standard. It is the specific settlement stack the frontend happened to be pointed at.

Across is a documented instance of the intent shape, and its architecture page breaks the flow into three layers. The first is a request-for-quote layer holding user intents, the second a competitive relayer network, the third a settlement layer. The docs are unusually direct about what the competition is actually optimising: "Competitive — relayers compete on speed to fill intents" Not price. Not cost. Speed, with the current implementation described as using fixed fees.

The relayer role is documented as open. Running one is a matter of running software, not passing a gate: "Running a relayer is permissionless — anyone can operate one." The reference implementation is public, the relayer pays out through bundles rather than through a validator set, and the exposure is capital lock-up rather than slashing.

The canonical model is the other shape, and Wormhole documents its assumption with unusual bluntness. The network is 19 named nodes, and a message is valid once 13 of them sign: "Wormhole relies on a set of 19 distributed nodes called Guardians that monitor the state on several blockchains." The signed artefact is a keccak256 hash of the message body, wrapped with the signatures into a Verifiable Action Approval. The docs also state the failure surface honestly: "However, there is always a small chance of an extended reorg that could invalidate or alter a previously emitted sequence number."

That is a nameable assumption, and that is the point. You can state your exposure as "13 of 19 named operators must not collude or all fail on the same chain," and a reader can evaluate that sentence. The Wormhole docs go further and draw the boundary themselves, describing the delivery component as untrusted: "The Executor is considered untrusted in the Wormhole ecosystem. It can affect message availability (timing of delivery) but cannot alter or forge VAAs, as validity is enforced by Guardian signatures." Availability and validity are separated, and only one of them is consensus-protected.

What the intent model removes, and what it puts there

The strongest claim in favour of intent systems is accurate, and it is worth stating precisely. No bonded validator set stands between your order and its destination. Your counterparty is a named solver, and if that solver does not perform, the contract on the source chain does not release your funds. The Across actors documentation frames the same property from the relayer's side, since the relayer fronts its own capital rather than posting a bond for correctness.

What the model adds is dependence on two off-chain parties you did not select. The first is the solver or relayer, who must be willing and able to deliver at the moment your order is live. The second is the settlement layer that eventually reimburses them, and this is where the honest complexity lives.

Across settles optimistically, and its security page is direct about the mechanics. A dataworker aggregates fills, proposes a bundle to the HubPool on Ethereum, and posts a bond, described as: "The dataworker proposes this bundle to the HubPool on Ethereum and posts a bond (denominated in ABT, the Across Bond Token)." A challenge period follows, and if a dispute is filed, "A challenger posts their own bond and the dispute is escalated to UMA's Data Verification Mechanism (DVM) for resolution." So the permissionless relayer is permissionless, and the party that proposes the settlement bundle is not. The same page states it as a design feature: the bond token "restricts which addresses may propose root bundles to the HubPool. This adds a permissioning layer on top of the economic bond requirement."

Read that next to the relayer documentation and the picture is complete. Open entry at the fill step, gated entry at the settlement step. A permissionless race at the front, a bond-token allow-list behind it.

Across also states its liveness assumption in a way that is easy to miss and easy to misread as a safety property, calling the system: "The system only requires a single honest actor to dispute invalid proposals to remain secure." That is a 1-of-N assumption about disputing, not about verifying. It is a claim that one watcher is enough to catch a bad bundle, and it says nothing about whether a bundle gets built at all, or whether the relayer shows up. Anyone can hold the difference between a safety property and an availability property.

The non-atomic experience is the part you will actually feel

An intent fill is not one transaction, and the documentation concedes the timeline. Relayer capital is tied up until settlement, a window the actors page quantifies as "Capital lock-up | Funds are locked until bundle settlement (~1.5 hours)." The refund path is slower still, and the docs warn against setting expectations optimistically: "Refunds are not instant." They put a figure on it: "With ~1.5-hour bundle intervals plus the challenge period and canonical bridge delays, refunds can take several hours to arrive."

There is a second non-atomicity that sits above the timeline, and it is the reason a fast intent transfer is not the same guarantee as an atomic message transfer. In a canonical model, the destination chain either receives a verified message or it does not, and the verification is the thing the network agreed on. In an intent model, your destination-side delivery depends on an off-chain party acting, and a separate oracle or validation layer later tells the source chain that the delivery happened. The destination is not final because a quorum said so, it is final because somebody with inventory decided to act and a validator system later confirmed it.

ERC-7683 names this exposure from the solver's direction, which is the mirror image of yours: "Solvers are exposed to risk from the time they commit capital, approvals, or transactions to an order until their expected payment is final and spendable." Security analysis therefore has to cover the whole window, and the ERC says so in its security considerations, requiring analysis to cover adversarial changes to protocol state, chain state, token behaviour, oracle values, permissions, and message-delivery paths across the full execution and settlement window.

The third architecture, which is a real one

LayerZero V2 is neither of the two shapes above, and lumping it in with a fixed validator set would be wrong.

The verification assumption is per-application rather than per-network, and the docs describe the mechanism as an X-of-Y-of-N threshold over verifier networks: "In this stack, each DVN independently verifies the payloadHash of each message to ensure integrity. Once the designated DVN threshold has been reached, the message nonce can be marked as verified and inserted into the destination Endpoint for execution."

The decision of who verifies is made by the application, not the protocol, and the execution step is separated out and documented as open: "By making the execution of crosschain messages available to anyone, LayerZero ensures that once a message is verified, it can be executed without gatekeepers."

The documented defaults are the part worth flagging for anyone treating "LayerZero" as a single security posture, because the documentation does not present the defaults as neutral. The security stack page states the warning in its own words: "Defaults A, B, and C list LayerZero Labs as a required DVN, and every default uses LayerZero Labs as the Executor." And it declines to treat the defaults as safe by omission: "You should always set your DVN configuration explicitly. Defaults are placeholder configurations — they may be Dead DVNs that prevent message delivery, may include only a single DVN, and may change without notice."

The config guide is blunter about the single-verifier case: "A single-DVN configuration means a compromise of that one verifier results in unrestricted forged messages on the pathway." Its guidance is "Production deployments should use multiple required DVNs from independent operators."

So the assumption here is application-specific and requires you to go read the application's configuration. That is a different task from "count the guardians," and a bridge UI will not do it for you.

What neither model guarantees

Both architectures fail in the same three ways, and the documentation of both is explicit about each.

Neither guarantees availability. Wormhole states that its untrusted Executor can affect message availability, meaning timing of delivery. Across publishes a refund timeline measured in hours. A relayer that does not fill leaves you waiting until a deadline.

Neither guarantees you get the number you saw. The Across relayer layer competes on speed with fixed fees, so the price is not the auction outcome.

Neither guarantees that the observation layer is as wide as the signing layer. Wormhole's delegated Guardian Sets are the honest version of this admission, and the security page describes the gap without spin: "Delegated Guardian Sets introduces a per-chain trust assumption: the delegate quorum threshold determines how many Delegated Guardians must independently agree before Canonical Guardians sign." The 13-of-19 signature threshold is preserved, and the chain being watched is not necessarily watched by all 19. The guardians page states the safeguard, that Canonical Guardians will not sign until delegate quorum is reached, "This prevents a minority of Delegated Guardians from lowering the effective security threshold of a chain."

The intent equivalent is the oracle layer, and LI.FI documents it as an explicit choice rather than a fixed component: "Trust assumptions for the oracle system needs to be explicit, so intent issuers and solvers can make informed decisions." The same page notes the dependency runs both ways: "Users can freely choose which oracle system they want to secure a specific intent, but solvers have to implement it for the intent to be solved."

A consequence follows that is easy to miss. An intent-based system does not remove the canonical verification problem, it relocates it to whichever oracle or validation layer the issuer selected. When a LayerZero-based or Wormhole-based oracle is the thing proving a fill, a canonical threshold assumption is still sitting inside the "permissionless" path. The trust model is a composition, and the parts have to be named separately.

What to actually do

Ask what the button is calling. Not "is this bridge safe" but "which of these two shapes, and whose configuration." If the answer is unavailable, treat the transfer as an unpriced counterparty exposure.

For an intent route, price the delay into your position. Funds are committed on the source chain before they exist on the destination chain. That gap is a real operational state, not a lag, and the documented worst case is hours.

For a canonical route, name the threshold out loud. Nineteen Guardians at 13 is nameable. An application-configured DVN set is nameable once you go and read the config, and the docs say the default is a placeholder that "may change without notice."

Check the two permission layers, not one. In the intent model, entry at the fill step and entry at the settlement step are governed differently, and one of them is an allow-list on a bond token.

Verify the wrapped asset, not just the transfer. A transfer that settles in the right amount of the wrong token is a successful settlement of the wrong thing.

The wider point

Bridging is a trust decision that arrives wearing a button. The intent model genuinely removes a bonded validator set from your path, and that is a real reduction in one specific kind of counterparty risk. It pays for that with dependence on off-chain solvers, a slower non-atomic timeline, and a settlement layer that can be permissioned even when the relayer set is not. The canonical model gives cleaner single-message semantics and a threshold assumption you can write down, and it carries the fixed-operator risk that implies.

Neither is safe in the abstract, and calling either unsafe in the abstract is equally useless. The honest move is to name the mechanism, name its documented limits, and decide whether that specific set of dependencies is one you accept for that specific transfer.

Risk note: cryptocurrency trading, cross-chain bridging, leveraged perpetual futures, and automated algorithmic strategies carry significant risk of rapid and total financial loss. Never risk funds you cannot afford to lose completely. Bridging adds protocol, counterparty, and liveness risk beyond price exposure: an intent route depends on an off-chain solver and a settlement layer before funds exist on the destination chain, a canonical route depends on a named threshold of operators remaining honest and available, and neither architecture guarantees a fill, a price, or a timeline. A wrapped asset can settle successfully and still be the wrong exposure. Nothing in this article is investment advice, a recommendation, or an offer to sell any product.

Sources

• Across, Actors in the System, fetched 2026-10-05: relayer mechanism, permissionless participation, the relayer risk table (gas, capital lock-up, software bugs, finality risk), exclusive relayer fields.
• Across, Security Model and Verification, fetched 2026-10-05: optimistic verification, the 1-of-N disputing assumption, ABT bond and the proposer permissioning layer, ~0.45 ABT bond amounts, UMA DVM escalation.
• Across, Intent Architecture in Across, fetched 2026-10-05: the three-layer split, fixed fees with competition on speed, hub-and-spoke settlement table, optimistic bundle verification.
• Across, Validating Root Bundles, fetched 2026-10-05: what a bundle validator checks (fill validity, deposit matching, no double-counting, block ranges, rebalancing, slow fills, fee calculations), the independent replay and root comparison procedure.
• Across, Running a Relayer, fetched 2026-10-05: the relayer-v3 codebase, required environment variables, inventory and rebalancing configuration, root bundles published every 1.5 hours minimum.
• Across, Refunds, fetched 2026-10-05: refund eligibility at fillDeadline, the non-instant refund warning, the several-hour timeline, refundAddress and refundOnOrigin parameters.
• ERC-7683: Cross Chain Intents, published 2024-04-11, fetched 2026-10-05: the resolver-centric standard, the explicit non-guarantee of settlement security, the solver capital-exposure window, cross-compatibility via ERC-7930 interoperable addresses.
• LayerZero V2, Security Stack (DVNs), fetched 2026-10-05: X-of-Y-of-N thresholds, the default pathway table (A/B/C/D), the LayerZero Labs required-DVN and Executor warning, the Dead DVN explanation, the instruction to set DVN configuration explicitly.
• LayerZero V2, EVM DVN and Executor Configuration, fetched 2026-10-05: the single-DVN forgery warning, the production guidance on requiredDVNCount >= 2 from independent operators, send/receive config matching.
• LayerZero V2, What is LayerZero V2?, fetched 2026-10-05: separation of verification and execution, immutable endpoint contracts, permissionless execution of verified messages.
• Wormhole, Guardians, last updated 28 Sep 2026, fetched 2026-10-05: the 19-node Guardian set, 13-of-19 multisignature attestations, full-set versus delegated observation chains, the delegate quorum safeguard, the Proof-of-Authority framing.
• Wormhole, Verified Action Approvals (VAAs), fetched 2026-10-05: VAA construction from a two-thirds Guardian supermajority over a keccak256 body hash, the (emitter_chain, emitter_address, sequence) uniqueness caveat, the reorg exposure, destination-agnostic multicast verification.
• Wormhole, Security, fetched 2026-10-05: core security assumptions, the Executor as untrusted for availability only, the per-chain delegated Guardian trust assumption, two-thirds governance threshold.
• LI.FI, Intent System Overview, fetched 2026-10-05: the three components (Input Settler, Output Settler, Oracle System), escrow versus Compact resource locks, efficientRequireProven, the canonical-solver rule for multi-output orders.
• LI.FI, Oracle Systems, fetched 2026-10-05: self-serve versus automatic versus same-chain validation layers, the requirement that trust assumptions be explicit, the issuer/solver implementation dependency, the speed-and-price note on capital rotation.
• LI.FI, Settlement, fetched 2026-10-05: the two input settlers, fill-first resource locks versus escrow-first flows, finalise and finaliseWithSignature, OutputSettlerSimple and its four order types.
• LI.FI documentation index, last updated May 2026, fetched 2026-10-05: LI.FI's stated scope as a routing layer over bridges, DEX aggregators, and intent solvers, the intents order lifecycle (Signed → Delivered → Settled), the order server and refund-on-expiry behaviour, the security page summary.