FAQ: What Happens If a Hashlock Markets Swap Fails or Stalls?

A short Saturday FAQ from the team at Hashlock Markets: the non-custodial atomic P2P cross-chain swap protocol that uses sealed RFQs and HTLC atomic settlement across Bitcoin, Ethereum, TRON, Solana, Base and Robinhood Chain.

Update, October 2026. This post was first published in April 2026. It has been revised to match the product as it is live today: six mainnet chains (Bitcoin, Ethereum, TRON, Solana, Base, Robinhood Chain), API key authentication, and the current MCP tool set. Current reference: https://docs.hashlock.markets

People reading our HTLC deep-dives sometimes come away with the happy-path version of cross-chain settlement and an unanswered question: "What if it doesn't work?"

That is the right question to ask of any execution protocol, and it is especially the right question to ask of one that promises trustless, bridge-free, cross-chain swaps. So this Saturday, instead of another deep-dive, we are answering the failure-mode questions directly.

The short version: every Hashlock Markets swap is engineered so that either both sides settle, or both sides get refunded. There is no third outcome where one party walks away with both legs of the trade. Below is how each of the realistic failure modes plays out in practice.

The protocol-level guarantee

Before walking through cases, it is worth restating the property the protocol gives you, because every "what if" answer rests on it.

A Hashlock swap is two Hash Time-Locked Contracts, one on each chain, locked by the same SHA-256 hash of a single 32-byte secret (H = sha256(s)). Each contract has two ways to resolve:

1. Claim path. Anyone who can present s such that sha256(s) == H before the timelock expires can release the locked funds to the leg's fixed recipient.
2. Refund path. After the timelock expires, the original funder can reclaim their funds.

Two roles matter here. The taker posts the RFQ and the maker quotes it; that is the negotiation. At settlement, the party who generates the secret is the initiator, and the initiator funds the leg with the longer timelock. The other party, the counterparty, funds the short leg. The timelock per chain is 24 hours on Bitcoin and 4 hours on Ethereum, Base, Robinhood Chain, TRON and Solana, and the long leg is always at least 2 hours longer than the short one.

The asymmetry is what makes the two-contract construction atomic. The initiator reveals the secret by claiming the short leg. The counterparty then still has time to use that revealed secret on the long leg before the initiator could refund it. If neither reveals, both refund. There is no ordering of events that lets one side claim and the other side fail to either claim or refund.

Everything below is a corollary of that property.

Case 1: No maker answers your RFQ

What happens: The RFQ has a lifetime (ttlSeconds). If no market maker quotes within the window, or if you do not accept any of the quotes that come back, the RFQ simply expires. No funds have been moved on chain at this point. No HTLC exists yet. There is nothing to refund.

What you do: Re-post the RFQ with adjusted parameters (size, asset pair, lifetime) or wait for better market conditions.

Cost to you: Nothing was funded, so there is no gas to pay and no protocol fee at this stage. The fee is paid on top of a leg when it is funded, not when an RFQ is posted.

Case 2: Counterparty disappears after you funded

This is the case that actually worries people, and it is the case the protocol was specifically designed for.

What happens: You created the RFQ, agreed terms in the thread, and funded the initiator-side (long) leg on chain A. The counterparty is supposed to mirror with their own HTLC on chain B, but they go silent. They never fund. They never see a secret. They are just gone.

What the chain does for you: Your long-leg timelock keeps ticking. When it expires, the claim path on your contract is closed and the refund path opens. You build a refund for that leg, sign it, and the chain returns your funds to the refund address you set for the swap.

What it costs you: Network gas on chain A. The notional you locked up was never at risk of being lost, only of being temporarily unavailable until the timelock elapsed. If you were the taker, the protocol fee paid on top of your funded leg is not refunded.

MCP tool: On the hosted server, build_refund returns the unsigned refund transaction and broadcast_tx relays it once you have signed. An agent can poll swap_status and call build_refund automatically when the leg enters the refundable state. On the local stdio server, the same job is deal_status plus refund_leg, signed with the agent's own chain key.

Case 3: You revealed the secret, then the network got congested

What happens: You went first because you were the initiator. You claimed the short leg on chain B by presenting s. The secret is now on chain, public. The counterparty needs to use it to claim your long leg on chain A, but the chain is congested and transactions are sitting in the mempool.

Why this is fine: The long-leg timelock is at least 2 hours longer than the short-leg timelock, and each chain's timelock is sized from its finality and reorg risk. The counterparty has time. On every chain except Bitcoin, Hashlock's keeper claims the leg to its fixed recipient once the secret is public, so the counterparty does not even have to be online. (A Bitcoin claim needs the receiver's own signature, so there the receiver claims it.)

The system never relies on a chain being uncongested. Timelocks are sized assuming you might lose some confirmation time on either side.

Case 4: You lose the secret

The initiator generates the secret s locally and is the only party that needs to keep it until they claim. Only the hashlock ever leaves their machine. The counterparty only needs s after the initiator reveals it on chain, at which point they read it from the claim transaction.

What happens if the initiator loses s before they claim: They wait for their own long-leg timelock to expire and refund. The trade does not settle, but no funds are lost. The counterparty's leg refunds the same way when its shorter timelock expires.

What happens if the counterparty loses s: Not possible in the normal flow. The counterparty only receives s by reading the initiator's claim transaction on chain B, where it is permanently recorded. As long as their leg has not been refunded, the secret is recoverable from chain history.

Case 5: A quote is filled at a price you didn't expect

What happens: Hashlock uses sealed RFQ pricing. Makers quote privately; there is no public price book. A quote opens a thread where either side can propose a new price and the other can take it. You see the terms before you accept them. You sign nothing until you have looked at the price.

Implication: There is no slippage, no last-look, no front-running of an in-flight order. Every accept names the price you read, and it is refused if the terms moved since. If you do accept, the price is locked in cryptographically: the HTLC pair encodes the exact amounts.

Failure mode that doesn't exist: "I executed at a price I didn't expect." The protocol forbids it by construction.

Case 6: Smart-contract-level failure of one of the chains

What happens: This is the catastrophic-event question. If chain A or chain B halts, censors transactions, or undergoes a deep reorg, what then?

What the protocol does: Both refund paths are unconditional once the timelock has elapsed in chain time. A reorg that reverts a confirmed funding transaction is a problem at the underlying chain's security level, not the protocol's; Hashlock waits for each chain's confirmation depth before treating a leg as funded and does not introduce additional reorg risk on top of the chains it settles against. A halt of one chain will eventually time out the contract on the other chain via the refund path; users get back the funds they put in on the still-live chain. The funds on the halted chain are recoverable when the chain resumes.

What the protocol does not do: Hashlock does not bridge tokens or hold custody. There is no cross-chain wrapped representation that could be deflated by a chain halt. There is only the same native asset on each chain that the user already had.

Why this matters for AI agents

Most of this article is the same answer the protocol would give a human user. The reason it matters for agents specifically is that an agent driving Hashlock through MCP (Claude, ChatGPT, Cursor, a custom executor) needs failure handling that is legible to it. The tool set maps cleanly onto the things an agent has to do across the lifecycle of a swap, including the failure cases:

• Watch the swap state with swap_status (hosted) or deal_status (local).
• Build and broadcast a refund with build_refund and broadcast_tx, or call refund_leg, when a leg enters the refundable state.
• Re-post the RFQ on the taker side if no quote is accepted.
• Handle congestion the same way it handles every other on-chain wait: by polling, not by panicking.

There is no out-of-band exception handling. There is no "support ticket" path. The state machine is the support ticket.

Try it

Hashlock Markets ships an MCP server you can wire into any MCP-capable host. Two transports are available:

• Streamable HTTP, hosted: add https://hashlock.markets/mcp to your client. The client discovers it needs authorization, sends you to Hashlock to approve with a wallet signature, and receives its own API key over OAuth. Clients that do not speak OAuth send Authorization: Bearer hk_live_... with a key you created yourself. Keys expire after 90 days. The hosted server returns unsigned transactions; you keep the preimage.
• stdio, for local agent workflows: npx -y @hashlock-tech/mcp with your own chain keys in the environment (npm: https://www.npmjs.com/package/@hashlock-tech/mcp). This one can sign, fund, claim and refund without a human in the loop.

The full docs live at docs.hashlock.markets. Source for the MCP server is on GitHub at Hashlock-Tech/hashlock-mcp.

If your concern about going trustless was "what if something breaks", the answer is that the protocol was designed assuming things break.

---

Hashlock Markets is a non-custodial atomic P2P cross-chain swap protocol that uses sealed Request for Quote (RFQ) auctions and Hash Time-Locked Contract (HTLC) atomic settlement to make cross-chain trades trustless, slippage-free, and immune to information leakage. Live on mainnet today: Bitcoin, Ethereum, TRON, Solana, Base and Robinhood Chain.

Comments

[Anthony Zender]

Great breakdown of the failure modes — the timelock asymmetry between T and T' is exactly the right design for atomicity. One gap worth flagging from the agent execution layer: the article notes that an agent should "poll get_htlc, call refund_htlc when refundable, re-RFQ if no quote is accepted." All correct — but there's a step before that. If create_rfq or create_htlc times out mid-call and the agent retries, it can fire the same action twice before the state machine has confirmed the first one landed. The HTLC layer stays safe, but you now have duplicate RFQs in flight or a double-funded attempt. That's the pre-protocol layer the article calls "polling, not panicking" — SafeAgent handles it by making each action idempotent at the execution level before it ever touches your MCP tools. Happy to share how it would sit above your six-tool interface if useful.

[Baris Sozen]

I replied to this at the other post