Bridges add interoperability by adding a new trust layer
Cross-chain bridges are not neutral plumbing. They decide who can attest a deposit, who can mint on the destination chain, who can unlock on the source chain, and who can upgrade or halt the system. That is why bridge analysis should start with control surfaces, not marketing claims about speed. A 2024 bridge survey of 60 bridges and 34 exploits found that bridge architectures generally offer weaker security guarantees than the chains they connect, while Wormhole, Axelar, and LayerZero each document distinct validator, governance, or configuration assumptions in their own designs.
Bridges matter because liquidity, users, and applications are spread across incompatible execution environments. That is the practical problem of blockchain interoperability. Ethereum, Solana, BNB Chain, Cosmos zones, appchains, and rollups do not share a single state machine. If value is going to move across them, some system has to translate a fact on chain A into a valid claim on chain B. BNB Chain’s current bridge guide makes this explicit by framing its own bridge front-end as an aggregator over route providers rather than a single universal bridge operator.
The economic point is simple. A bridge does not just move assets. It defines a new liability structure around those assets. Once a token becomes bridged, wrapped, fronted by a relayer, or represented through an app-specific mint, users are no longer holding only the source-chain asset. They are holding a claim on a cross-chain mechanism. That claim can be strong, narrow, and transparent, or it can be weak, discretionary, and opaque. The difference shows up only when something breaks.
Most bridges do not move the original asset
The classic bridge model is lock-and-mint. The canonical token is escrowed or locked on the source chain, and a wrapped representation is minted on the destination chain. Axelar’s whitepaper describes this as a transfer where validators observe the source-chain deposit and then sign a destination-chain transaction sending pegged tokens to the recipient. Wormhole’s wrapped transfer flow similarly requires token registration and creates a corresponding wrapped asset on the destination chain.
Wrapped tokens are economically useful and structurally fragile. They are useful because they let liquidity appear where the original asset does not natively exist. They are fragile because their value depends on the bridge’s custody, message verification, and redemption logic remaining intact. Wormhole now distinguishes between Wrapped Token Transfers and Native Token Transfers. That distinction is important. Wormhole’s docs state that WTT is the more permissionless path, but the wrapped token contracts are managed by Wormhole Governance. By contrast, NTT is designed so token teams retain ownership and define cross-chain policies themselves.
That does not eliminate trust. It relocates it. With WTT, users rely on Wormhole governance over the wrapped representation. With NTT, users rely more directly on the issuer’s own policy and upgrade process. The trade-off is not decentralization versus centralization in the abstract. The trade-off is third-party bridge governance versus issuer-controlled bridge policy.
A different model is liquidity or intent-based bridging. Across does not mint representative assets for the user path it advertises. Its docs state that the protocol “exclusively transfers canonical assets” and that relayers front capital on the destination chain before being repaid through the canonical bridge path. This reduces wrapped-asset exposure for end users, but it introduces dependence on relayer incentives, canonical settlement paths, and the optimistic oracle system that secures repayment.
The strongest class of interoperability is usually the one that verifies the counterparty chain on-chain instead of trusting an external committee. Cosmos IBC is the canonical example. Cosmos docs describe IBC as relying on light clients that store the information needed to verify the other chain’s state and updates. That is structurally different from a bridge that asks users to trust an extra validator set or multisig outside both connected chains.
Bridge categories are really security and governance categories
Bridge taxonomy is often presented as a product menu. It is better understood as a menu of trust assumptions. The table below is the practical lens that matters for token holders, treasuries, and protocols integrating a multichain asset.
| Model | Representative example | How transfer completes | Main trust assumption | Operator discretion exposure |
|---|---|---|---|---|
| Lock-and-mint wrapped bridge | Wormhole WTT, historical Binance Bridge 2.0 | Asset is locked or escrowed on source chain, wrapped token minted on destination chain | Locked collateral remains redeemable and mint logic cannot be forged | High if bridge governance can upgrade contracts, manage wrapped token logic, or alter redemption behavior |
| External validator or oracle network | Wormhole, Axelar | A separate validator set observes chain state and signs or attests cross-chain messages | Committee honesty and key security | High if the same committee can also pass governance actions or upgrades |
| App-configurable messaging | LayerZero | Messages flow through immutable endpoints, but applications choose verification and execution settings | The application owner chooses a sound security stack | Medium to high because owner or delegate can change libraries, DVNs, peers, and options |
| Optimistic or intent-based bridge | Across, Nomad architecture | Relayers or updaters post state claims that can be challenged within a time window | At least one honest watcher, disputer, or settlement path exists | Lower custody exposure for canonical-asset flows, but still meaningful parameter and dispute-process risk |
| Native light-client interoperability | IBC | Each chain verifies the counterparty through a light client | The chains’ own consensus and client-upgrade rules hold | Lower dependence on external committees, though still exposed to chain-level governance and upgrade risk |
Operator discretion is the quiet variable most users underprice
Admin power is usually the hidden bridge risk. Wormhole’s GitHub security overview states that a 2/3+ guardian quorum can pass messages, set fees, upgrade contracts, and upgrade the guardian set. The same document explains that Wormhole’s emergency shutdown strategy relies on existing upgrade authority via governance to temporarily patch smart contracts during a crisis. That is a coherent operating model. It is also a reminder that “decentralized bridge” does not mean “no one can change the rules.”
LayerZero shows the other side of the design space. Its endpoints are immutable and permissionless, which is a real reduction in protocol-level discretion. But the application layer remains configurable. LayerZero’s docs state that the owner or delegate can manage protocol configurations, and its OApp docs say the owner can change libraries, DVNs, peers, enforced options, and delegate assignments. In other words, protocol immutability does not remove application-level governance risk. It pushes that risk to the token issuer or app owner.
Axelar is a useful case because the project documented the transition openly. An official 2023 governance RFC states that EVM gateway contracts “initially had an upgrade function governed by an offline emergency committee” and proposed moving upgrades to on-chain Axelar governance. That is the real trade-off in bridge design. Early systems want fast iteration and emergency response. Mature systems need tighter structural accountability. Speed helps ship interoperability. It also concentrates trust while the system is young.
Users should therefore ask a bridge question that is simpler than most architecture diagrams: who can change verification, minting, redemption, or pause logic without my consent? If the answer is “a multisig, guardian supermajority, delegate, emergency committee, or foundation-controlled governance process,” then the bridge carries governance risk even if its cryptography is sound.
The major bridge failures were governance and verification failures in practice
Ronin is the cleanest example of validator concentration becoming loss realization. In its April 27, 2022 postmortem, Ronin stated that on March 23, 2022 attackers compromised five of nine validator keys, draining 173,600 ETH and 25.5 million USDC. Ronin also disclosed that Sky Mavis controlled four of the nine validators and that an old allowlist tied to a gas-free RPC path was not revoked. The lesson is not abstract. Small committees plus operational shortcuts can collapse an otherwise respectable bridge model.
BNB Chain’s native Token Hub exploit showed the same problem from another angle. In its October 11, 2022 response, BNB Chain said the attacker forged a proof within the bridge, that 2 million BNB were effectively minted, and that validators coordinated a synchronized pause and resume to limit losses. That response prevented a worse outcome. It also demonstrated that the validator set retained enough coordinated control to stop the chain in an emergency. This is the core bridge trade-off in one incident: fast containment versus credible minimization of operator discretion.
Nomad’s own documentation makes its safety bottleneck explicit. The docs state that the Updater is the only actor in the system that can commit fraud causing safety failure, and illustrate a case where a fraudulent root could authenticate a message sending all escrowed bridge funds to the Updater after the optimistic timeout. Even before one studies the August 2022 exploit details, the structural issue is visible in the design itself: if one role can create a fraudulent root that drains escrow, that role is economically critical infrastructure.
The broader damage was not anecdotal. Chainalysis estimated on August 2, 2022 that $2 billion had been stolen across 13 bridge hacks, representing 69% of funds stolen in crypto that year up to that point. Later research has pushed aggregate bridge-loss estimates higher. The point is not the exact scoreboard. The point is that bridges have repeatedly been the largest concentration point for cross-chain systemic risk.
Bridge choice is token economy design, not just infrastructure
A multichain token is a bundle of issuance rules. The bridge defines whether supply is canonical or wrapped, whether redemption is direct or delayed, whether liquidity fragments across wrappers, and whether a third party can alter message verification or minting conditions. That means bridge architecture belongs inside token economy design. It is not a post-launch integration detail.
The first policy decision is canonicality. Teams should publish which chain hosts the canonical supply, which routes are official, which wrappers are supported, and which are unofficial even if markets create liquidity around them. Without that map, exchanges, wallets, lending markets, and governance participants can end up treating non-equivalent claims as interchangeable.
The second policy decision is control disclosure. Teams should make bridge admin power legible. That means naming upgrade authorities, guardian or validator assumptions, pause rights, delegate rights, and the process for emergency changes. If a token uses LayerZero, users should know whether the OApp owner can change DVNs. If it uses Wormhole WTT, users should know Wormhole governance manages the wrapped contracts. If it uses an issuer-controlled NTT deployment, users should know the issuer keeps that authority.
The third policy decision is collateral quality. Wrapped assets and bridged claims should not be treated as economically identical to native assets when used as treasury reserves or core collateral. That is an inference from bridge structure, not a moral judgment. If redemption depends on a separate validator set, emergency governance, or a bridge escrow contract, then the asset carries a distinct failure mode that must be priced and limited.
For teams planning multichain expansion, a practical checklist is straightforward:
- Map who can mint, unlock, upgrade, pause, and reconfigure the bridge path.
- Prefer architectures that minimize external committees when equivalent functionality is available.
- Separate “canonical token policy” from “front-end route aggregation,” because an official bridge UI may aggregate third-party routes rather than operate them directly.
- Avoid launching on many chains before the team can monitor supply reconciliation, redemption flows, and admin actions in real time.
- Document the exact governance path for emergency intervention before users need it.
At FinDaS, this is where bridge review meets tokenomics consulting in the narrowest possible sense: bridge architecture changes supply accounting, liquidity topology, collateral quality, and governance risk. Any tokenomics advisor reviewing a multichain design should treat bridge selection as a balance-sheet decision. The fastest route is not automatically the safest route. The most flexible route is often the one with the largest residual operator discretion. That trade-off can be acceptable. It should never be hidden.
