# Why atomicity is hard This opening slide shows two independent blockchains evolving side by side. A transfer on one chain can finalize before the matching transfer on the other, creating dangerous middle states where the trade is partially complete. The key idea is that failures like delay, message loss, or a counterparty disappearing are not exotic; they all fit naturally inside that timing gap. Because chain A cannot natively verify chain B's state, atomic cross-chain exchange needs extra protocol structure. This motivates <ref slide="2">The atomic swap goal</ref>, then the concrete designs in <ref slide="3">Escrow and lock flow</ref> and <ref slide="5">HTLCs across chains</ref>, which we later compare in <ref slide="6">Escrow vs HTLC tradeoffs</ref>. ## The atomic swap goal The goal of an **atomic swap** or atomic cross-chain transfer is simple to state and difficult to implement: the system should end in one of only two acceptable outcomes. - The swap fully completes on both chains. - The swap safely unwinds so each side keeps or recovers its original asset. What must not become permanent is a **partial completion state**. Those states may appear temporarily while the protocol is still in progress, but they should always be either completed or reversed. This is an important mindset shift. The protocol is not trying to eliminate all intermediate risk instantly; it is trying to make risky states **temporary and recoverable**, never the final resting place of user funds. <viz id="1"></viz> **Drag the progress marker** through the sequence and **toggle between outcomes**. Look for which states are marked as acceptable endpoints and which are only temporary. **Pay special attention to whether a red state can recover back to safety or gets stuck there.** Once you see the problem this way, protocol design becomes much clearer. You are building a process that channels every failure into a safe rollback path, rather than hoping failures do not happen. From here, there are two major coordination patterns to study. One uses a coordinating custodian or bridge-style lockbox, and the other uses cryptographic conditions and timeouts. We’ll start with the escrow pattern in <ref slide="3">Escrow and lock flow</ref>. ## Escrow and lock flow An **escrow-based flow** introduces a neutral coordination point between the two chains. Instead of immediately destroying or releasing assets, the protocol first places value into a controlled **lock state**. That lock acts like a safety buffer: funds are committed, but not yet irreversibly gone. Why does this help? Because if the destination-side action fails, the source-side asset is still recoverable. The protocol can return it rather than leaving the user stranded in a partial completion state. Conceptually, this is similar to putting goods in a warehouse before confirming that payment and delivery are both ready. The warehouse is not the final destination; it is a staging area that prevents one side from making an irreversible move too early. <viz id="2"></viz> **Step through the flow one stage at a time**. First **lock the source asset**, then **send the bridge signal**, then **trigger the destination preparation**. After that, **switch to the failure branch** and watch what happens when confirmation never arrives. **Notice that the asset stays in escrow instead of being destroyed too early.** The key safety property here is ordering. By locking first, the protocol delays the irreversible step until it has stronger evidence that the destination-side action is ready or complete. This also reveals the main tradeoff: escrow improves safety by adding a coordinating party or mechanism that temporarily controls funds. The exact trust assumptions depend on who operates that escrow and how its decisions are verified. A particularly important variant is the “burn only after success is confirmed” pattern, which we’ll examine next in <ref slide="4">Burn after mint confirmation</ref>. ## Burn after mint confirmation In a **burn-after-mint-confirmation** flow, the source-side asset is not burned immediately. Instead, it is first locked in escrow. A bridge message then asks the destination chain to mint the corresponding asset there. Only once the mint is successfully confirmed does the protocol perform the source-side burn. This ordering matters a lot. A **burn** is irreversible, so doing it too early creates the exact failure mode we want to avoid: the source asset is gone, but the destination asset never appears. By postponing the burn, the protocol keeps a recovery path open. This slide focuses on the **SoW burn flow** idea: lock first, mint second, burn last. If minting fails, the source tokens remain recoverable because they were never prematurely destroyed. <viz id="3"></viz> **Replay the success path** and watch the order carefully: **lock, message, mint, confirm, then burn**. Then **switch to the failed mint path**. **Notice that the burn never happens**, and the source-side tokens can return from escrow. This is one of the clearest examples of using sequencing to enforce atomicity. You are not making uncertainty disappear; you are arranging irreversible actions so uncertainty resolves before damage can occur. The price is that some actor or system must reliably report whether the destination mint really succeeded. So the mechanism is safer than “burn first,” but it still depends on how trustworthy and robust the bridge confirmation process is. An alternative avoids a trusted escrow-style coordinator by using cryptographic locks and deadlines. That is the idea behind <ref slide="5">HTLCs across chains</ref>. ## HTLCs across chains An **HTLC** is a **Hashed Timelock Contract**. It combines two ingredients: - a **hashlock**, which says funds can be claimed only by revealing a secret whose hash matches a known value - a **timelock**, which says if that claim does not happen before a deadline, the funds can be refunded This creates a clever coordination trick across chains. The same secret can unlock value on both chains. Once one party reveals it to claim on one chain, the secret becomes public, allowing the other side to complete the matching claim on the other chain. The timelocks are what make the flow safe. One deadline must be longer than the other, so the party who learns the secret second still has enough time to use it before their refund window closes. <viz id="4"></viz> **Set up the two locks**, then **click to reveal the secret** on one chain. Watch how that same secret becomes usable on the other side. Next, **adjust the two timelocks**. **Try making the deadlines too close together** and notice how safety breaks when there is not enough time to react. The aha insight is that the secret itself becomes the bridge signal. No escrow agent has to declare success; the on-chain revelation of the preimage is the proof. But HTLCs shift complexity elsewhere. They require more active coordination, careful deadline design, and compatible smart contract support on both chains. In practice, that makes them elegant but not always the easiest operational choice. Now that you have both patterns, we can compare when each one fits best in <ref slide="6">Escrow vs HTLC tradeoffs</ref>. # Escrow vs HTLC tradeoffs This slide compares escrow-style locks with HTLCs side by side using four controls: trust level, latency, failure mode, and user coordination. It connects the mechanisms from <ref slide="3">Escrow and lock flow</ref> and <ref slide="5">HTLCs across chains</ref> to practical scenario choices instead of treating one design as universally best. Key takeaway: escrow often fits better when a trusted bridge exists and operational delays are the main problem, because the intermediary can smooth over retries and stalled message delivery. HTLC fits better when no trusted intermediary is acceptable or when a counterparty may disappear, because each side gets a timeout-based escape hatch without asking a middle party to behave. The learner should leave with a tradeoff lens: escrow buys smoother recovery by adding trust, while HTLC removes trust by adding timing and coordination constraints.