Bridges: Moving Between Networks

:::section{mins=7} Why Bridges Exist :::

:::p{html} Open a [[gloss:wallet|wallet]] with several networks connected and you'll notice something odd: the same-looking token sits in separate piles. [[gloss:ethereum|ETH]] on [[gloss:ethereum|Ethereum]], [[gloss:ethereum|ETH]] on Arbitrum, [[gloss:ethereum|ETH]] on Base – these are three different balances, and you can't shuffle between them with one tap. The reason is that each [[gloss:blockchain|blockchain]] is an isolated system with its own state and its own rules. [[gloss:ethereum|ETH]] on Arbitrum physically does not exist on [[gloss:ethereum|Ethereum]], and USDC on [[gloss:ethereum|Ethereum]] is a different contract from USDC on Base, even though they look identical. Sometimes the difference is right there in the name: a token tagged like USDC.e on Arbitrum is a "bridged" version, a wrapper over the original USDC, not the same coin Circle issues on [[gloss:ethereum|Ethereum]]. Inside one network you [[gloss:move|move]] tokens between addresses freely; between networks there is simply no shared space. :::

:::p{html} A bridge is a protocol that takes on the job of safely moving your asset from network A to network B, coordinating two independent blockchains that know nothing about each other on their own. It does not "forward" the coin in any literal sense – we'll see in §2 what actually happens – but to you the result looks like a transfer: you hand over [[gloss:ethereum|ETH]] on one side and receive an equivalent on the other. This is critical multichain infrastructure: as long as networks don't share state, bridges are unavoidable (a point we made in 2.6 §4) – without them, hundreds of networks would stay locked islands, and liquidity could not flow to where it's needed most. :::

:::p{html} The scale of this infrastructure is enormous: hundreds of millions of dollars cross bridges every day, and tens of billions over the years. And this arrangement has a cost newcomers rarely notice at first. The more networks you operate in, the more your capital splinters: $200 on Arbitrum, $150 on Base, $90 on Optimism – each amount too small on its own to do much with once fees are counted. This liquidity fragmentation isn't a theoretical protocol problem but a thoroughly everyday one: you spend time and [[gloss:gas|gas]] just to gather your own money into one place. Bridges solve that, but each such "gathering" is a separate operation with its own fee and its own risk. :::

:::p{html} In practice you need a bridge in a few typical situations: :::

:::p{html}

• From an exchange to an [[gloss:layer 2|L2]] – withdraw [[gloss:ethereum|ETH]] from Coinbase or Binance straight to Arbitrum, to skip [[gloss:ethereum|Ethereum]]'s expensive fees.
• Between [[gloss:layer 2|L2s]] – [[gloss:move|move]] from Base to Optimism chasing a better yield or a new protocol.
• Between different ecosystems – send assets from [[gloss:ethereum|Ethereum]] to [[gloss:solana|Solana]], which runs a different virtual machine and different rules (we compared them in 2.6).
• For cheap [[gloss:gas|gas]] – push activity to a network where fees are tens of times lower.

:::p{html} But do you even need a bridge? Sometimes not. For a first hop between ecosystems, a centralized exchange (CEX) works as a simple, legible "bridge": you send [[gloss:ethereum|ETH]] to Coinbase and withdraw it on the network you want – the exchange holds balances on all of them. There's an upside beyond simplicity: the exchange gives you a native asset directly on the target network, no wrappers. But the downsides are real too: you trust the exchange with your funds (custodial – it holds the keys for you), you pass KYC, the withdrawal can be slower than a direct bridge, and not every exchange supports withdrawal to every [[gloss:layer 2|L2]] – the network list at Coinbase and Binance is limited and changes. For a newcomer not ready to reason about verification and trilemmas yet, it's still often the safest first step. :::

:::callout{icon=💡} Think about wiring money from a bank in one country to a bank in another. Your bank doesn't physically ship banknotes abroad. It debits your account, then sends a message to the receiving bank: "credit this customer." The two banks settle through a correspondent account – a pot of money each keeps with the other precisely so transfers can happen without cash ever crossing the border. A bridge does the same between networks. Your [[gloss:ethereum|ETH]] stays put on [[gloss:ethereum|Ethereum]]; the bridge debits it on that side and signals the other side to credit you an equivalent. The locked funds are the correspondent account, and the whole thing rests on one question: can the receiving side trust that the message is genuine? :::

:::keypoints{label="Key Points"}

• "Same token" across networks is a UI illusion: USDC on [[gloss:ethereum|Ethereum]] and on Base are different contracts that happen to share a name, not one balance in two places
• Every cross-network [[gloss:move|move]] costs a fee and adds risk, so "chase the best yield across five chains" often loses to staying put – count the bridging cost before you [[gloss:move|move]]
• The rarer the route and the more exotic the network, the more an exchange beats a bridge – a CEX often has a tested path where a bridge would only reach through a questionable wrapper
• Want to know whether you hold the "real" asset or a representation of it – check whether it can only be withdrawn back to the source network through the same bridge. If so, it's a wrapper, and you depend on that bridge :::

:::details{badge=Advanced title="Why you can't just send a token to another network"} :::p{html} Inside one network, a transfer is an entry in a shared state that every [[gloss:node|node]] sees and verifies the same way. [[gloss:ethereum|Ethereum]] and Arbitrum don't share that state: each has its own [[gloss:validator|validator]] set, its own [[gloss:consensus|consensus]], and its own ledger of balances. When you "send" a token, you're really changing a row in one network's ledger – but the other network has no way to learn about that change, because it doesn't watch a foreign [[gloss:consensus|consensus]] and isn't obliged to trust it. :::

:::p{html} Addresses make the picture even more confusing. The same address 0xABC… exists on [[gloss:ethereum|Ethereum]], on Arbitrum, and on Base, controlled by the same [[gloss:private key|private key]] – but this isn't "one account in several places." It's several independent accounts with different balances that happen to share a name. So sending a token "to the same address but on another network" is meaningless: the recipient on the target chain simply gets nothing. This is exactly the gap a bridge closes – it becomes the one link that sees both sides at once and carries the fact from one into the other. :::

:::p{html} This abstraction has an unpleasant flip side. If you manually send a token to an exchange address that supports only [[gloss:ethereum|Ethereum]] but pick Arbitrum as the network, the coins leave your balance on the source network and "arrive" at the same address on the target – but no one is waiting for them or controls them there. Technically they haven't vanished: a ledger entry on the target network exists. But if no one holds the [[gloss:private key|private key]] for that address on that network (as with an exchange deposit address built for one chain), they can't be retrieved. This is exactly why bridge and exchange interfaces nag you about the network so insistently: a mistake here isn't undone by a support ticket – it turns into a real loss. In that sense a bridge isn't just convenience but insurance against sending value "into the void." :::

:::p{html} 在一个网络内部，转账是所有节点以相同方式看到和验证的共享状态中的一条记录。以太坊和Arbitrum不共享这个状态：各自有自己的验证者集、自己的共识和自己的余额账本。当你"发送"代币时，你实际上改变的是一个网络账本中的一行––但另一个网络无法知道这一变化，因为它不监视外部共识。 :::

:::p{html} 地址让情况更加混乱。同一个地址0xABC...同时存在于以太坊、Arbitrum和Base上，由同一个私钥控制––但这不是"一个账户在多个地方"，而是多个独立账户碰巧同名。因此把代币发送到"同一个地址但在另一个网络上"是没有意义的。这正是桥填补的鸿沟。 :::

:::p{html} 这种抽象有一个不愉快的反面。如果你手动将代币发送到只支持以太坊的交易所地址，但选择了Arbitrum网络，代币会离开你在源网络的余额并"到达"目标网络的同一地址––但没有人在那里等待或控制它们。这正是桥和交易所界面如此反复确认网络的原因：这里的错误不会被客服撤销，而是变成真正的损失。 ::: :::

:::quiz{id=q-3-5-s1 correct=2 explanation="Correct. Each network keeps its own state, so "USDC" is a distinct contract on each chain with no shared ledger. A bridge is what links a balance on one to a balance on the other. The price is effectively the same; fees and "realness" aren't the point."} Why are USDC on [[gloss:ethereum|Ethereum]] and USDC on Base not the same thing?

• Because their prices differ between networks
• Because Base charges a higher fee for USDC
• They're separate contracts on separate networks that don't share state
• Because only one of them is a real [[gloss:stablecoin|stablecoin]] :::

:::section{mins=6} How Bridges Work :::

:::p{html} We already walked through the mechanics in 2.5 §7: a bridge either locks an asset on one side and issues a representation of it on the other (lock-and-mint), or burns it and freshly mints a native version (burn-and-mint, like Circle's [[gloss:cctp|CCTP]]), or hands you a token from a pre-filled pool (liquidity), or tasks a third-party solver with paying you instantly out of their own pocket ([[gloss:intent-based|intent-based]]). If those four schemes still sound unfamiliar, go back to 2.5 – we won't re-explain them here. The same weak spot hides behind all of them. :::

:::p{html} When a bridge "moves" an asset, the destination network doesn't see the source network directly – it has no way to peer into a foreign [[gloss:consensus|consensus]] on its own. So someone has to tell it: "yes, 1 [[gloss:ethereum|ETH]] really is locked on [[gloss:ethereum|Ethereum]], go ahead and issue the representation." That someone is the heart of the bridge. Whatever the destination is forced to take on trust decides everything else: speed, cost, and above all what exactly can go wrong. A bridge is a mechanism for delivering one single message: "the lock happened, you may release." :::

:::p{html} Who exactly you trust depends on the bridge type, and it helps to hold it in your head as one scale: :::

:::p{html}

• The math of an [[gloss:l1|L1]] – a [[gloss:rollup|rollup]]'s [[gloss:canonical bridge|canonical bridge]] leans on [[gloss:ethereum|Ethereum]]'s own proofs. The lock is attested not by a group of people but by a proof that [[gloss:ethereum|Ethereum]] itself verifies. You trust [[gloss:ethereum|Ethereum]] and no one else – but you pay in waiting time (up to seven days on optimistic [[gloss:rollup|rollups]]).
• A set of signers – a bridge like Wormhole keeps a set of "guardians": 19 independent [[gloss:validator|validators]], and to attest a lock at least 13 of them (two-thirds) must sign. You trust that those 13 are honest and their keys aren't stolen. For contrast, the Harmony bridge in 2022 used a 2-of-5 scheme – and fell when an attacker got just two keys.
• A liquidity pool – here the asset never crosses the border at all; you simply swap with the pool on the other side. You trust that the destination pool holds enough funds and that its contract has no bug.
• A third-party solver – in an intent bridge an intermediary pays you instantly from their own funds and gets reimbursed later through a [[gloss:canonical bridge|canonical bridge]]. In models like Across the solver posts a bond for this, which they lose if they misbehave – trust here is backed by their money under threat of loss.

:::p{html} This "trust scale" is a direct practical tool. When we choose a bridge in §6, the first question will be exactly this: which point on the scale does it sit at, and are you comfortable with the corresponding assumption? An [[gloss:ethereum|Ethereum]] proof and a set of 13 honest signers are very different promises, even if both bridges' interfaces look equally smooth. The larger the amount, the further left on the scale (closer to [[gloss:l1|L1]] math) you should stay, and the less willing you should be to accept "trust a group of people" in exchange for a couple of saved minutes. :::

:::callout{icon=💡} You're buying a car from a stranger in another city. You don't want to hand over cash before you get the car, and they don't want to release the car before the cash. The fix is an escrow agent: a neutral party you both trust. You send the money to them, they hold it, and only once the car is confirmed delivered do they release the payment to the seller. A bridge is that escrow agent between two networks. Your asset is frozen on one side, and the funds on the other are released only once the bridge has confirmed the lock happened. The whole safety question reduces to how far you can trust that agent – whether it's one person with a key, a group of signers, or a mathematical proof. :::

:::keypoints{label="Key Points"}

• To size up a bridge's risk fast, ask one question: who tells the destination network the lock happened? The name of that someone – math, signers, or a solver – is the risk profile
• A bridge is exactly as safe as whoever it trusts to verify. Five [[gloss:multisig|multisig]] keys protect funds only as well as those five keys are protected – no more
• A wrapped token holds its peg only while the bridge is solvent. If the reserve is drained by a hack, the wrapper can instantly lose its peg – you're holding an IOU from a bankrupt
• A liquidity bridge can stall not from a bug but simply because the destination pool lacks depth for a large transfer. A big amount is often cheaper and safer split into parts :::

:::details{badge=Advanced title="The bridge trilemma: why you can't have everything"} :::p{html} Bridge builders have a framing that echoes the [[gloss:blockchain|blockchain]] trilemma (we covered that in 1.3) – it was proposed by Arjun Bhuptani, founder of Connext (the project is now called Everclear). You'd want the ideal bridge to be trustless (requiring no trust in intermediaries), extensible (easy to plug into any new network), and generalizable (carrying not just tokens but arbitrary data) all at once. In practice you can't get all three – you sacrifice one to keep the other two. :::

:::p{html} [[gloss:rollup|Rollup]] canonical bridges sacrifice extensibility: they're trustless and can carry data, but they're tied to one network pair ([[gloss:l1|L1]] ↔ their own [[gloss:layer 2|L2]]) and don't reach everywhere. Signer-set bridges like Wormhole sacrifice the trustless part: they plug into dozens of networks and carry anything, but you trust a set of guardians. Liquidity bridges like Stargate are easiest to extend, but usually [[gloss:move|move]] only tokens, not arbitrary messages. This is exactly why there's no "best bridge for everything" – only a choice of what you're willing to sacrifice on a given route. :::

:::p{html} The trilemma has a newer dimension too – economic security. If a set of signers can't be trusted "just because," you can require them to post a bond that's burned if they misbehave. Several approaches work this way: Axelar [[gloss:validator|validators]] stake the AXL token and lose it for malicious behavior; LayerZero introduces [[gloss:slashing|slashing]] via EigenLayer in its DVN (data verification network) system; optimistic bridges like Across require relayers to post a bond. The idea in every case is the same: shift trust from "we believe people are honest" to "dishonesty costs more than it pays." This doesn't make a bridge trustless in the strict sense, but it turns trust in people into trust in an economic incentive – which is verifiable and measurable, unlike bare reputation. :::

:::p{html} [[gloss:rollup|Rollup]]的规范桥牺牲了可扩展性：它们是无信任的且能传输数据，但绑定在一对网络上。签名者集合桥如Wormhole牺牲了无信任部分。流动性桥如Stargate最容易扩展，但通常只移动代币。正因如此，不存在"万能最佳桥"––只有你愿意在特定路线上牺牲什么的选择。 :::

:::p{html} 三难问题还有一个更新的维度––经济安全。如果不能"仅仅因为"就信任一组签名者，可以要求他们存入保证金，作弊时烧毁。几种方法都是这样工作的：Axelar验证者质押AXL代币；LayerZero通过EigenLayer引入削减；Across要求中继者存入保证金。思路都一样：把信任从"相信人是诚实的"转移到"不诚实的成本高于收益"。 ::: :::

:::quiz{id=q-3-5-s2 correct=1 explanation="Correct. The destination network can't see a foreign [[gloss:consensus|consensus]] directly, so it relies on whoever attests that the lock happened – a mathematical proof, a group of signers, or a solver. The reliability of that mechanism, not speed or fees, is what decides safety."} What actually guarantees that the mint on the destination network matches the lock on the source network?

• The speed of the internet connection between the networks
• The verification mechanism the destination network trusts
• The size of the fee you paid
• The number of confirmations in the source [[gloss:block|block]] :::

:::section{mins=6} Bridge Types :::

:::p{html} When you open a bridge or an aggregator, the architecture is almost never spelled out in big letters. But indirect signs give it away. If the transfer is promised in seconds and you receive a native asset, it's almost certainly a liquidity pool or an intent bridge with a solver. If a window like seven days or a few hours appears for the withdrawal, that's a [[gloss:rollup|rollup]] [[gloss:canonical bridge|canonical bridge]] waiting on its challenge period or proof. If you receive a token with a suffix like USDC.e, or the bridge openly names "guardians" and signers, you're looking at lock-and-mint with an external trust group. One glance at the promised time and the kind of asset you get tells you more about the security model than any marketing copy. :::

:::p{html} Time is an especially telling sign, and it has clear benchmarks. Fast routes through intent bridges and pools (Across, Hop) usually land within one to five minutes. Standard liquidity bridges like Stargate take roughly five to fifteen minutes. But anything that hits [[gloss:ethereum|Ethereum]] [[gloss:finality|finality]] (a withdrawal from [[gloss:layer 2|L2]] to [[gloss:l1|L1]] through a [[gloss:canonical bridge|canonical bridge]], say) takes twenty minutes or more, and on optimistic [[gloss:rollup|rollups]] the withdrawal window stretches up to seven days. If an interface promises "seconds" where the nature of the route should mean minutes or days, that's not magic – someone is just fronting you the funds and charging for it. :::

:::p{html} A separate class is messaging bridges, such as LayerZero, Wormhole, and Hyperlane. They carry not just tokens but arbitrary data between networks, which is why they underpin cross-chain apps: an action on one network, settlement on another. Most of the time you don't even notice them – the app "just works," and underneath, a message about your action rides across one of these bridges. A game on one network with items recorded on another; a DAO vote whose treasury lives on a third – all of it rests on messaging bridges. That's convenient, but it means trusting the app includes trusting the bridge it's built on. :::

:::p{html} Picking a specific bridge by hand for an unfamiliar route is almost always wasted effort. Aggregators do it for you. Jumper (on LI.FI's infrastructure) and Bungee (on Socket) compare dozens of bridges and exchanges and pick a route on price and time. They can fuse two steps into one: take [[gloss:ethereum|ETH]] from Arbitrum and hand you [[gloss:solana|SOL]] on [[gloss:solana|Solana]] in a single operation, adding a DEX swap. That's a cross-chain swap – not just moving one token, but changing both the network and the asset at once. Symbiosis belongs to the same class: it swaps any token into any other across dozens of networks in one [[gloss:transaction|transaction]] straight from your [[gloss:wallet|wallet]], delivering native assets instead of wrappers and without requiring you to hold a [[gloss:gas|gas]] token on the destination chain. :::

:::p{html} It's worth knowing how to read an aggregator's output. It typically shows three to five routes with a fee and time estimate for each, and the top one isn't always the one you want: the algorithm optimizes for either price or speed by default, and the mode switch reorders the list. Under each route sits a specific underlying bridge with its own trust model – Across, Stargate, [[gloss:cctp|CCTP]], and so on. So the key caveat is this: an aggregator saves you the choice but doesn't remove the risk. It finds a cheap, fast path, but the safety of that path is the safety of whatever bridge ended up underneath, not of the aggregator itself. :::

:::callout{icon=💡} Picture freight travelling by rail across the border between two countries with different track gauges. The wagon itself can't continue. There are three ways out. First, at the border station the cargo is reloaded into local wagons: slow, bureaucratic, but reliable and under official control (this is the [[gloss:canonical bridge|canonical bridge]]). Second, a local company keeps its own fleet at the border and transfers your cargo into a ready wagon for a fee (the liquidity bridge). Third, a forwarder hauls your cargo onward immediately on their own transport and settles up with the railway later themselves (the intent bridge). And an aggregator is the dispatcher who rings all three in a minute and tells you which is cheaper and faster today. :::

:::keypoints{label="Key Points"}

• Speed and a low fee usually mean someone lent you liquidity and charges for it. A slow [[gloss:canonical bridge|canonical bridge]] is often safer than a fast one
• Using a cross-chain app, you silently accept its bridge as part of the deal: even if the app is sound, a hack of the messaging bridge underneath will hit you
• For one-off and small transfers, trust the aggregator; but for a regular large route, find out which bridge it picks and judge that bridge – saving seconds isn't worth an unclear trust model
• An aggregator's "best quote" and the "safest route" are different things. When the price gap between bridges is small, choose by their verification model, not by a couple of saved dollars :::

:::details{badge=Advanced title="Cross-chain MEV: the invisible threat"} :::p{html} [[gloss:mev|MEV]] doesn't vanish at the border between networks – it takes on its own shape among bridges. In intent bridges like Across, your request is filled by solvers competing for the right to pay you out. That competition works in your favour: solvers bid the price down in an auction, and the best quote goes to you. But the same mechanic creates room for games – a solver sees your intent before it's executed and could, in principle, use that knowledge on other venues. That's why large cross-chain swaps are worth splitting up, and why you should check the quote you got rather than blindly accepting the first one. :::

:::p{html} Understanding how solver competition turns in your favor and where its limit is. In the Across model several solvers see your intent at once, each ready to fill it from their own funds; the one offering the best price wins, and the gap in their costs is squeezed to a minimum – that's the auction working for you. But this openness has a flip side: while the intent waits to be filled, it's public, and in theory a solver could account for your trade in its own actions on a DEX on that network. In practice this is invisible for ordinary amounts, but on large transfers it's sensible to use routes with a private order flow or to split the amount so you don't [[gloss:move|move]] the price with your own order. The same rule applies here as with slippage in a regular swap: the larger and more visible your order, the more attention it draws. :::

:::p{html} [[gloss:mev|MEV]]不会在网络边界消失––它在桥中有自己的形态。在像Across这样的intent桥中，你的请求由竞争填单权的solver执行。这种竞争对你有利：solver在拍卖中压低价格，最佳报价给你。但同样的机制也创造了博弈空间––solver在你的意图执行前就看到了它。因此大额跨链兑换值得拆分。 :::

:::p{html} 值得了解solver竞争如何对你有利以及其限度在哪里。在Across模型中，多个solver同时看到你的意图，各自准备用自己的资金填单；出价最好的获胜。但这种开放性有另一面：在意图等待执行时它是公开的，理论上solver可以在该网络的DEX上考虑到你的交易。对于普通金额这是不可见的，但对于大额转账，明智的做法是使用私有订单流的路线或拆分金额。 ::: :::

:::quiz{id=q-3-5-s3 correct=2 explanation="Correct. Instant release of a native asset means the funds come from a ready pool or are fronted by a solver – that's the liquidity or intent model. A [[gloss:canonical bridge|canonical bridge]], by contrast, makes you wait out a withdrawal window. Speed says nothing about safety."} A bridge promises to release funds in seconds and gives you a native token (not a wrapper). What does that most likely tell you?

• It's a [[gloss:rollup|rollup]] [[gloss:canonical bridge|canonical bridge]] that settles transfers directly through the [[gloss:l1|L1]] contract
• It means the transfer is free
• It's a liquidity pool or intent bridge – someone is supplying liquidity here and now
• It means the bridge is completely risk-free :::

:::section{mins=5} Bridging in Practice :::

:::p{html} First the [[gloss:wallet|wallet]] and the networks. You connect a [[gloss:wallet|wallet]] (MetaMask, Rabby, or Phantom for [[gloss:solana|Solana]]) to the bridge or aggregator interface and check that the [[gloss:wallet|wallet]] is set to the correct source network. It sounds trivial, but this is where people slip up most often: they try to send from Base while their funds sit on Arbitrum. Then you pick the asset, the amount, the destination network – and the interface shows you a route with its fee and time. Don't skip past that screen: it spells out how much you'll pay and how long you'll wait, and this is the moment to double-check the destination network is the right one. :::

:::p{html} Next come two signatures, and the difference matters. The first is approve: you [[gloss:permit|permit]] the bridge contract to handle a specific token up to a specific amount. That's not the transfer itself – just permission – but it needs its own [[gloss:transaction|transaction]] and [[gloss:gas|gas]]. The second signature is the transfer proper. Modern [[gloss:wallet|wallets]] like Rabby can fold approve and transfer into one confirmation via Permit2, but if you see two requests back to back, that's normal and intended. Watch the allowance amount specifically: some interfaces request an "unlimited" approve by default so they don't have to ask again later – convenient, but it leaves the contract open-ended access to your token. For an unfamiliar bridge it's wiser to approve exactly the transfer amount, and to revoke old allowances now and then through tools like revoke.cash. :::

:::p{html} Before you sign, read the simulation. Rabby and similar [[gloss:wallet|wallets]] dry-run the [[gloss:transaction|transaction]] and show what it will actually do: which tokens leave and arrive, which contracts get called, whether the whole thing will revert, whether an unexpected allowance is being granted. This is your last line of defense: if the simulation shows the wrong token leaving, or the wrong recipient address, or an approve for your full balance you weren't expecting – stop and investigate, don't sign. The habit of reading the simulation turns signing from "clicking OK blind" into a deliberate act. For an unfamiliar bridge add one more cheap measure: push a small test amount through first and confirm it arrives, and only then send the real one. :::

:::p{html} After you confirm, the waiting begins, and how long it lasts depends on the route. Between two [[gloss:layer 2|L2s]] a transfer usually takes from twenty seconds to a minute; from [[gloss:l1|L1]] to [[gloss:layer 2|L2]], three to six minutes; and a withdrawal from [[gloss:layer 2|L2]] to [[gloss:l1|L1]] through a [[gloss:canonical bridge|canonical bridge]] takes seven to ten minutes or more because of the [[gloss:finality|finality]] window. While you wait, it helps to keep the bridge's status tracker or the explorer open by the [[gloss:transaction|transaction]] [[gloss:hash|hash]]: you'll see which stage the transfer is at and won't have to guess whether something's wrong. One last thing about [[gloss:gas|gas]]: you need a native token not only on the source network to send, but sometimes on the destination too – so you can actually use the funds once they arrive. Arriving on a new network with an asset but no [[gloss:gas|gas]] for your first [[gloss:transaction|transaction]] is a common, painful mistake. Some routes, like Symbiosis, can take destination [[gloss:gas|gas]] out of the amount being moved, but that's the exception, not the rule. :::

:::callout{icon=💡} The approve step is best understood as signing a power of attorney. When you grant someone power of attorney over an account, you're not handing over the money – you're giving them the right to act with it, up to whatever limit you wrote in. The property is still yours until they actually use that right. A token approval is exactly this: it lets the bridge contract [[gloss:move|move]] your token, but moves nothing by itself. Two consequences follow, just as with a real power of attorney. First, signing it alone doesn't part you from your funds. Second – and this is what people forget – a power of attorney you no longer need should be revoked, or it sits there as a standing right someone could use later. :::

:::keypoints{label="Key Points"}

• A bridge has no "undo" button: if you picked the wrong destination network or address format, the [[gloss:transaction|transaction]] can't be rolled back. A minute spent double-checking the network and the address is worth more than it seems
• Two pop-ups in a row (approve, then transfer) is normal, not a glitch – but one combined confirmation via Permit2 is normal too; what matters is reading each, not their count
• A small test transfer costs pennies of [[gloss:gas|gas]] and saves you from losing the whole amount on an unfamiliar route – a cheap safety net almost everyone skips
• The lowest-fee route isn't always the cheapest in the end: on a volatile market, a slow bridge can cost you more in price [[gloss:movement|movement]] while you wait than the fee you saved :::

:::details{badge=Advanced title="What to do when a transfer is stuck"} :::p{html} When a transfer seems "stuck," it's too early to panic – diagnose first. If the [[gloss:transaction|transaction]] on the source network confirmed but the funds haven't shown up at the destination, open the bridge's explorer or status tracker by the [[gloss:transaction|transaction]] [[gloss:hash|hash]] (we covered reading explorers in 3.4). Most often you'll see one of the stages: waiting for source confirmation, [[gloss:validator|validator]] or relayer signing in progress, settlement on the destination underway. For intent and liquidity bridges, a delay sometimes just means the destination pool was briefly short on liquidity and the solver is waiting – the money isn't lost. The real problem is only if the [[gloss:transaction|transaction]] failed (reverted) on the source network; in that case the funds stayed with you and you can try again. :::

:::p{html} It helps to know the typical stages a transfer "hangs" at and what each one means. If the tracker shows "waiting for source confirmations," that's normal: the bridge is waiting for the [[gloss:transaction|transaction]] on the source network to gather enough [[gloss:block|blocks]], which on [[gloss:l1|L1]] can be several minutes. The "[[gloss:validator|validator]]/relayer signing" stage means the lock is recorded and a quorum of signatures is being gathered (for Wormhole, that same 13 of 19); it only hangs for long if some signers are unavailable. "Settlement on the destination" for liquidity and intent bridges sometimes drags because the pool is short on liquidity – the solver waits for it to refill, and that's deferred execution, not a loss. But if a transfer sits for hours with no [[gloss:movement|movement]] and the tracker shows none of these stages, it's worth contacting the bridge's support with the [[gloss:transaction|transaction]] [[gloss:hash|hash]] – just make sure you're looking at the official tracker, not a phishing copy easily found by searching "bridge stuck." :::

:::p{html} 了解转账"卡住"的典型阶段及其含义很有用。如果追踪器显示"等待源确认"，这很正常：桥在等待源网络上的交易积累足够的区块。"验证者/中继者签名"阶段意味着锁定已记录，正在收集签名法定人数。"目标网络结算"对流动性和intent桥有时因池中流动性不足而延迟––solver等待池补充，这是延迟执行而非损失。但如果转账数小时没有移动且追踪器未显示任何这些阶段，值得用交易哈希联系桥的客服––但首先确保你看的是官方追踪器，而不是搜索"bridge stuck"容易找到的钓鱼副本。 ::: :::

:::quiz{id=q-3-5-s4 correct=0 explanation="Correct. Approve only lets the contract handle your token; it doesn't [[gloss:move|move]] it. Until the second signature – the transfer itself – the funds stay at your address. That's why an approve with no follow-up transfer is harmless to your balance – though the allowance is worth revoking afterward."} You signed an approve [[gloss:transaction|transaction]] for a bridge, but haven't confirmed the transfer itself yet. Where are your funds right now?

• Still with you – approve only granted permission, the transfer hasn't started
• Already on the destination network, because approve automatically initiates the transfer
• Locked in the bridge contract, waiting for the relayer to confirm delivery
• Burned on the source chain and waiting to be re-minted on the destination chain :::

:::section{mins=5} Bridge Risks :::

:::p{html} Why bridges specifically. We went through the hack cases in 2.5 §7 – Ronin, Wormhole, Nomad, BNB – and won't retell them here. What matters more is seeing the pattern: almost all the big hacks came through people and trust, not clever math. The largest, Ronin at $624 million, was stolen [[gloss:validator|validator]] keys; BNB Bridge lost around $568 million to a forged proof, Wormhole around $326 million to a signature-check bug. Behind these numbers is one and the same story: what broke wasn't the [[gloss:cryptography|cryptography]] but its wrapping – keys, configuration, verification logic. :::

:::p{html} The root is that a bridge, by its nature, is a concentration of value. It gathers the collateral of both networks in one contract, and the more value locked there, the bigger the prize for breaking in and the more effort an attacker will invest. An ordinary [[gloss:wallet|wallet]] isn't worth it on its own; a bridge contract with hundreds of millions is worth it to everyone. To that add a second problem: unlike an exchange, a bridge has no "emergency brake." An exchange can be shut down, freeze withdrawals, reverse operations by hand; a bridge is a contract running by its own rules, and if the rules [[gloss:permit|permit]] funds to be drained, they leave in a single [[gloss:block|block]], with no chance to intervene. :::

:::p{html} What this changes for you. Since a bridge is more dangerous than an ordinary [[gloss:transaction|transaction]], you should act more carefully on it. The core rule is simple: a bridge is a pipe, not a vault. You transfer through it; you don't store in it. If you need to hold funds on another network, hold them in your own [[gloss:wallet|wallet]] on that network – don't leave them in bridged or wrapped form longer than the transfer needs. The less time your money spends "in the pipe," and the less of it at once, the less you depend on this particular bridge not becoming the next hack headline. :::

:::p{html} From this follow a few simple behavioral takeaways worth more than any audit. Split large sums into several transfers rather than one – that way less is in the risk zone at any moment. Don't use a bridge as casual storage: if you got a wrapper, [[gloss:move|move]] it into the native asset. And remember that the mere existence of a noticeable balance in wrapped form makes you dependent on a specific bridge's solvency, even when you're not thinking about it. :::

:::p{html} The good news is that the trend has turned. After the 2022 wave, the industry moved from bridges that trust signers toward verification through proofs – ZK and light clients, where math, not a group of people, confirms the lock happened. Hacks have dropped noticeably. But "fewer" isn't "none": no bridge is provably safe, and in 2025 bridges were still used to launder over $1.5 billion stolen elsewhere. Caution stays your job – it isn't delegated to the protocol. :::

:::callout{icon=💡} Moving a famous painting between two museums. While it hangs in a guarded hall, it's about as safe as it gets – cameras, climate control, a wall of security. The danger isn't the hall; it's the [[gloss:move|move]]. The instant the painting is off the wall, crated, and on the road, it becomes the single most attractive target it will ever be: enormous value, in transit, briefly outside any one institution's full control. That's exactly a bridge. Your assets aren't most at risk sitting in a [[gloss:wallet|wallet]] on either network – they're most at risk in the moment of crossing, concentrated in one contract. Which is why the rule for both paintings and tokens is the same: minimize the time spent in transit, and don't [[gloss:move|move]] more at once than you must. :::

:::keypoints{label="Key Points"}

• A [[gloss:rollup|rollup]]'s [[gloss:canonical bridge|canonical bridge]] can't be hacked separately from [[gloss:ethereum|Ethereum]] itself – which makes it structurally safer than any third party for holding value between networks, even if you wait longer
• A bridge's [[gloss:tvl|TVL]] measures the size of the target, not its reliability. $500M in a contract attracts exactly $500M worth of attacker attention
• A big name and an audit lower the risk but don't remove it: Ronin and Wormhole were both large, well-known, and audited – right up until the day they were drained
• Don't count on being made whole after a hack: Wormhole's losses were covered by its backer (Jump), but that's the rare exception – most drained bridges never repaid users in full :::

:::details{badge=Advanced title="Five reasons bridges are more vulnerable than ordinary contracts"} :::p{html} Bridges have five structural reasons to be more vulnerable than ordinary contracts: :::

:::p{html}

• Concentration. A bridge is a honeypot where the collateral of both networks sits in one place, and the size of the prize justifies enormous attacker effort.
• Complexity. Code that understands two different networks at once is inherently more complex, and bugs hide in complexity.
• Trust in external parties. Many bridges rely on signers or relayers, and their keys become a point of failure.
• Reaction speed. A bridge has no admin who can instantly freeze everything under attack – and if it does, that's already a point of centralization.
• Novelty of attack vectors. Cross-chain messaging is a young field, and new classes of attack are still being found.

:::p{html} From these five reasons follows an uncomfortable but honest conclusion: a bridge's safety can't be judged as confidently as a simple contract's. An ordinary [[gloss:defi|DeFi]] protocol's attack surface is bounded by its own logic; a bridge's surface includes a foreign [[gloss:consensus|consensus]], external signers, relayers, and the seam between two different execution environments – and any link in that chain can be the weak one. This is exactly why experienced users treat bridges as temporary infrastructure, not permanent: they pass through quickly, split large sums, and for long-term holding return to canonical paths or to a self-custodied [[gloss:wallet|wallet]] on the network itself. That isn't paranoia but a sober accounting of the fact that the five factors above won't go away – they're built into the very idea of connecting independent networks. :::

:::p{html}

• Концентрация. Мост – это honeypot, где залог обеих сетей лежит в одном месте, и размер приза оправдывает огромные усилия атакующих.
• 集中。桥是一个蜜罐，两个网络的抵押品放在一个地方，奖励的大小证明了攻击者投入的巨大努力。
• Сложность. Код, который одновременно понимает две разные сети, по определению сложнее, а в сложности прячутся ошибки.
• 复杂性。同时理解两个不同网络的代码天然更复杂，而bug藏在复杂性中。
• Доверие к внешним сторонам. Многие мосты полагаются на подписантов или релееров, и их ключи становятся точкой отказа.
• 对外部方的信任。许多桥依赖签名者或中继者，他们的密钥成为故障点。
• Скорость реакции. У моста нет администратора, который мгновенно заморозит всё при атаке, – а если есть, то это уже точка централизации.
• 反应速度。桥没有管理员可以在攻击时立即冻结一切––如果有，那已经是中心化点了。
• Новизна векторов. Кросс-чейн сообщения – молодая область, и новые классы атак всё ещё находят.
• 攻击向量的新颖性。跨链消息传递是一个年轻的领域，新的攻击类别仍在被发现。

:::p{html} 从这五个原因得出一个不舒服但诚实的结论：桥的安全性无法像简单合约那样自信地判断。普通[[gloss:defi|DeFi]]协议的攻击面受其自身逻辑约束；桥的攻击面包括外部共识、外部签名者、中继者以及两个不同执行环境之间的接缝。这正是经验丰富的用户将桥视为临时而非永久基础设施的原因：快速通过、拆分大额资金、长期持有则回到规范路径或网络上的自托管钱包。 ::: :::

:::quiz{id=q-3-5-s5 correct=1 explanation="Correct. The biggest hacks – Ronin's stolen [[gloss:validator|validator]] keys above all – came through the human and trust layer, not through broken [[gloss:cryptography|cryptography]]. That's the whole case for moving to ZK and light-client verification, where math does the attesting."} What has been the most common cause behind the largest bridge hacks?

• Flaws in the cryptographic math itself
• Stolen keys and the people holding them – signers, not code
• Users entering the wrong amount
• Networks being too slow :::

:::section{mins=4} Choosing a Safe Bridge :::

:::p{html} Start with a simple rule: let the size of the amount choose the bridge, not the other way around. For a small everyday transfer, take the most convenient option – usually an aggregator like Jumper or Bungee that picks a cheap, fast route for you; here saving a minute matters more than the trust model, because little is at risk. For a large sum you'd hate to lose, the logic reverses: the [[gloss:canonical bridge|canonical bridge]] of the [[gloss:layer 2|L2]] in question if you're moving between [[gloss:ethereum|Ethereum]] and its [[gloss:rollup|rollup]], or a long-running, repeatedly audited bridge with a transparent verification model. Between [[gloss:ethereum|Ethereum]] and [[gloss:solana|Solana]] it's sensible to go through native paths like [[gloss:cctp|CCTP]] for USDC, not through some random wrapper – a native path doesn't leave you holding a representation whose peg depends on the bridge's solvency. :::

:::p{html} Learn to spot the red flags. A new bridge with no track record that pushes itself aggressively on social media and promises zero fees is almost always either bait or untested risk: a zero fee is made up for somewhere, and if it's not clear where, then you're the one paying – in risk. You should also be wary of a very small amount of locked funds (a bridge no one uses is either too new or has scared people off), the absence of a public audit, a [[gloss:multisig|multisig]] with too few signers (remember Harmony with its 2-of-5 scheme), and an unverified contract in the explorer whose source code you can't read. Any one of these alone isn't a verdict, but a combination of them adds up to the same warning repeated from different angles. :::

:::p{html} Verify before you trust a large amount to it. [[gloss:l2beat|L2Beat]] is an independent analytics resource that rates [[gloss:layer 2|L2s]] and bridges by their security models; it has a dedicated bridges section where each solution's security model, audits, and trust assumptions are laid out clearly – a minute there is cheaper than any insurance. The practical routine: open the bridge's page, find what verification rests on (proofs, signers, a pool), see who can upgrade the contract and with what delay, and check the value locked and the incident history. If after that you can state in one sentence who you're trusting and what happens if that someone turns out to be dishonest, you're ready. If not, that's a signal to look for another route, not to look away. :::

:::p{html} A separate tool for very large sums is insurance. Protocols like Nexus Mutual sell cover against a smart-contract hack, oracle manipulation, or a governance attack, and several billion dollars of assets are already protected through them. But it's important to understand its limits. First, cover doesn't extend to your own mistake – sending to the wrong address or network, phishing, a leaked key: anything where the protocol worked as intended and you erred is not a claim. Second, with these mutuals a payout is decided by a member vote rather than issued automatically, and there have been denials in disputed cases. So insurance makes sense as a tool for large sums where its cost pays off, and is useless as a substitute for basic caution. :::

:::callout{icon=💡} Choosing a bridge is like choosing a courier for a valuable parcel. For a postcard you grab whoever's cheapest – it barely matters. But for something you can't afford to lose, you don't hand it to an unknown van that appeared yesterday promising free delivery. You pick a service with a track record, real tracking, and insurance you can actually claim on – and you accept it costs a bit more and takes a bit longer. The "free, instant, brand-new" courier isn't a bargain; it's the one with no reputation to lose if your parcel vanishes. And note: the insurance covers the courier losing the parcel – not you writing the wrong address on it. :::

:::keypoints{label="Key Points"}

• Let the amount set the bar: for $50 take whatever's convenient; for $50,000 the route must justify itself, and "it was faster" isn't justification
• A single red flag isn't a verdict, but they cluster: aggressive promotion, no public audit, and an unverified contract together are one warning said three times
• Two bridges can't be compared by a single number: a cheaper fee on a signer-set bridge and a higher one on a [[gloss:canonical bridge|canonical bridge]] are prices for different risks, not the same thing at different costs
• Bridge insurance is a tool for large sums, not for every transfer: its cost only pays off when the amount is well above the price of the cover. On $200 it's simpler to accept the risk than to insure it :::

:::details{badge=Advanced title="How to read a bridge's L2Beat page"} :::p{html} First, look at the trust type: is the bridge marked as relying on [[gloss:validator|validators]], on an external set of signers, or on proofs? Next, who can upgrade the contract, and is there a delay before an upgrade takes effect – a bridge the team can change instantly is, in effect, governed by trust in that team. Then, was it audited and by whom, and how much value has already passed through the bridge without incident. And finally, read the trust-assumptions section in your own words: if you can't explain exactly who you're trusting and what happens if that someone turns out to be dishonest, you're not ready to send a large amount there yet. :::

:::p{html} The most underrated parameter on that page is upgradability – whether the contract can be changed. Many people picture a bridge as immutable math, but most bridges have an admin key or [[gloss:multisig|multisig]] that can replace the contract's logic. If an upgrade applies instantly, with no delay (timelock), the holder of that key can effectively change the rules at any moment – and then all the bridge's "security" reduces to the security of that key, however elegantly the verification is described. A good sign is a delay of several days between an upgrade's announcement and its taking effect: it gives users time to exit if the change looks malicious. [[gloss:l2beat|L2Beat]] flags these properties explicitly, and it's those, not brand volume, you should look at when a large amount is at stake. A bridge with flawless [[gloss:cryptography|cryptography]] but instantly upgradable by one key isn't a trustless solution – it's trust in the team in a pretty wrapper. :::

:::p{html} 首先看信任类型：桥是标记为依赖验证者、外部签名者集合还是证明？接下来––谁可以升级合约，升级生效前是否有延迟。然后––是否进行了审计、由谁进行、有多少价值已经通过桥而没有事故。最后，用自己的话阅读信任假设部分：如果你无法解释你到底信任谁以及如果那个人不诚实会怎样––你还没准备好往那里发送大额资金。 :::

:::p{html} 该页面上最被低估的参数是可升级性––合约是否可以更改。许多人将桥想象为不可变的数学，但大多数桥有管理员密钥或多签可以替换合约逻辑。如果升级立即生效、没有延迟（timelock），那么该密钥持有者实际上可以随时更改规则––然后桥的所有"安全性"都归结为该密钥的安全性。好的迹象是升级公告和生效之间有几天的延迟。[[gloss:l2beat|L2Beat]]明确标记这些属性，当大额资金在手时应该关注的是这些，而不是品牌知名度。 ::: :::

:::quiz{id=q-3-5-s6 correct=3 explanation="Correct. Cover like Nexus Mutual's pays out on contract hacks, oracle manipulation, and governance attacks – failures of the protocol. Your own mistake (wrong address or network) is explicitly excluded, which is why most user losses aren't insurable at all."} You bought bridge cover from a [[gloss:defi|DeFi]] insurer. Which of these would it typically NOT pay out on?

• The bridge contract was hacked and drained
• An oracle was manipulated to forge a deposit
• A governance attack forced a malicious upgrade
• You sent funds to a wrong address on the wrong network :::

:::section{mins=4} Chain Abstraction :::

:::p{html} The idea is called [[gloss:chain abstraction|chain abstraction]]. Today your money is scattered across networks in separate piles, and you decide what to bridge where. In a chain-abstraction world you have one combined balance – say 1,000 USDC, not "500 here and 300 there" – and when you want to pay or invest, the system itself works out which network to pull from and what route to carry it on. The network becomes an implementation detail you don't see – much as you don't think about which routers your internet traffic passes through today. :::

:::p{html} Under this future sits concrete engineering, and its key building [[gloss:block|block]] is the intent standard ERC-7683, proposed by Uniswap Labs and Across in 2024. Instead of signing a [[gloss:transaction|transaction]] that says "call this contract on this network," you sign an intent: "I want 1,000 USDC on any network where I have a payment." Solvers then compete to fulfill it – the same ones we saw in intent bridges. In February 2025 the [[gloss:ethereum|Ethereum]] Foundation launched the Open Intents Framework – a shared scaffold for such intents – backed by more than thirty teams, including Arbitrum, Optimism, Polygon, and zkSync. :::

:::p{html} Along with the intent standard come two things that make the abstraction tangible. The first is a universal balance: the [[gloss:wallet|wallet]] shows not seven separate lines of "USDC on network X" but a single sum, and decides for itself where to draw from when you pay. The second is [[gloss:gas|gas]] abstraction: you no longer need to hold a native token on every network to pay for a [[gloss:transaction|transaction]] – the solver covers the fee and folds it into the overall settlement. These two details are exactly what used to kill multichain convenience earliest: a newcomer arriving on a new network with no [[gloss:gas|gas]] hit a wall, and now the wall is gone. That very scenario from §4, where you watched [[gloss:gas|gas]] on both sides, simply doesn't arise in a chain-abstraction world. :::

:::p{html} And this isn't theory. By early 2026 Across, UniswapX, CoW Protocol, and others already run on ERC-7683 in production – for Across, that standard accounts for the bulk of volume. [[gloss:wallet|Wallets]] followed: Safe, Argent, and Rabby learned to emit such intents, and MetaMask added native support in version 12.4 in March 2026. Full invisibility of bridges will arrive gradually, but the foundation for it is already in production, not in slide decks. :::

:::callout{icon=💡} [[gloss:chain abstraction|Chain abstraction]] is the wall socket for money. When you plug in a lamp, you don't choose which power plant the electricity came from, which transmission lines it travelled, or which operator balanced the grid that second. You just expect light. Yet behind the socket sits an enormous machine of generation, switching, and settlement you never think about. [[gloss:chain abstraction|Chain abstraction]] aims to make moving value feel the same: you press "pay," and underneath, a solver picks the network, a bridge carries the value, and [[gloss:gas|gas]] is handled – all invisible. The thing to remember is that the socket hiding the grid doesn't make the grid go away. The complexity is still there; you've just stopped having to operate it by hand. :::

:::keypoints{label="Key Points"}

• An invisible bridge isn't a safe bridge: abstraction hides the complexity, it doesn't remove it. Under "one button" there's still someone else's code and someone else's liquidity
• [[gloss:chain abstraction|Chain abstraction]] makes the mechanics in this card more valuable, not less: when one button works you can relax, but when a transfer breaks, knowing there's a bridge underneath is the only way to debug it
• When the [[gloss:wallet|wallet]] picks the bridge for you, you lose the ability to refuse a bad one – convenience and control trade off, and for large sums control is still worth choosing by hand
• Real [[gloss:chain abstraction|chain abstraction]] is invisible; if an app still makes you pick a network, approve a wrapper, or top up [[gloss:gas|gas]] on the far side, it's a normal bridge with a nicer skin, not abstraction :::

:::details{badge=Advanced title="What ERC-7683 solves – and what it leaves untouched"} :::p{html} The intent standard and light clients solve different problems, and it's important not to confuse them. ERC-7683 describes the shape of an intent: how a user expresses "what I want," how a solver reads it, and how settlement happens. But it deliberately does not solve verification – the very question §2 opened with. Under the elegant "one button," some specific bridge is still working, with its own trust model: a pool, signers, or proofs. Intent abstraction makes choosing and executing convenient, but it doesn't make the actual carrying of value across the border safe. So the future the industry is heading toward isn't "bridges disappeared" – it's "bridges hid." The trust questions from §5 haven't gone anywhere; they've just moved one level down, under the hood. :::

:::p{html} For you as a user, a concrete conclusion follows. As interfaces hide bridges behind "one button," responsibility for choosing the trust model quietly shifts from you to the solver and the standard – and that cuts both ways. On one hand, there's less room for manual error: you won't pick a dubious bridge out of ignorance. On the other, the system chooses for you by price and speed, not by your personal risk threshold, and its priorities need not match yours. Technically the same machine we covered all card sits behind that choice: a solver takes your intent and executes it through a specific bridge – you just don't see which. Abstraction relocates the decision, it doesn't remove it: someone still chooses the bridge, it's just no longer you. :::

:::p{html} 对你作为用户来说，有一个具体的结论。随着界面将桥隐藏在"一个按钮"后面，选择信任模型的责任悄悄从你转移到了solver和标准––这是一把双刃剑。一方面，手动犯错的空间更小。另一方面，系统按价格和速度为你选择，而不是按你的个人风险阈值。技术上，你整张卡片学到的同一台机器就在选择背后：solver接受你的意图并通过特定桥执行––你只是看不到是哪个。抽象转移了决策，但没有取消它：有人仍在选择桥，只是现在不再是你了。 ::: :::

:::quiz{id=q-3-5-s7 correct=2 explanation="Correct. ERC-7683 is a common language for intents – one order format any solver can execute through whatever bridge sits underneath. It standardizes the "what," not the "how": notably, it doesn't solve verification, so the trust questions from §2 and §5 still live one level down."} What is ERC-7683, exactly?

• A new, safer bridge that replaces the old ones
• A verification method that makes bridges trustless
• A standard for expressing intent that any solver can fulfill through any bridge
• A token you stake to insure your transfers :::