Atomic Swap Failures Between Runes and Other Bitcoin Assets

Atomic swaps between Runes and other Bitcoin-native assets, such as inscriptions, rely on Hash Time-Locked Contracts (HTLCs) and Partially Signed Bitcoin Transactions (PSBTs) to achieve trustless exchange. However, the interaction between Runes' UTXO-based state model and Bitcoin's scripting system introduces failure modes not present in standard Bitcoin atomic swaps. A flaw in the construction of the swap—specifically in how the Runes protocol transfers tokens within an HTLC execution branch—can allow one party to claim both the Runes and the counterparty asset, or permanently lock both assets in an unrecoverable state.

The core risk lies in the mismatch between the atomicity expected by the swap contract and the actual atomicity provided by the Runes protocol's transfer semantics. A Runes transfer is executed by consuming a UTXO holding a specific Runes balance and creating new UTXOs with the appropriate distribution. If the HTLC script does not strictly bind the Runes distribution to the same spending conditions as the Bitcoin output, a party can satisfy the hashlock or timelock to claim the Bitcoin while structuring the transaction to redirect the Runes to an address they control, violating the swap's intent. Alternatively, an incorrectly constructed fallback path can lead to a deadlock where neither party can finalize the trade without the other's cooperation.

Teams building decentralized trading infrastructure for Runes should treat these swaps as a novel security domain, not a simple extension of existing Bitcoin HTLC patterns. A security review must verify that the PSBT construction enforces simultaneous asset transfer, that the Runes distribution is cryptographically bound to the same witness that satisfies the HTLC, and that all timeout and refund paths correctly handle the Runes-bearing UTXOs without allowing partial claim or permanent lockup. Chainscore Labs can conduct a targeted review of your atomic swap contract logic and PSBT construction to identify these failure modes before they result in asset loss.

Atomic swaps between Runes and other Bitcoin-native assets like inscriptions rely on Hash Time-Locked Contracts (HTLCs) and Partially Signed Bitcoin Transactions (PSBTs) to ensure that either both sides of the trade complete or neither does. The root cause of most failures is a fundamental impedance mismatch: standard HTLC patterns designed for homogeneous Bitcoin outputs do not account for the heterogeneous nature of UTXOs carrying Runes or inscriptions. A swap contract that correctly locks the bitcoin value of a UTXO may fail to constrain the transfer of the Runes or Ordinal data payload attached to it, allowing a counterparty to claim the bitcoin while the meta-protocol asset is routed to an unintended output or burned as fees.

The most common failure pattern occurs in the PSBT construction phase. When a swap is partially signed, the transaction's output structure must precisely map the intended asset transfer. A flaw in the PSBT's output ordering, an incorrect change address, or a missing OP_RETURN commitment for the Runes protocol can create a transaction that is valid at the Bitcoin consensus layer but semantically invalid for the Runes or Ordinals indexer. An attacker who recognizes this gap can sign and broadcast the transaction, claiming their counterparty's asset while the victim's indexer-dependent wallet sees the swap as incomplete or failed. In more severe cases, a poorly constructed timelock branch allows one party to claim both sides of the trade after the timeout expires, exploiting the fact that the refund transaction does not properly invalidate the asset transfer path.

A secondary pattern involves indexer state divergence during the swap's critical path. If the two parties rely on different indexer implementations that disagree on the location or validity of the Runes or inscription involved, one party may believe the swap has failed and broadcast a refund transaction that the other party's indexer interprets as a valid asset transfer. This creates a double-spend scenario at the meta-protocol layer even though the Bitcoin consensus layer sees no conflict. Teams building decentralized trading infrastructure for Runes and Ordinals should conduct a security review of their HTLC contract logic and PSBT construction against these specific failure modes, ensuring that asset transfer constraints are enforced at the meta-protocol level and not solely at the Bitcoin script level.