Papers
Topics
Authors
Recent
Search
2000 character limit reached

R-HTLC: Secure Atomic Cross-Chain Protocol

Updated 16 May 2026
  • R-HTLC protocol is a cryptographic scheme that enables secure, atomic cross-chain exchanges with enhanced privacy and offline resilience.
  • It employs a unique hourglass unlocking function, multi-path refund logic, and game-theoretic collateral design to thwart offline failures and bribery attacks.
  • Experimental evaluations on Bitcoin and Ethereum demonstrate its improved performance and robust security compared to classical HTLC models.

The Refundable Hashed Time-Locked Contract (R-HTLC) protocol is a cryptographic protocol for atomic cross-party and cross-chain value exchange that augments the classical Hashed Time-Locked Contract (HTLC) model to address offline failures and bribery-resistance. R-HTLC realizes its security enhancements through mechanisms including an hourglass unlocking function, multi-path refund logic, game-theoretically incentive-compatible collateral design, and, in multi-hop cross-chain settings, privacy-preserving proof systems such as zk-SNARKs. R-HTLC aims to secure liveness and privacy against adversarial node-offline patterns, censorship by rational miners, and all known collusive bribery attacks, with experimental validation on Bitcoin and Ethereum (Xu et al., 3 Dec 2025, Awathare, 23 Oct 2025).

1. Motivation and Threat Landscape

Classical HTLC, which uses a hash lock and a time lock to guarantee atomic settlement in payment channels and atomic swaps, is vulnerable in both distributed and decentralized environments. In multi-hop cross-chain networks, node availability is crucial; if any intermediate node is temporarily offline, settlements can fail, posing a risk of funds loss. In permissionless systems, classical HTLCs also suffer from incentive incompatibilities and are susceptible to bribery attacks wherein miners, possibly colluding with protocol participants or among themselves, censor or reorder transactions to unfairly confiscate or block funds (Xu et al., 3 Dec 2025, Awathare, 23 Oct 2025).

State-of-the-art mitigations, such as MAD-HTLC and He-HTLC, extend classical HTLC by adding collateral and nuanced hash-lock logic, but only partially address active and passive miner collusion. They neglect coalition proofs and broader bribery vectors, failing particularly under miner-to-miner collusion (M2MBA). R-HTLC targets these limitations by combining protocol mechanisms that: (i) guarantee atomicity and liveness even under arbitrary node-offline and delayed message patterns; (ii) establish strong game-theoretic irrelevance of bribery; (iii) achieve unlinkability through cryptographic proofs; and (iv) enable decentralized coordination without trusted parties (Xu et al., 3 Dec 2025, Awathare, 23 Oct 2025).

2. Formal Protocol Construction

R-HTLC contracts operate in two paradigms:

  • Cross-chain, multi-hop channels: Each hop in a payment or asset transfer is secured by an instance of R-HTLC between adjacent parties on distinct chains. The protocol employs multiple independent hash-locks and zero-knowledge proofs for consistent and private state synchronization (Xu et al., 3 Dec 2025).
  • Decentralized exchange and atomic swaps: R-HTLC (aka DEMBA) utilizes collateral contracts, burn penalties, and deterministically sequenced commitment phases to achieve bribery-resistance (Awathare, 23 Oct 2025).

2.1 Cross-Chain Channel Parameters and Algorithms

  • Security parameter λ\lambda
  • Collision-resistant hash function H:{0,1}{0,1}256H : \{0,1\}^* \rightarrow \{0,1\}^{256}
  • zk-SNARK system Π=(Setup,Prove,Verify)\Pi = (\mathrm{Setup}, \mathrm{Prove}, \mathrm{Verify}) with completeness, soundness, and zero-knowledge
  • Timelocks TlockT_\text{lock} and TrefundT_\text{refund}, with Trefund<TlockT_\text{refund} < T_\text{lock}
  • Hourglass rate function ρ:[0,Tlock][0,1]\rho : [0, T_\text{lock}] \rightarrow [0,1]
  • Value to lock VlockNV_\text{lock} \in \mathbb{N}

For each two-party contract RR-HTLC(uvu \to v; chain), state variables include secret preimages H:{0,1}{0,1}256H : \{0,1\}^* \rightarrow \{0,1\}^{256}0, H:{0,1}{0,1}256H : \{0,1\}^* \rightarrow \{0,1\}^{256}1, public hash-locks H:{0,1}{0,1}256H : \{0,1\}^* \rightarrow \{0,1\}^{256}2, a set of spend commitments, and a state variable in H:{0,1}{0,1}256H : \{0,1\}^* \rightarrow \{0,1\}^{256}3. Zero-knowledge circuits H:{0,1}{0,1}256H : \{0,1\}^* \rightarrow \{0,1\}^{256}4 enforce cross-chain hash-lock relationships and conceal preimages.

2.2 Decentralized Exchange Logic

R-HTLC (DEMBA) uses three contracts: H:{0,1}{0,1}256H : \{0,1\}^* \rightarrow \{0,1\}^{256}5 (Alice's collateral; dual hash-lock), H:{0,1}{0,1}256H : \{0,1\}^* \rightarrow \{0,1\}^{256}6 (Bob's single hash-lock collateral), and H:{0,1}{0,1}256H : \{0,1\}^* \rightarrow \{0,1\}^{256}7 (exchange contract), with strict redemption and burn rules:

  • If both preimages are released in time, Alice receives the asset.
  • If Bob's refund path is valid after the timelock, he is refunded.
  • If miners censor Alice's claim, she can force a burn of H:{0,1}{0,1}256H : \{0,1\}^* \rightarrow \{0,1\}^{256}8, making such censorship unprofitable (Awathare, 23 Oct 2025).

This structure achieves Nash equilibrium for honest protocol adherence in all bribery and collusion scenarios.

3. Workflow: Multi-Hop and Bribery-Resistant Flows

3.1 Multi-Hop Cross-Chain Sequence

  1. Receipt phase: Each hop H:{0,1}{0,1}256H : \{0,1\}^* \rightarrow \{0,1\}^{256}9 opens/updates its channel and agrees on commit amounts.
  2. Zero-knowledge setup: Terminal node generates and distributes zk-SNARK proofs for all hops; verification ensures state consistency without leaking interaction relationships.
  3. Sequential locking: Each chain runs Tx_Lock operations with monotonically decreasing Π=(Setup,Prove,Verify)\Pi = (\mathrm{Setup}, \mathrm{Prove}, \mathrm{Verify})0 for sequential unlocking.
  4. Reverse unlock: Each intermediary presents unlock proofs; secrets pass backward to enable chain-on-chain release.
  5. Refund handling: If any party fails (offline), local refund logic executes (see Section 4).

3.2 Bribery-Resistance and Collateral Flows

The exchange proceeds in two phases:

  • Phase 1 (commitment): Both parties lock collateral in their respective contracts; exchange contract is set up.
  • Phase 2 (execution):
    • If all parties behave honestly, funds are transferred or refunded appropriately.
    • If censorship/bribery is attempted, burn rules and delayed collateral unlocks make all such deviations unprofitable (Awathare, 23 Oct 2025).

4. Hourglass and Multi-Path Refund Mechanisms

4.1 Hourglass Mechanism

Locked funds Π=(Setup,Prove,Verify)\Pi = (\mathrm{Setup}, \mathrm{Prove}, \mathrm{Verify})1 are divided into "Frozen" and "Available" balances such that, as time advances from lock time Π=(Setup,Prove,Verify)\Pi = (\mathrm{Setup}, \mathrm{Prove}, \mathrm{Verify})2 to Π=(Setup,Prove,Verify)\Pi = (\mathrm{Setup}, \mathrm{Prove}, \mathrm{Verify})3,

Π=(Setup,Prove,Verify)\Pi = (\mathrm{Setup}, \mathrm{Prove}, \mathrm{Verify})4

with Π=(Setup,Prove,Verify)\Pi = (\mathrm{Setup}, \mathrm{Prove}, \mathrm{Verify})5 linear by default (Π=(Setup,Prove,Verify)\Pi = (\mathrm{Setup}, \mathrm{Prove}, \mathrm{Verify})6). Commitments (amounts moved to "Available") are tracked to ensure integrity. This design assures that unresponsive counterparts cannot indefinitely lock funds, reducing exposure to "active offline" scenarios (Xu et al., 3 Dec 2025).

4.2 Multi-Path Refund Logic

Refund processing employs three cases per chain segment:

  • Case 1 (normal): If unlock is achieved and Π=(Setup,Prove,Verify)\Pi = (\mathrm{Setup}, \mathrm{Prove}, \mathrm{Verify})7, the original locker redeems all remaining funds.
  • Case 2 (active offline): If the unlock did not occur by Π=(Setup,Prove,Verify)\Pi = (\mathrm{Setup}, \mathrm{Prove}, \mathrm{Verify})8, the locker can unilaterally recover via secret revelation.
  • Case 3 (passive offline/cheat mitigation):
    • The counterparty, if unlocked elsewhere, can claim via an alternative unlock proof.
    • Miners may challenge an illegitimately-claimed refund by revealing cooperation secrets and are rewarded to incentivize honest monitoring.

Each chain's contracts enforce these rules independently, eliminating single-point failure and unfair enrichment (Xu et al., 3 Dec 2025).

5. Security, Privacy, and Incentive Properties

5.1 Atomicity, Liveness, and Bribery Resistance

  • Atomicity: Either every party in a chain receives their entitled value or all recover funds. Violating this implies cryptographic assumption failure or an error in smart contract logic (Thm 4.1, (Xu et al., 3 Dec 2025)).
  • Liveness: The hourglass and refund mechanisms guarantee available redemption for honest parties under arbitrary offline patterns (adversary may drop/delay messages, or act passively/actively offline).
  • Bribery-Resistance: Formal game-theoretic analysis shows that no bribery coalition (Alice-miner, Bob-miner, miner–miner) can strictly improve expected payoff by deviation; all rational miners maximize expected returns by following protocol, as any censoring party risks fund burn or reduced fee receipts (Thm 4.1, Lemmas 2.3–2.5, (Awathare, 23 Oct 2025)).

5.2 Privacy and Unlinkability

  • Hash lock independence: Each hop uses cryptographically independent hash locks, thwarting cross-chain transfer correlation.
  • zk-SNARKs: Zero-knowledge proofs ensure protocol compliance without revealing dependencies or amounts.
  • Off-chain receipts: Arbitrary intra-chain amounts hide cross-chain exchange values, making routing relationships statistically indistinguishable to partial observers (Thm 4.2, (Xu et al., 3 Dec 2025)).

6. Assumptions, Formal Results, and Experimental Evaluation

  • Adversary model: PPT adversary may delay/drop messages, corrupt any subset of intermediaries short of the full path.
  • Chain model: Underlying ledgers assume honesty bounds (PoW: Π=(Setup,Prove,Verify)\Pi = (\mathrm{Setup}, \mathrm{Prove}, \mathrm{Verify})9 adversarial mining, BFT: TlockT_\text{lock}0 Byzantine nodes).
  • Cryptographic assumptions: TlockT_\text{lock}1 is collision-resistant; zk-SNARKs are sound and zero-knowledge.
  • No trusted setup: All operations occur either on-chain or via publicly verifiable, simulation-extractable protocols.

Experimental results (Xu et al., 3 Dec 2025, Awathare, 23 Oct 2025):

Metric Naive HTLC MAD-HTLC He-HTLC R-HTLC
Bitcoin Alice claim (bytes) 250 320 260 272
Bitcoin Bob refund (bytes) 250 450 300 174
Ethereum Alice claim (gas) 80,000 95,000 75,000 78,000
Ethereum Bob refund (gas) 80,000 120,000 85,000 65,000
BTC time-to-complete (min) 10.1–10.2 11.8–12.3 10.0–25.4 10.0–10.1

A plausible implication is that R-HTLC maintains favorable performance metrics while uniquely providing both full offline resilience and provable bribery-resistance across practical deployment contexts.

7. Significance and Context in Cryptographic Protocols

R-HTLC both extends and addresses concrete deficiencies in the security and application landscape of atomic cross-chain and decentralized exchange mechanisms. By tightly coupling hash-lock independence, time-conditioned liveness, fine-grained refund logic, and privacy-preserving proof composition, R-HTLC is the first HTLC variant to achieve provable atomicity, equivalence-incentive Nash equilibrium for all participants (including all forms of bribery and censorship), and unlinkability in adversarial settings (Xu et al., 3 Dec 2025, Awathare, 23 Oct 2025). This security tightness positions R-HTLC as a canonical core for secure, censorship-resistant, and privacy-preserving decentralized financial infrastructure.

Topic to Video (Beta)

No one has generated a video about this topic yet.

Whiteboard

No one has generated a whiteboard explanation for this topic yet.

Follow Topic

Get notified by email when new papers are published related to R-HTLC Protocol.