## Why Bridges Matter **Blockchains** are separate systems with their own rules, histories, and assets. A token on one chain does not automatically “exist” on another, because the second chain cannot normally inspect or trust the first chain’s state. That is the core reason **bridges** exist: they create a controlled way to move **value** or **messages** between chains that do not share state. A useful intuition is to picture each chain as its own island ledger. You can update ownership inside one island easily, but you cannot just toss a token across the water and expect the other island to accept it. Something has to **verify** what happened on the source side and then trigger the corresponding result on the destination side. This matters because users and apps want access to different ecosystems: maybe liquidity is on one chain, an app is on another, and a user wants both. Without a bridge, these ecosystems stay isolated. <viz id="0"></viz> **Click a token** on the left chain and **try sending it directly** to the right chain. Notice that the transfer fails. Then **activate the bridge path** and **send the token again**. Watch how the movement now goes through an extra verification step instead of jumping straight across. The key idea is that the bridge is not a magic tunnel. It is a **coordination system** that translates an event on one chain into an accepted outcome on another. That translation step is the whole game. Once you see that, the next question becomes: what exactly happens during a transfer? In many bridges, the answer is not “move the same token,” but “**lock** something here and **create a representation** there.” That mechanism is the foundation for the common bridge flow in <ref slide="2">Lock And Mint Flow</ref>. ## Lock And Mint Flow A common bridge pattern is **lock and mint**. Instead of physically moving an asset between chains, the bridge **locks** the original asset on the source chain and **mints** a corresponding wrapped version on the destination chain. On the way back, the wrapped token is **burned**, and the original asset is **released**. The big intuition is this: value is not teleported. It is **accounted for across two ledgers**. If `10` tokens are locked on Chain A, the bridge can allow up to `10` wrapped tokens to exist on Chain B. The bridge is maintaining a relationship between the locked reserve and the issued representation. This is why wrapped assets depend so heavily on bridge correctness. If the bridge mints too much, releases too much, or accepts a fake event, the accounting breaks. <viz id="1"></viz> **Drag a token into the source-chain vault**. Then **step through the timeline** one stage at a time: deposit, proof, mint, burn, and release. Watch the source balance, vault contents, and wrapped-token supply change together. Notice the accounting invariant: when the wrapped token exists on the destination chain, the original token is not freely circulating on the source chain. It is being held in reserve. That is what keeps the system from creating value out of thin air. This also reveals the bridge’s critical dependency: someone or something must decide that the source-chain deposit really happened before minting on the destination side. That brings us to the most important design question in bridging: **who verifies what**. Different answers create very different trust and security profiles, which you will compare in <ref slide="3">Who Verifies What</ref>. ## Who Verifies What Most bridge designs differ less in *what* they want to achieve and more in **who or what performs verification**. When Chain B accepts a message that says, “funds were locked on Chain A,” what convinces it that this is true? That verifier might be a **trusted operator**, a **multisig or MPC committee**, an on-chain **light client**, an **optimistic** mechanism that allows challenges, or a **liquidity network** that solves the problem in a different way. Each approach makes a different tradeoff among **trust**, **latency**, **cost**, **complexity**, and **capital efficiency**. A helpful way to think about bridge architecture is: where is the real security boundary? Is it a small signer set? A verification contract? A challenge window? Pre-positioned liquidity? The answer tells you what must go right for the bridge to be safe. <viz id="2"></viz> **Switch between the bridge designs** using the tabs or buttons. Then **hover over the verifier components** in each lane. Watch how the transfer path changes, and compare the indicators for trust, speed, and cost. The aha insight here is that a bridge is really a **verification machine** wrapped around an asset or message flow. If you know who verifies events and under what assumptions, you already understand a large part of the risk model. One especially important split is between bridges that create a canonical wrapped asset and bridges that simply source liquidity on the destination chain. Those can feel similar to users, but the mechanics and risks are very different. That contrast is the focus of <ref slide="4">Liquidity Vs Canonical</ref>. ## Liquidity Vs Canonical Not all bridges mint a wrapped token. A **canonical bridge** often follows the lock-and-mint model: lock the original asset on one chain, then mint its representation on another. A **liquidity bridge**, by contrast, may pay you out from pre-positioned funds on the destination chain instead of creating a new wrapped asset for that transfer. That difference changes the user experience. Liquidity bridges can feel **faster**, because the destination-side funds are already there. But they also depend on **inventory** being available in the right place and size. If pools become imbalanced or a transfer is too large, costs and delays can rise. So the key tradeoff is not just speed. It is also **wrapped-token exposure** versus **liquidity and routing constraints**. <viz id="3"></viz> **Toggle between the two bridge types** and **move the transfer-size slider** from small to large. Watch what happens to wait time, slippage, pool balance, and whether you end up holding a wrapped asset. A good mental model is that canonical bridges emphasize **correct cross-chain accounting**, while liquidity bridges emphasize **fast settlement from available inventory**. Neither is automatically “better”; they optimize for different things. That distinction becomes very important in security analysis. Wrapped-asset systems concentrate risk around verification and custody, while liquidity systems add inventory, routing, and pool-balance concerns. To reason clearly about failures, you need to see the stack of components where assumptions can break, which is exactly what you will inspect in <ref slide="5">Where Bridges Break</ref>. ## Where Bridges Break Bridge failures usually do not come from some mysterious cross-chain force. They come from ordinary security boundaries failing in a cross-chain setting: **smart contract bugs**, **bad proof verification**, **compromised signers**, **key management failures**, **replay handling mistakes**, **oracle issues**, or **governance abuse**. In other words, the bridge is only as strong as its weakest critical component. If a verifier accepts a fake message, if an admin can push a malicious upgrade, or if enough keys are stolen to authorize withdrawals, funds can be minted, released, or redirected incorrectly. This is why bridge analysis has to be layered. You need to ask not just “is the bridge decentralized?” but “which exact component can cause theft or freezing if it fails?” <viz id="4"></viz> **Select different attack cards** one by one. Watch which layers of the bridge stack light up, crack, or turn red. Compare how each attack changes the likely impact and the root cause. The main lesson is that a bridge’s advertised design category tells only part of the story. Two bridges that both call themselves “multisig” can still have very different practical risk depending on key storage, upgrade powers, contract quality, and operational discipline. Once you can localize failures to specific components, you are ready for a more systematic method: build a **threat model**. That means writing down assets, assumptions, attackers, and failure paths explicitly instead of relying on vague trust. You will do that next in <ref slide="6">Threat Model The Bridge</ref>. ## Threat Model The Bridge A **threat model** is a structured way to reason about security. For a bridge, it asks four practical questions: - What **assets** are at risk? - Which **actors** or components are trusted? - What **assumptions** must hold? - What can an **attacker** do, and what fails if those assumptions break? This is powerful because it turns “Is this bridge safe?” into a more precise question: **what has to go wrong before funds are stolen, frozen, or censored?** That framing is much more useful than broad labels like “decentralized” or “secure.” For example, if your bridge assumes an honest signer threshold, secure key custody, and correct proof validation, then each of those becomes a possible attack path. Threat modeling makes those paths visible. <viz id="5"></viz> **Drag assumptions into the canvas** and then **toggle different attacker powers**. Watch the attack paths change color, and note whether the result becomes theft, censorship, or a temporary freeze. The big payoff is clarity. Instead of memorizing bridge brands or buzzwords, you learn to ask: what protects funds, who can override the system, and what independent failures would be required for a catastrophic loss? That mindset also helps with practical decisions. Designers can reduce assumptions, integrators can choose safer dependencies, and users can decide what level of trust they are actually accepting. The final step is to translate that thinking into concrete defensive practices, which you will explore in <ref slide="7">Safer Bridge Practices</ref>. ## Safer Bridge Practices Strong bridge security comes from **defense in depth**. No single mechanism makes a bridge safe. Instead, good systems combine **minimal trust**, **hardened key management**, **limited upgrade power**, **monitoring**, **rate limits**, **delay timers**, **circuit breakers**, and careful engineering practices like audits and, where appropriate, formal verification. A useful intuition is to separate defenses into three jobs: - **Prevent** bad actions, like strong verification or better key custody - **Limit blast radius**, like withdrawal caps or rate limits - **Buy response time**, like timelocks, monitoring, and emergency pauses This matters because some controls reduce the chance of compromise, while others mainly reduce how much damage can happen before humans respond. Both are valuable, but they solve different problems. <viz id="6"></viz> **Adjust the defense controls** one at a time and then **run the simulated attacks**. Compare how the settings change blast radius, detection time, user impact, and available recovery options. The final takeaway is that bridges are not just about moving assets. They are about **managing trust across systems that cannot natively verify each other**. Good bridge design starts with clear assumptions, and good bridge use starts with understanding those assumptions. If you leave with one habit, make it this: **ask what verifies the message, who controls upgrades or keys, and what limits losses if that trust fails**. That question set is often more revealing than any headline label about speed, decentralization, or convenience.