If one examines the history of human commerce, it is, at its core, a history of trying to solve a single, persistent problem: the problem of the counterparty. When two individuals wish to trade (whether it is grain for gold in ancient Mesopotamia or Bitcoin for Monero in the digital ether) there exists a moment of profound vulnerability. It is the moment when one asset has left one hand, but the other asset has not yet arrived. In that split second, or hour, or block time, trust is required. And trust, as history has repeatedly demonstrated, is a security hole.

For five thousand years, the solution to this problem was the introduction of a third party. The village elder, the escrow agent, the clearinghouse, the bank. These intermediaries served a vital function. They bridged the gap of trust. Alice did not need to trust Bob; she only needed to trust the bank. Bob did not need to trust Alice; he only needed to trust the bank. This model allowed civilization to scale. It allowed trade to cross oceans. It built the modern world.

But this solution came with a hidden cost. By centralizing trust, we centralized power. We created points of failure. We created gatekeepers who could extract rents, censor transactions, and surveil participants. The bank vault became a panopticon. The intermediary became the master.

When the internet arrived, it promised to disintermediate the world. In the realm of information, it succeeded. One does not need a post office to send an email. One does not need a broadcast tower to publish a video. But in the realm of value, the internet stalled. For twenty years, online commerce was simply traditional banking with a web interface. PayPal was just a faster bank. The structure remained the same: Alice and Bob still needed a middleman.

Then came Bitcoin. For the first time, we had a mechanism for peer to peer value transfer without a trusted intermediary. It was a revelation. But it was an island. Bitcoin existed in its own universe, secure and immutable. Then came Ethereum, Litecoin, Monero, and a thousand other chains, each an island unto itself.

The problem of the counterparty returned. How does one move value from the island of Bitcoin to the island of Ethereum?

The obvious solution (the solution that the vast majority of the cryptocurrency industry rushed to build) was to recreate the bank. They called them "bridges." They built massive, centralized (or semi-centralized) vaults that lock up assets on one chain and issue IOUs on another. They rebuilt the very structures that blockchain was invented to dismantle.

This report argues that this was a mistake. A profitable mistake, perhaps, in the short term, but a catastrophic error in architectural design. There is another way. It is harder to build. It is harder to use. It involves a kind of "schlep" (a tedious, complex undertaking) that most developers have avoided. It is called the Hashed Timelock Contract, or HTLC.

The HTLC is not a bank. It is a mechanism. It is a piece of logic that allows Alice and Bob to trade directly, peer to peer, without ever trusting each other and without anyone else holding their funds. It is the digital equivalent of a robotic vending machine made of indestructible glass, placed in a neutral zone where no government has jurisdiction.

This analysis asserts that despite the friction, despite the difficulty, and despite the current dominance of custodial bridges, the HTLC (and its privacy-preserving evolution, the Scriptless Script) is the only correct mechanism for cross-chain swaps. It is the only architecture that preserves the fundamental properties of crypto: trustlessness, censorship resistance, and privacy.

To understand why the HTLC is necessary, one must first confront the failure of the alternative. In the software world, there is a concept often observed where the "industry standard" solution is bloated, insecure, and corporate, while the "hacker" solution is elegant, minimal, and initially unpopular. In cross-chain interoperability, the "Java" of the industry (the corporate, heavy standard) is the Cross-Chain Bridge. The "Python" (the hacker's choice) is the Atomic Swap.

A cross-chain bridge is fundamentally a custodial service, even if it claims to be decentralized. The mechanism is almost always a variation of "Lock and Mint". When a user wants to move Bitcoin to Ethereum to use it in Decentralized Finance (DeFi), they do not actually move the Bitcoin. The Bitcoin blockchain cannot talk to the Ethereum blockchain. They speak different languages; they have different consensus rules.

So, the user sends their Bitcoin to a specific address controlled by the Bridge. This is the "Lock." The Bridge observes this transaction. Once it is confirmed, the Bridge's smart contract on Ethereum mints an equivalent amount of a new token (say, Wrapped Bitcoin, or wBTC) and sends it to the user's Ethereum address. This is the "Mint".

The user now holds wBTC. But what is wBTC? It is a claim check. It is an IOU. Its value depends entirely on the fact that the original Bitcoin is sitting safely in the Bridge's vault. If that vault is opened, or if the key is stolen, the wBTC becomes worthless.

This architecture creates a "honeypot." In the physical world, bank robbers rob banks because that is where the money is. In the crypto world, hackers hack bridges because that is where the liquidity is pooled.

When a bridge becomes successful, it accumulates massive amounts of assets. A popular bridge might hold 100,000 Bitcoin. This becomes a single point of failure worth billions of dollars. For a hacker, the return on investment for finding a single bug in the bridge's code, or compromising a single private key (or a small threshold of keys in a multi-sig setup), is astronomical.

This is not theoretical speculation. The history of crypto bridges is a history of devastation. In 2022 alone, bridge hacks accounted for 69% of all stolen crypto funds, totaling over $2 billion.

Consider the Ronin Bridge hack. The Ronin Network was built to support the popular game Axie Infinity. To move funds in and out, they built a bridge. It was secured by a multi-signature scheme with nine validators. To withdraw funds, five of the nine signatures were needed. This sounds secure. It sounds decentralized. But it wasn't. The attackers managed to compromise the private keys of five validators. Once they had those keys, they simply drained the bridge. They took $625 million in USDC and Ethereum. The users who held the "wrapped" assets on the Ronin chain were left holding empty bags. Their claims were backed by nothing.

Consider the Wormhole Bridge hack. In this case, it wasn't a stolen key; it was a bug in the smart contract logic. The attacker found a way to trick the bridge into thinking a deposit had been made on Solana without actually depositing the funds. The bridge, following its code, minted 120,000 Wrapped ETH on Solana. The hacker then sold this "air" for real assets, draining the bridge of over $320 million.

These are not anomalies. They are the inevitable result of the bridge architecture. By pooling assets, bridges concentrate risk. They ask users to trust that the code is perfect and that the operators are incorruptible. In a field defined by the maxim "Don't Trust, Verify," bridges are a massive regression.

But the security risk, as severe as it is, is arguably the lesser of two evils. The deeper issue (the one that makes bridges fundamentally incompatible with the long-term vision of a free society) is privacy. Bridges are surveillance machines.

When a user interacts with a bridge, they leave a permanent, immutable trail. They send funds from Address A on Chain X to the Bridge. The Bridge sends funds to Address B on Chain Y. This link is public. It is recorded on the blockchain forever.

Companies like Chainalysis, TRM Labs, and Elliptic have built billion-dollar businesses around tracking these flows. They market "cross-chain tracing" tools that allow law enforcement, tax authorities, and compliance officers to follow the money across the bridge.

If Alice sends Bitcoin to a bridge, and Bob receives Wrapped Bitcoin on Ethereum, an observer can easily correlate the timing and the amount. "User sent 10.5 BTC at 10:00 AM; User received 10.5 wBTC at 10:15 AM." The probability that these are the same person is near 100%.

The bridge acts as a choke point. Because it is a centralized or semi-centralized entity with a physical presence (servers, developers, a legal entity), it is subject to regulation. It can be pressured.

We are already seeing this. Bridges are implementing "lists" of blocked addresses. They are integrating "Know Your Transaction" (KYT) software. If a user tries to bridge funds that have ever touched a "tainted" address (like a gambling site or a mixer), the bridge can freeze the funds.

This destroys fungibility. It creates two classes of crypto: "Clean" crypto that has been blessed by the compliance tools, and "Dirty" crypto that is rejected by the bridges.

The "Lock and Mint" model is a privacy nightmare because the "Mint" event on the destination chain is cryptographic proof of the user's history on the source chain. The user's identity bleeds across the partition.

This is the "Schlep Blindness" of the modern crypto user. Users accept the surveillance and the security risk because bridges are convenient. They are fast. They have high liquidity. But they are building their financial lives on a foundation of sand.

If one rejects the bridge (if one refuses to trust a third party with custody) what is left? One must return to first principles. How can Alice send Bitcoin to Bob, and Bob send Litecoin to Alice, such that neither can cheat, and no one else holds the money?

The answer lies in the concept of "atomicity." In computer science, specifically in database theory, an operation is atomic if it is indivisible. It either happens completely, or it does not happen at all. There is no middle state. You cannot be half-pregnant, and in an atomic swap, you cannot be half-paid.

The mechanism that enables this in a trustless environment is the Hashed Timelock Contract (HTLC). The HTLC is built on two simple cryptographic primitives: the Hashlock and the Timelock.

The Hashlock (The Secret) allows us to lock funds such that they can only be spent by revealing a secret. It uses a hash function (like SHA-256). A hash function is a one-way street. Alice can pick a random number (the "preimage" or secret) and calculate its hash. She can give the hash to the world. No one can derive the secret from the hash. But if Alice reveals the secret, anyone can instantly verify that it matches the hash.

The Timelock (The Safety Valve) allows us to lock funds for a specific period of time. It says, "These funds cannot be moved until Block #800,000." This is crucial for preventing funds from getting stuck forever if a counterparty disappears.

The protocol for combining these into a swap is often credited to Tier Nolan, who outlined the mechanics on the BitcoinTalk forum in 2013. It is a game-theoretic dance that forces honesty. Let us trace the steps of a Bitcoin (BTC) to Litecoin (LTC) swap between Alice and Bob. Alice holds BTC; Bob holds LTC.

In Step 1 (The Setup), Alice creates a secret key (let's call it S). She calculates the hash of this secret: H = Hash(S). Alice does not tell Bob the secret S. She only gives him the hash H.

In Step 2 (Alice Locks), Alice creates a transaction on the Bitcoin blockchain. She sends 1 BTC to a special script address (a P2SH or P2WSH address). This script has two conditions: Condition A states that Bob can spend this 1 BTC if he provides the secret S and his signature. Condition B states that Alice can refund the 1 BTC to herself after 48 hours (the timelock). Alice broadcasts this transaction. The 1 BTC is now locked. Bob can see it. He can verify that the hash H is correct. But he cannot spend it because he doesn't know S.

In Step 3 (Bob Locks), Bob sees Alice's commitment. He is satisfied. Now he creates a transaction on the Litecoin blockchain. He sends 100 LTC to a script address. This script uses the exact same hash H. Condition A states that Alice can spend this 100 LTC if she provides the secret S and her signature. Condition B states that Bob can refund the 100 LTC to himself after 24 hours. Note the timing: Bob's timelock (24 hours) must be shorter than Alice's (48 hours). This is a critical security parameter. If Bob's lock lasted longer than Alice's, Alice could wait for her refund, get her BTC back, and then still use the secret to take Bob's LTC. The staggering of timelocks prevents this exploit.

In Step 4 (Alice Claims), Alice sees that Bob has locked the LTC. She has the key S. She wants the LTC. She creates a transaction on the Litecoin blockchain to spend the 100 LTC to her own wallet. To do this, the network requires her to provide S. She broadcasts the transaction. The Litecoin network verifies S matches H, and gives her the funds. Crucially, by broadcasting this transaction, Alice reveals S to the entire world. It is now recorded on the public Litecoin blockchain.

In Step 5 (Bob Claims), Bob is watching the Litecoin blockchain. He sees Alice's transaction. He looks at the input data and sees the secret S. He copies S. He goes to the Bitcoin blockchain. He uses S to fulfill the condition on Alice's initial transaction. The Bitcoin network verifies S matches H, and gives Bob the 1 BTC.

In Step 6 (The Equilibrium), the swap is complete. Alice has LTC. Bob has BTC. Neither party ever had custody of the other's funds. Neither party could steal. If Alice disappears after Step 2? Bob waits 48 hours (technically, he doesn't have to wait, he just never locks his funds). If Bob locks his funds and Alice disappears? Bob waits 24 hours and refunds his LTC. Alice then waits 48 hours and refunds her BTC. The system is "trustless." The security is guaranteed by the consensus rules of Bitcoin and Litecoin, not by a server.

While this mechanism is secure against theft, it is not perfectly efficient. It suffers from what financial theorists call the "free option" problem. Between Step 2 (Alice locks) and Step 3 (Bob locks), or Step 3 and Step 4 (Alice claims), time passes. Markets move. If the price of Bitcoin crashes 20% while the swap is setting up, Alice (who is effectively buying LTC) might decide she doesn't want the deal anymore. She holds the secret. She can simply choose not to reveal it. She lets the clock run out. Bob gets his LTC back after 24 hours. Alice gets her BTC back after 48 hours. No funds are lost, but Bob has lost time. He locked up his capital for 24 hours for a deal that didn't happen. This is "griefing." This inefficiency makes atomic swaps difficult for high-frequency trading. They are slow. But for a user who values sovereignty (who wants to move large amounts of value without risk of confiscation) the "schlep" of the wait time is a price worth paying.

If the HTLC is so robust, why is this report arguing for a "privacy-focused" evolution? Because the standard HTLC, as described above (and as used in the Lightning Network), has a fatal flaw when it comes to privacy. It works too well in the open.

The genius of the HTLC is that it links the two chains using a shared secret hash H. This ensures atomicity. But that same link destroys privacy. Blockchains are transparent. An observer (or a surveillance firm like Chainalysis) can scan the Bitcoin blockchain and the Litecoin blockchain. They see Bitcoin Chain: Transaction A locked with Hash(X). They see Litecoin Chain: Transaction B locked with Hash(X).

The hash H acts as a "unique identifier" or a "correlation tag." Even though Bitcoin and Litecoin are separate networks, the presence of the identical hash string H in the script of both transactions cryptographically links them. If the observer knows Alice's identity on the Bitcoin chain (perhaps she withdrew from a KYC exchange like Coinbase), they can now link her to the Litecoin transaction. They know Alice owns that Litecoin address. The privacy partition is breached.

Furthermore, the very structure of the transaction stands out. Most Bitcoin transactions are simple payments (Pay-to-Public-Key-Hash). An HTLC transaction is a complex script involving OP_SHA256, OP_EQUALVERIFY, and OP_CHECKLOCKTIMEVERIFY. To a surveillance algorithm, an HTLC transaction looks different from a normal payment. It glows in the dark. It signals, "This is not a simple payment; this is a swap." This allows analysts to filter and flag these transactions for higher scrutiny.

This is the "Privacy Paradox" of the first-generation HTLC. It removes the central intermediary (good for privacy), but it creates a permanent, public, verifiable link between the sender and receiver across chains (bad for privacy). For true privacy, we need to go deeper. We need the swap to be invisible. We need the transaction to look like a standard payment, with no hashlocks and no scripts visible to the network.

The evolution of technology often moves from the visible to the invisible. The first machines were loud and clunky. Modern technology disappears into the background. The same is happening with cryptographic protocols.

The solution to the privacy leakage of HTLCs is a concept known as Scriptless Scripts, utilizing a cryptographic primitive called Adaptor Signatures. This technology allows us to perform the atomic swap without putting the condition on the blockchain.

The magic relies on the mathematical properties of Schnorr signatures (and similar schemes). Schnorr signatures have a property called "linearity." This means you can add two private keys together to get a combined private key, and adding their respective public keys together gives the correct combined public key: PubKey(A) + PubKey(B) = PubKey(A+B). This linearity allows for "multisig" transactions that look exactly like single-signature transactions. To the blockchain, it just looks like a public key signed a message. It doesn't know that the public key is actually an aggregation of Alice and Bob's keys.

The Adaptor Signature takes this a step further. It allows Alice to sign a transaction with a "partial" signature that is encrypted with a secret. Here is the simplified workflow of a Scriptless Script swap: In the Off-Chain Negotiation phase, Alice and Bob communicate directly (off-chain). They agree on the terms. They exchange public keys. For The Split Key, they create a 2-of-2 multisig address on each chain. Crucially, they use key aggregation, so on the blockchain, this address looks like a normal, single-user address. For The Adaptor, Alice creates a signature for the transaction on Chain A, but she "blinds" it with a secret value T. She gives this "Adaptor Signature" to Bob. This signature is not valid yet. It cannot be broadcast. However, Bob can mathematically verify that if he learns the secret T, he can fix the signature and make it valid. The Link is the magic: Alice constructs the adaptor signature such that if Bob uses the corresponding secret to sign his side of the deal on Chain B, the act of publishing his signature reveals the secret T to Alice.

During The Execution, Bob signs on Chain B. His transaction is broadcast. It looks like a normal payment. Alice sees Bob's signature on Chain B. Because of the mathematical relationship established off-chain, she can extract the secret T from Bob's signature. Alice uses T to unblind her own signature for Chain A. She broadcasts it. It looks like a normal payment.

The result is profound. On Bitcoin, the blockchain records a standard payment from Address X to Address Y. On Litecoin, the blockchain records a standard payment from Address Z to Address W. There is no hashlock. There is no OP_SHA256 in the script. There is no shared identifier H visible on-chain. To an external observer (even one with the power of the NSA or Chainalysis) these two transactions are completely uncorrelated. They are just two drops in an ocean of noise. This is the holy grail of cross-chain privacy. It decouples the security of the swap (which is absolute) from the visibility of the swap (which is zero).

The ultimate test of any privacy technology is its compatibility with Monero (XMR). Monero is the only major cryptocurrency that is private by mandatory default. It uses Ring Signatures to hide the sender, Stealth Addresses to hide the receiver, and RingCT to hide the amount.

For years, doing an atomic swap between Bitcoin and Monero was considered the "impossible schlep." Bitcoin uses the secp256k1 elliptic curve. Monero uses the edwards25519 elliptic curve. Monero does not support the scripting language (Script) required for HTLCs. It doesn't have "smart contracts" in the way Bitcoin or Ethereum do. If you cannot write a script on Monero, how can you make a Timelock? How can you make a Hashlock?

The solution came from the open-source community, driven by researchers like the COMIT team and Farcaster. They utilized a variation of the adaptor signature scheme that bridges the gap between the two cryptographic curves. They developed a protocol using Zero-Knowledge Proofs (ZKPs). Alice generates a secret on the Bitcoin curve. She needs to prove to Bob that this secret corresponds to a key on the Monero curve, without revealing the secret. She generates a ZKP (a mathematical proof) that certifies: "I know a number x such that x is the discrete log of Point A on the Bitcoin curve AND x is the discrete log of Point B on the Monero curve."

This allows the swap to proceed. The Bitcoin Side uses a scriptless script or specific taproot script. The Monero Side uses a purely cryptographic lock (view key sharing) rather than a script lock. When the swap executes, the Bitcoin transaction looks like a standard spend. The Monero transaction is essentially invisible because all Monero transactions are obfuscated.

This creates a one-way privacy diode. You can move from the transparent world of Bitcoin into the dark world of Monero without leaving a link. Once in Monero, the trail ends. The history is washed. This is the "killer app" for privacy preservation. It allows users to exit the surveillance grid of public blockchains without going through a centralized gatekeeper.

If this technology is so superior (trustless, private, secure) why isn't everyone using it? Why is $50 billion locked in bridges while atomic swaps remain a niche tool for cypherpunks? The answer is the "Schlep." Atomic swaps are hard to use and hard to price.

A bridge transaction is fast. It feels like using a centralized exchange. You send funds, the bridge server sees it (often instantly, trusting zero confirmations or just one), and credits you on the other side. An atomic swap is bound by the consensus speed of the underlying chains. If you are swapping Bitcoin, you are beholden to the 10-minute block time. For security, you typically wait for 2 confirmations before initiating the next step. Step 1: Wait 20 mins for Alice's lock. Step 2: Wait 20 mins for Bob's lock. Total time: 40 to 60 minutes. In a world addicted to instant gratification, waiting an hour for a trade feels like an eternity.

For the person providing liquidity (Bob), the atomic swap presents a financial risk. When Bob locks his Litecoin, he is effectively giving Alice a "free American call option." Alice has the right, but not the obligation, to complete the swap. If the price of Bitcoin crashes 10% during the 1-hour setup process, Alice can simply walk away. She doesn't reveal the secret. The swap fails. Bob gets his Litecoin back, but he has held the bag during the crash. He lost the opportunity to sell his Litecoin elsewhere. This "optionality" means that market makers have to charge higher fees to compensate for the risk of griefing. This widens the spread, making atomic swaps more expensive than centralized exchanges.

Bridges rely on "Pools." Everyone dumps their money into one big pot. This makes liquidity fungible and easy to access. Atomic swaps are "Peer-to-Peer." You have to find a specific counterparty who wants exactly what you have. It is the difference between an Uber (pooled transport) and hitchhiking (P2P). Matching engines can help, but the liquidity is fundamentally fragmented.

The solution to the UX and liquidity problem is not to make users run atomic swaps manually. It is to abstract the complexity away. We are seeing the rise of Intent-Based Architectures (e.g., UniswapX, CowSwap, Across, Anoma). In this model, the user does not propose a transaction. They propose an intent. The User Intent is simple: "I want 1000 USDC on Ethereum in exchange for my 0.05 BTC. I am willing to pay up to 1% fee." The user signs this intent cryptographically.

This intent is broadcast to a network of professional "Solvers" (also called Relayers or Fillers). These are sophisticated actors running automated bots. The Solvers compete to fill the order. Solver A says: "I can do it for 0.9% fee." Solver B says: "I can do it for 0.8% fee." The winner (Solver B) immediately sends the 1000 USDC to the user on Ethereum. They do this out of their own pocket. They take the inventory risk. They provide the speed. Now, the Solver needs to get paid. The protocol allows the Solver to claim the user's BTC. This settlement happens via an atomic mechanism (or an optimistic verification mechanism like Across).

This model flips the script. For Speed, the user gets their funds instantly (because the Solver fronts the capital). For Liquidity, the user taps into the Solver's private inventory, not a fragmented P2P order book. For Security, the atomicity is preserved. The user only releases their BTC if they get the USDC. The protocol enforces this. For Privacy, the complexity of the swap is handled by the Solver. The user just sees a simple transfer. The "Schlep" of managing the state, watching the blockchain, and hedging the price risk is moved from the User to the Solver. The Solver is paid a fee to handle the Schlep. This is the division of labor that allows the system to scale.

There is a final, pragmatic argument for the inevitability of the atomic/scriptless model: Regulation. Regulators globally are cracking down on crypto "on-ramps" and "off-ramps" and "bridges." They view bridges as Money Service Businesses (MSBs) or Virtual Asset Service Providers (VASPs). The Financial Action Task Force (FATF) "Travel Rule" requires these entities to collect data on senders and recipients.

A centralized bridge can be regulated. Its servers can be seized. Its developers can be arrested (as happened with Tornado Cash developers, although Tornado Cash was a mixer, not a bridge, the precedent of holding code writers accountable for the protocol's use applies). An atomic swap protocol cannot be regulated in the same way because there is no intermediary to regulate. Alice talks to Bob. They exchange signatures. They broadcast transactions to decentralized blockchains. There is no third party facilitation the swap. There is no server matching the orders (in a pure P2P sense).

If regulations make it impossible to operate a compliant non-custodial bridge (because a bridge technically holds funds, even if briefly), the only compliant way to move assets will be to not hold funds at all. Atomic swaps are the only architecture that satisfies the condition of "non-custodial exchange." As the regulatory walls close in, the "grey market" of privacy-focused users will migrate entirely to scriptless atomic swaps. It will be the only way to move value without a passport.

The "right" mechanism is rarely the easiest one. It is the one that aligns with the fundamental constraints of the environment. The environment of the blockchain is adversarial. It is a dark forest.

Centralized exchanges and bridges attempt to build safe houses in this forest. They work for a while. They are comfortable. But eventually, the wolves get in. The honey pot is too sweet; the target is too big.

The Hashed Timelock Contract, and its evolution into Scriptless Scripts and Adaptor Signatures, represents a different approach. It does not build a house. It builds armor for the traveler. It accepts the "schlep" of complexity, of latency, and of fragmentation, in exchange for the absolute guarantee that theft is impossible (Atomicity), surveillance is impossible (Unlinkability), and censorship is impossible (Decentralization).

The "Python Paradox" of crypto is that the tools that seem clunky and difficult today (the command-line atomic swaps, the Monero bridges) are the ones that will run the financial infrastructure of tomorrow. The bridges are the AOL of crypto: a walled garden that feels safe until you realize you are trapped. The atomic swap is the open web. For the privacy-focused user, there is no choice. The lock is the key to freedom.

Table 1: The Trust Spectrum in Cross-Chain Exchange

Centralized Exchange (CEX): Trust Model is Full Trust (Custodian), Privacy Level is None (KYC Required), Custody Risk is High (FTX, Mt. Gox), Primary Vulnerability is Insolvency / Fraud / Seizure.

Cross-Chain Bridge (Lock & Mint): Trust Model is Distributed Trust (Validators), Privacy Level is Low (Traceable), Custody Risk is High (Honeypot), Primary Vulnerability is Smart Contract Bugs / Key Theft ($2B+ lost/yr).

Standard HTLC Atomic Swap: Trust Model is Trustless (Code), Privacy Level is Medium (Timing Attacks), Custody Risk is None (Self-Custody), Primary Vulnerability is Griefing (Free Option) / Metadata Leaks.

Scriptless Script Swap (Adaptor Sig): Trust Model is Trustless (Math), Privacy Level is High (Unlinkable), Custody Risk is None (Self-Custody), Primary Vulnerability is Implementation Complexity / Liquidity.

Table 2: Privacy Leakage Vectors

Lock & Mint Bridge: On-Chain Footprint is Deposit to Bridge Contract, Linkability is High (Mint event cryptographically linked to Lock event), Observer Inference is "User A on Chain X sent funds to Bridge; User A on Chain Y received funds."

Standard HTLC: On-Chain Footprint is P2SH / Script Hash, Linkability is Medium (Shared Hash Preimage H), Observer Inference is "Transaction A and Transaction B use the exact same hash lock; they are the same swap."

Adaptor Signature: On-Chain Footprint is Standard Payment Signature, Linkability is None (No shared on-chain data), Observer Inference is "User A sent a payment. User B sent a payment. No visible connection."

Table 3: Economic Cost of Security

Bridge: Transaction Fee is High (Bridge fee + Gas + Slippage), Capital Efficiency is High (Instant liquidity from pool), Cost of Failure is Total Loss (Principal is gone), Settlement Time is Seconds/Minutes.

Atomic Swap (HTLC): Transaction Fee is Low (Network Gas only + Market Maker spread), Capital Efficiency is Low (Funds locked during swap duration), Cost of Failure is Time Loss (Funds refunded after timeout), Settlement Time is Minutes/Hours (Dependent on block confirmations).