Multi-leg trade atomicity: when one preimage has to settle three legs at once

An autonomous agent kicks off a three-leg trade. Leg one: it pays BTC and receives ETH. Leg two: it routes that ETH to a second counterparty for USDC. Leg three: that USDC settles to a vendor for a compute reservation. Legs one and two clear. Then the third counterparty goes quiet.

The agent is now holding USDC it never wanted, at a price that has already moved against it, with no way to reverse the first two legs. It did not lose the trade. It lost control of its own inventory.

This is the failure mode that single-leg atomic swaps do not address, and it is the one autonomous agents hit constantly, because an agent's "trade" is rarely one hop. It is a path. This post is about making the whole path atomic: either every leg settles, or every leg unwinds, with no intermediate state where anyone is left holding the wrong asset.

Settle-then-hope is the default, and it is the problem

Walk through how a multi-hop trade executes today without atomicity. You settle leg one. Then you attempt leg two. Then you attempt leg three. Each "attempt" is a fresh negotiation with fresh risk. Call it settle-then-hope.

Every intermediate hop carries three costs that compound down the path:

• Inventory risk. Between legs you are holding an asset you did not want to hold. For a market-making agent that is sometimes fine. For an agent executing a directional path it is pure exposure.
• Price risk. The market moves while you are mid-path. The quote that made leg three worthwhile at the start may be underwater by the time legs one and two clear.
• Counterparty risk. Each leg's counterparty can simply not show up, the way the third one did above. You are stranded at whatever hop you reached.

Most funded settlement infrastructure shipping this year optimizes the single leg or the two-party case extremely well. Payment-rail clearing and atomic OTC desks both make one exchange between two parties safe. That is real and useful. Multi-leg atomicity is a different problem: it is about binding N legs across N counterparties and possibly N chains into one settlement fate. Solving the single leg does not solve the path.

The core trick: one secret gates every leg

Hash-time-lock contracts already give us atomicity for two parties. Party A locks funds behind hash(s). Party B locks the corresponding funds behind the same hash(s). When A reveals s to claim B's funds, the revelation is public, so B uses the same s to claim A's funds. Atomic: either s is revealed and both legs complete, or it is never revealed and both refund after a timeout.

The extension to multi-leg is almost embarrassingly direct: use the same hashlock H = hash(s) across every leg in the path. A single preimage s then gates the entire chain.

Leg 1:  A --BTC--> B    locked behind H
Leg 2:  B --ETH--> C    locked behind H
Leg 3:  C --USDC--> D   locked behind H

s revealed once  =>  every leg's hashlock opens
s never revealed =>  every leg refunds

There is no intermediate "leg one done, leg two pending" state that an agent can get stranded in, because no leg can complete without s, and the moment s is public, every leg can complete. The path settles as a unit.

The part that actually requires care: the timelock ladder

The naive version above has a fatal timing bug. Whoever reveals s first exposes it to everyone. If the timeouts are equal, the last party to claim might find their counterparty's refund window has already opened, letting that counterparty grab the refund and the revealed-secret claim.

The fix is a descending timelock ladder. The party that reveals the secret must be the last one whose funds are at risk, so each leg upstream gets strictly more time:

Leg 1 timeout:  T0 + 12h   (longest — A revealed first, needs the most safety margin)
Leg 2 timeout:  T0 +  8h
Leg 3 timeout:  T0 +  4h   (shortest — D claims first, triggering the cascade upward)

The downstream party claims first, which publishes s, which gives every upstream party enough remaining time to claim before their own refund window opens. This is the same safety argument that makes Lightning payment routing work, generalized from a payment path to a heterogeneous, cross-chain trade path.

The consequence worth internalizing: the worst-case capital lockup is set by the longest leg in the ladder, and it applies to every participant simultaneously. A five-leg path locks everyone's capital for the duration of the top rung.

Where it breaks, honestly

If we only described the happy path this would be marketing. The construction has real, named limitations, and an agent deciding whether to use it needs them:

• The free-option problem. The secret holder can watch the market after all legs are locked and choose whether to reveal. That is a free option with value proportional to volatility and lockup time. Mitigations are short windows, a non-refundable fee that the secret holder forfeits on non-completion, or posted collateral. None of them make the option worth exactly zero.
• Capital lockup scales with leg count. Every leg is locked at once, for the worst-case duration. A long path is expensive to hold open.
• Liveness assumption. Someone has to come online to reveal s inside the window. Atomicity protects funds — nobody loses money — but a griefing party can force the whole path to unwind by going dark. You get safety, not guaranteed completion.
• Hash-function compatibility across chains. A cross-chain path is only atomic if every chain can verify the same hash of the same preimage. SHA-256 is the portable choice; a leg on a chain whose cheap native hash is Keccak needs the SHA-256 path explicitly, or the shared-secret property silently breaks.

Atomic multi-leg is strictly safer than settle-then-hope on the dimension that matters most to an agent — you can never be stranded mid-path holding the wrong asset — but it buys that safety with capital efficiency and a liveness requirement. That is the trade. State it plainly to anyone integrating.

How an agent expresses this through MCP

The point of putting this behind an MCP server is that the agent should describe a path, not orchestrate hops by hand. A sealed-bid RFQ carries the full leg set — the assets, the chains, the counterparty slots, and the single hashlock that will bind them. Responders bid on legs; the matched set shares one H; the timelock ladder is derived from the path length and the chains involved. The agent reasons about one settlement outcome, not three independent ones.

The chain-status reality, stated exactly as it stands today: Ethereum mainnet is live end-to-end. Bitcoin HTLCs are signet-validated, mainnet pending. Sui contracts are deployed and CLI-tested, with gateway wiring in progress. A path that touches all three is buildable in pieces today and end-to-end as those legs come online; the BTC-to-ETH leg of the opening example is the part that is live now. No bridge, no custodian, no wrapped asset at any hop.

The distinction worth keeping

"Settlement layer" has come to name several different things this year — payment-rail clearing, atomic OTC desks, custodial venue rails. Most of them make a single exchange between two parties safe, and they do it well. Multi-leg atomicity is the corner of the map where one preimage has to bind a chain of legs across counterparties and chains into a single all-or-nothing outcome. It is a harder problem than the single leg, and it is the one an agent executing a real path actually has.

If your agent's next trade is a path rather than a hop, which leg are you willing to be stranded on?

---

Docs and the MCP tool surface: hashlock.markets/docs. The protocol design and volume methodology: hashlock.markets/methodology. MCP server: hashlock-tech/mcp (scoped). Code: Hashlock-Tech/hashlock-mcp. The cryptographic foundations are written up in the whitepaper on SSRN.